2205 2005-09-14 19:09:40 +0000 R-213: Question about attribute wildcards and restriction 2009-04-21 19:25:08 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.0 only All All CLOSED LATER P2 normal --- 1 sandygao ht www-xml-schema-comments oldest_to_newest 6222 0 sandygao 2005-09-14 19:09:40 +0000 This is a recap of an possible erratum discussed within the Schema IG. Because attribute wildcards have a "lazy" behavior, it's possible for an apparently-valid restriction to violate the general notion of restriction. By "lazy" I mean the property that an attribute-wildcard will only match an attribute-information-item (AII) if no other attribute-use matches the AII. Best demonstrated by example: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="B"> <xs:attribute name="FOO" type="xs:int"/> <xs:anyAttribute processContents="skip"/> </xs:complexType> <xs:complexType name="A"> <xs:complexContent> <xs:restriction base="B"> <xs:attribute name="FOO" type="xs:int" use="prohibited" /> <xs:anyAttribute processContents="skip" /> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:schema> I believe this is a valid restriction per the rules of restriction, but not by the general definition in Section 2, which includes Members of a type, A, whose definition is a restriction of the definition of another type, B, are always members of type B as well. B doesn't accept an element with attribute FOO="abc", but A does accept it. That's because A doesn't contain an attribute-use for FOO, so the attribute- wildcard validates FOO in A. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003JanMar/0007.html 6421 1 sandygao 2005-09-23 03:59:52 +0000 Closely related to the "restriction as subsumption" discussion (RQ-17 and friends). Propose to close this bug and defer to 1.1. 6426 2 sandygao 2005-09-23 15:37:45 +0000 The email reference should be http://lists.w3.org/Archives/Public/www-xml-schema-comments/2003AprJun/0007.html 6519 3 sandygao 2005-09-28 11:55:05 +0000 Discussed at 2005-09-23 telecon and decided to defer this to a future version of the recommendation.