5079 2007-09-26 01:44:57 +0000 Type tables and substitution groups 2008-02-10 02:06:21 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only Macintosh All CLOSED WORKSFORME http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ medium, work, clarification cluster P2 normal --- 1 xan.gregg cmsmcq www-xml-schema-comments oldest_to_newest 16796 0 xan.gregg 2007-09-26 01:44:57 +0000 It seems that type tables aren't used in the definition of type derivation or substitutability, allowing for valid substitutions that subvert the type constraints. For example, <xs:element name="message" type="messageType"> <xs:alternative test="@kind='string'" type="messageTypeString"/> <xs:alternative test="@kind='base64'" type="messageTypeBase64"/> <xs:alternative test="@kind='binary'" type="messageTypeBase64"/> <xs:alternative test="@kind='xml'" type="messageTypeXML"/> <xs:alternative test="@kind='XML'" type="messageTypeXML"/> </xs:element> <xs:element name="mixed_message" type="messageType" substitutionGroup="message"> <xs:alternative test="@kind='string'" type="messageTypeXML"/> <xs:alternative test="@kind='binary'" type="messageTypeString"/> </xs:element> Is this a problem? 18158 1 cmsmcq 2007-12-27 00:45:41 +0000 Thank you for the comment. There seem to be two possible answers to your question. The first is: no, there is no problem. At least, there is no logical contradiction here. The rules for substitutability require a particular relation between the declared type of the substitution-group head and the declared types of the members of its substitution group. It is true that particular instances of the head and particular instances of the substitution-group members may have different types -- in 1.0 this is possible by means of xsi:type, and in 1.1 it is possible both by means of xsi:type and by means of conditional type assignment. The guarantee that schema validity gives relates to the declared type; this has consequences for the governing types of the element instances involved, but it does not have the consequence that there is any substitutability relation between the governing types of different element instances which match the same particle, only that there is a substitutability relation between the governing types and the declared type given in the particle. A second answer would just turn the question around: the schema spec makes a given guarantee. Is that guarantee sufficient for users' needs (in particular, yours)? Or is it a problem? If it's not a problem for users of XSDL, then it's not a problem. If it's a problem for a sufficiently large number of them, then it may be a problem. But that is for you to say, not for the WG. 18175 2 xan.gregg 2008-01-01 22:43:31 +0000 I know of no user problems -- just making sure this is not an oversight. 18559 3 David_E3 2008-01-25 20:04:54 +0000 After discussing this issue, the WG believes that the current design handles the significant cases. As always, thank you for your careful reading of our work, Xan. 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 two weeks, we will assume you agree with the WG decision. 18956 4 xan.gregg 2008-02-10 02:06:21 +0000 I disagree with the resolution but will not appeal. The unconstrained combination of type tables and substitution groups violates the spirit of valid derivation in the substitution group tree. I assume the WG is aware of this violation and considers the intersection of these two features to not be a "significant case." It will be dangerous to combine the two features, and any examples of elements with type tables in future editions of XSD 1.1 should block substitution.