This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The definition of "context determined type table" uses an "effective type table" - constructed from {type definition} - if the Element Declaration D has no {type table}. The application of this definition in Conditional Type Substitutable in Restriction (§3.4.4.5) has an inacceptable effect: Let T1 be a complex type definition which contains a wildcard matched by one or more global Element Declarations without {type table}. Then any type T2 derived from T1 which contains a local Element Declaration overriding one of those Element Declarations matching the wildcard is likely to make any element validated against it invalid, if only that element contains a child element whose name matches the overriding Element Declaration. This follows from 3.4.4.2, clause 7, that is, the application of "Conditional Type Substitutable in Restriction" to that child element. If the local element declaration contains a type table, the element is invalid because it violates Element Declarations Consistent (§3.8.6.3); if it does not contain an element declaration, application of Conditional Type Substitutable in Restriction (§3.4.4.5) will probably result in ST != SB. This is illustrated by the following example schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="e2" type="t2"/> <xs:element name="b" type="xs:integer"/> <xs:complexType name="t1"> <xs:sequence> <xs:element name="a" type="xs:string"/> <xs:any processContents="skip"/> </xs:sequence> </xs:complexType> <xs:complexType name="t2"> <xs:complexContent> <xs:extension base="t1"> <xs:sequence> <xs:element name="b" type="xs:date"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema> Any element validated against Element Declaration e2 will be invalid, because applying "Conditional Type Substitutable in Restriction" to child element b (with T=t2, B=t1) yields: ST = xs:date SB = xs:integer
Note that the constraint is called "Conditional Type Substitutable in *Restriction*", but your example uses <extension>. As we have observed in bug 6561, the "skip wildcard bringing in CDTT" aspect may not seem intuitive to some people, but we haven't identified a case where this behavior is "incoherent", instead of just "feels strange".
Closing this bug according to comment #1. Note that the concerns raised in bug 6561 have been addressed by a proposal recently adopted by the schema WG. See bug 6561 for details.
(In reply to comment #2) I think 3.4.4.5 "Conditional Type Substitutable in Restriction" deals with extension too, in spite of its title. Therefore the example presented seems to me appropriate. The resolution of bug #6561 *seems* to fix the problem which the concrete example presented above poses. This is so because a skip wildcard is used. But after replacing it with a lax wildcard, we get these phenomena: 1. the element declaration of e2 is correct according to 3.8.6.3 (because it does not use type tables), but will yield any element instance invalid (because 3.4.4.5 does compare type definitions, in the absence of type tables) 2. if the local element declaration of b (or the global one) included a "redundant type table" stating the type definition as the default and not containing alternatives - then suddenly the element declaration of e2 would be inconsistent according to 3.8.6.3 part 2. And now with the latest correction - xs:anyType does not create any context-determined type table - we get a further twist: 3. the example as presented above yields element instances invalid; but if we collapse the two steps of derivation into one, getting <xs:complexType name="t2"> <xs:sequence> <xs:element name="a" type="xs:string"/> <xs:any processContents="lax"/> <xs:element name="b" type="xs:date"/> </xs:sequence> </xs:complexType> I think the element instances that were found invalid (due to 3.4.4.5 Conditional Type Substitutable in Restriction) are again valid (clause 1: "if TB does not exist => constraint is satisfied"). So if *one* of the purposes of 3.4.4.5 was to disallow one element name to be associated with different types within a complex type, this purpose is sometimes met, sometimes not: it depends on how the matches (wildcard and element declaration) are distributed over derivation steps. So I think it is inappropriate to try let 3.4.4.5 do a job *beyond* safeguarding the consistency of proper type tables within derivation chains: better leave a job alone, than do it unreliably, occasionally, undermining the confidence in what is correct and what is not. I suppose there is a general feeling that the present state of affairs is not quite as clear as one might wish. Perhaps there is just no real improvement in sight, and one should leave things as they are. So I really do not know if the following proposal would be an improvement - but at any rate you might consider it as an option: ! Change the definition of context-determined type table in such a way that an element does not have a CDTT unless it does contain a type table (that is, dropping clause 2.2) ! Advantage: than the rules dedicated to safeguard the consistency of type tables (3.4.4.5 and 3.8.6.3) would be clear and without contradiction. The basic concept of consistent type tables would be: the elements in question must either all have compatible type tables - or all have no type tables. Disadvantage: 3.4.4.5 would cease to help ensure that one element name cannot be associated with several types (in case concurrent element declaration and wildcard) within a complex type. But, as I tried to point out, the disadvantage is perhaps an illusionary one, as the safeguarding function of 3.4.4.5 is unreliable. The proposal would reduce 3.4.4.5 to this purpose: safeguard the consistence of type tables within derivation chains.
> you might consider it as an option: > ... (that is, dropping clause 2.2) I think clause 2.2 is there to make sure the following works: <xs:complexType name="base"> <xs:sequence> <xs:element name="a" type="xs:decimal"> <xs:alternative test="1" type="xs:integer"/> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="restriction"> <xs:complexContent> <xs:restriction base="base"> <xs:sequence> <xs:element name="a" type="xs:int"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> For element "a", base assigns "xs:integer" and and restriction assigns "xs:int", it should be OK. Without clause 2.2, T_T for "restriction" would be absent, and "Validation Rule: Conditional Type Substitutable in Restriction" would fail.
(In reply to comment #4) Yes, you are right - therefore dropping clause 2.2 would have to be combined with a modification of 3.4.4.5 Conditional Type Substitutable in Restriction. This modification would distinguish the special case you pointed at - "B has a type table and T has not" - and use in this case instead of ST a T_T constructed "on the fly" from T.{type definition}, just as CDTT presently is always constructed. And in a similar way one would have to handle a second special case: "B has no type table but T has, and derivation mode is extension". But one can get the same result in a much simpler way: a) leave the definition of CDTT as it is b) add a special clause to 3.4.4.5 which states the constraint to be satisfied if neither B nor T has a type table. So please REPLACE THE PROPOSAL made in comment #3 by the following ... Proposal: ==================================== Change 3.4.4.5 in the following way: a) After "E and T satisfy this constraint if and only if one of the following is true", insert: 1. T.{type table} is absent, and B.{type table} is absent b) Accordingly renumber the presently existing clauses, that is, increment their numbering by 1, to get: 2 Tb does not exist (i.e. E has no context-determined type table in B) 3 TT and TB both exist ... etc. ==================================== Motivation: ==================================== 1. The purpose of 3.4.4.5 - as stated in the Note immediately following it - would still be fully met 2. This side effect would be removed: erratically making instances invalid in cases where no type tables are involved. ====================================
Thank you for your comments and your interest in the XSD 1.1 spec. The XML Schema WG discussed this issue at its telcon today. I am sorry to have to tell you that, while several members of the WG found the proposal attractive in various ways, there was also some feeling in the WG that a really full development of the idea would probably require more time than the WG has as its disposition (we are late in delivering XSD 1.1 as a Candidate Recommendation), and runs a fairly high risk of leading to results which are not compatible with the fundamentals of the story the WG believes we are telling about restriction. I am not sure that the WG had consensus on the proposition that we should do nothing here, but it was clear that the WG did not have consensus to hold the progress of the spec for this issue, and that developing a strong consensus either way would not happen in the foreseeable future. Accordingly we are resolving the issue with a disposition of LATER, which means we recommend consideration of this idea to any WG responsible for future versions of XSD. Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next ten days or so, we will assume you agree with the WG decision.
(In reply to comment #6) Thank you for your detailed explanation of how you came to your decision. From my point of view it is a pity, but I understand your hesitation. What also reconciles me with the outcome is the thought that a future fix is likely to make the language more tolerant, rather than stricter. So postponing the fix will not result in later breaking schemas which are valid now. Accordingly, I close this bug report.