Re: [xml] Proposal for libXML2 inclusion in LSB


On Wed, 2005-11-16 at 02:39 -0500, Daniel Veillard wrote:
On Tue, Nov 15, 2005 at 10:59:17PM -0800, Hisashi T Fujinaka wrote:
On Mon, 14 Nov 2005, Daniel Veillard wrote:


 Inplesmantation of redefines except that no more than the amount of
change that Microsoft is about to do to its published and released MSXML4
XML toolkit deployed everywhere.

I'm not understanding this. Do you mean the previous release of the
specification is distributed widely enough that it should be

  I mean that our level of problems with the specification is not much worse
than the one from Microsoft or others XML Schemas implementations. We have
one missing piece of the standard (redefines) and various bugs and specs
understanding problems like everybody else.

Just to complement Daniel's note: we have an initial implementation of
redefinitions. What is missing to make redefinions complete is the
support of 'restriction' constraints for complex types. Since in XML
Schema 1.0 those constraints were recognized to be too restrictive and
too complex, Libxml2 will not try to implement those, but will compare
only the content model to be a subset of the restricted content model,
as described in XML Schema 1.1 - this is currently done also by XSV and
Ah, and we are missing unique particle attribution.
If this API should be included in LSB, then we should point this out
clearly, as Libxml2 is not yet at the state to completely verify
the correctness of schemata and should not be used to _learn_ writing

The problems with tests for an XML Schema 1.0 implementation are based
on the many parts of the spec which leave room for interpretation or are
simply not doable without interfering with other rules of the spec. So
test results will change - besides bugfixes or error report enhancements
- due to adjustment of such wobbly parts; I'm always asking the W3C
people when I hitting a wobbly part, and the decision which way to go
for an implementation is based on the answers (if any) of the XML Schema
WG + affected by other implementations (Xerces-J, Saxon, MSXML, XSV and
SQC) + affected by common sense. To be compatible, we will change the
implementation when all the other processors take a specific approach -
unless it's clearly visible that it would be wrong.

To some extent XML Schema 1.0 is a wobbly spec, thus we get wobbly test
results to some extent.

If we are talking about the schema processor's stability regarding
segfaults and that alike:
- we have 23170 tests for the datatype part of the spec
- 7230 + 193 tests for the structure part of the spec
Although the test suite does not cover many real-life scenarios it feels
good enough call it at least semi-stable.

If we are talking about the schema processor's stability regarding the
schema spec: I have not seen yet a schema processor which is
implementing the spec correctly to the full extent; I even think that
this is not doable, at least with XML Schema 1.0.
Based on my personal observations, if I should try to compare XSV with
Libxml2, then XSV is working about 70% correct, while I would give
Libxml2 90%.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]