6168 2008-10-16 16:04:27 +0000 Interaction of notQName="##defined" with processContents 2008-10-30 13:24:39 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only PC Windows NT CLOSED WORKSFORME P2 normal --- 1 mike cmsmcq www-xml-schema-comments oldest_to_newest 22184 0 mike 2008-10-16 16:04:27 +0000 In an element or attribute wildcard, using notQName="##defined" together with processContents="lax" or processContents="strict" would seem to be meaningless. Shouldn't it be banned? Alternatively, should the functionality be delivered through a new value for processContents rather than through the notQName attribute? 22188 1 mike 2008-10-17 08:48:03 +0000 Further thoughts on this. There now seem to be four ways of controlling what happens when a wildcard matches/does not match a global element/attribute declaration: strict: validate if defined, error if not lax: validate if defined, untyped if not skip: untyped if defined, untyped if not notQName=defined: error if defined, untyped if not One practical implication of making this a fourth option on processContents (let's say processContents="undeclared") would be that it would affect the rules for wildcard intersection and union. Currently the rules for attribute groups with multiple wildcards are pretty strange: you get the intersection of the allowed namespaces, but the processContents of the first wildcard. Moving the notQName=defined so it became a processContents option wouldn't suddenly set the world to rights on this, but it would ensure that you don't end up with crazy combinations like processContents="strict" notQName="##defined". (I'm not sure where this leaves notQName="##definedSibling", however - that's another carbuncle, if you ask me.) 22197 2 sandygao 2008-10-17 16:51:01 +0000 Using "processContents" for the "not-in-schema" wildcard support was one possibility the WG considered, because its interaction with global declarations is like the opposite of "strict". The WG decided not to do it. We may be able to recover the reasoning by fishing through the minutes. One way to look at the interaction between {namespace constraint} and {process contents} is that the former controls what to match, and the latter controls what to do after the match. For "not-in-schema" wildcard, one could argue that the test should fail at the "match" step, which makes {namespace constraint} (hence notQName) a better choice. Also note that "strict" = "can be validated (against a declaration or a type)" != "matches a global declaration". i.e. having an xsi:type would satisfy strict (and lax), without a matching global element declaration. 22285 3 cmsmcq 2008-10-29 22:16:08 +0000 The WG discussed this issue at some length during the ftf today. After discussion, those present felt that the initial proposition in the issue description is not really true: the meaning of a strict not-in-schema wildcard is unusual and unlikely to be widely needed, but it does have a well-defined meaning: it does not match any element declared in the schema, and if it does match an element (which will be one not defined in the schema), either there is an xsi:type on the element, or the parent will be invalid. The difference between this and an imaginary wildcard with processContents="undeclared" is also visible in the interaction with open content: if 'e' is declared in the schema, then <xs:any notQName="##defined"/> does not match an instance of 'e', which means the 'e' may be matched by the open content particle, whereas <xs:any processContents="undeclared"/> would match an 'e' and prevent it matching the open content particle. We concluded that the right way to class this bug report is as 'WORKSFORME'. Michael, please review this decision and its rationale and communicate your judgement in the usual way. Thanks. 22290 4 mike 2008-10-30 13:24:39 +0000 I think this rationale exposes the severe lack of orthogonality in the design of this construct; but lack of orthogonality is not a bug (and is nothing new to XSD) so I will accept the resolution.