- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Sun, 31 Mar 2013 16:22:31 -0600
- To: Pierre Attar <pat@tireme.fr>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, XMLSchema-dev <xmlschema-dev@w3.org>
On Mar 20, 2013, at 11:56 AM, Pierre Attar wrote: > Hi, > > I have a problem using group redefinitions and validating both with XMLSpy (who complains) and Oxygen (who validates). > My question : who is correct ? Where a I wrong ? > > Note: my schema are a lot more complex but I try to make a sample (non realistic) in order to isolate my question. > > Here is the situation : > > base.xsd declares a group called essai : > ... > > > other.xsd only includes base.xsd > ... > And now, redefine .xsd both redefine base.xsd and includes other.xsd > > ... > At this time, XML spy complains but not oxygen 14.2. If I remove the include, no problem found. The upshot is that in the schema described by redefine.xsd, the components declared in base.xsd are both redefined (via the redefinition of base.xsd) and included as-is (via the inclusion of other.xsd and the inclusion, there, of base.xsd). Such situations do not, I believe, have any non-contradictory interpretation in the XSD spec, and (as one might expect under the circumstances) processors differ in how they attempt to make sense of the contradictory rules in the spec. The description of xs:redefine says (simplifying slightly) that the redefined version of the essai element should be included in the schema. The description of xs:include says (again simplifying) that the unmodified version of the 'essai' element should be included in the schema. If both of these descriptions are taken at face value, then the schema described by redefine.xsd has two top-level declarations for 'essai' and does not conform to the spec. That appears to be the reading adopted by XML Spy. The spec also says in passing (and without any concrete explanation of what is meant) that redefinition has "a pervasive impact". This is taken by some implementations to mean that the inclusion of base.xsd should essentially be ignored (or else be regarded as covered by the redefinition request). That appears to be the reading adopted by Xerces and/or Saxon, which Oxygen is using. Of the two readings of the spec, the second one (which allows this schema to be legal) is probably closer to what the designers of the redefine construct wanted to achieve, and most users probably find it more useful. But the first reading seems to me to be a perfectly plausible -- in fact, somewhat more plausible -- reading of what the spec actually says about the meaning of the constructs involved. Both readings seem to involve ignoring parts of the spec: the first reading ignores the sentence about redefinition having pervasive impact as being unclear or meaningless, or else must assign it some meaning compatible with the rest of the reading. The second reading ignores all the rules in section 4 of the spec about the meaning of xs:include. To answer your questions directly: Who is correct? The spec is too badly drafted to allow this question to have a clear answer. So: no one is correct, or everyone is correct. For all practical purposes, we must act as if the spec said explicitly that the behavior of conforming processors in cases like this one were implementation-dependent. Where are you going wrong? You are going wrong by including constructs in your schemas whose meaning is implementation-dependent (in this case because the meaning is not well defined by the XSD spec), and then expecting different processors to behave consistently. If you want consistent behavior across processors, eliminate the double reference to base.xsd. The simplest way to avoid implementation-dependent processing of include, import, and redefine is to remove all instances of xs:include, xs:override, and xs:redefine, and all instances of @schemaLocation on xs:import, from any schema document that actually declares anything (elements, attributes, types, ...), and move them into distinct 'driver' documents which contain no declarations of their own, but only references to other schema documents: In the ideal case: - "class 1" schema documents contain declarations and definitions; if they have xs:import elements, those elements have no schemaLocation attributes. - "class 2" schema documents contain nothing but a top-level xs:override or xs:redefine pointing to a class-1 schema document. - "class 3" schema documents contain nothing but xs:include (and possibly xs:import) elements pointing to class-1 or class-2 documents. If xs:import elements are present, they may carry schemaLocation attributes. In complex cases, you may end up with a class-2 document needing to redefine the entire set of components for a namespace, so it may end up pointing to a class-3 and not a class-1 document. In any case, avoid multiple references to the same schema document and avoid cyclic references (A refers to B refers to C refers to ... refers to A): they have interoperability problems out of all proportion to their convenience. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Sunday, 31 March 2013 22:23:06 UTC