This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3.3.2.1 Common Mapping Rules for Element Declarations specifies that the {identity-constraint definitions} property of an element declaration component contains just those identity constraints mapped to by the relevant children of the element's source declaration. The SML Working Group, in contrast, has found it desirable to ensure that if a particular element declaration E carries a set of identity constraints, those constraints (or a more restrictive set of constraints) are also carried by each element declaration substitutable for E. For example: if a <student> element is required to have a key reference which corresponds to some element in the Students document, then a <graduate-student> element, which is conceptually a refinement of the <student> element, should also be required to have an appropriate key reference. In short: XSD does not ensure that the (XSD) identity constraints on an element E are also obeyed by elements substitutable for E; SML does ensure that the analogous SML identity constraints are obeyed by substituted elements. This state of affairs seems to raise two problems: (1) The lack of alignment between the two specifications is likely to prove confusing for users of the two specs. The lack of alignment was raised as an issue against SML in bug 4643, but the SML Working Group declined to change the SML rule, on the grounds that the constraints imposed by it are necessary for reliable specification of constraints. (2) The rule adopted by XSD appears to make it too easy for document authors or schema extenders to evade or subvert identity constraints imposed by a schema, and too hard for schema authors to prevent such evasions. (The only obvious way to prevent them is to block substitution entirely, which is throwing out the baby with the bath water.) Either of these seems sufficient reason to request that the XML Schema WG consider aligning its rules for the interaction of identity constraint and subsitution groups with those of the SML specification. The simplest way to align the two specs would be for XSD 1.1 to specify (a) that if no identity constraints are specified in a source declaration, then the identity constraints of the substitution-group head are inherited, and (b) that as a constraint on schemas, the {identity-constraint definitions} of any element must be a restriction of those of its substitution-group head. (The nature of restriction will also need to be defined.) The relevant rules of SML, for those who would like to review them, may be found by examining the occurrences of the phrase "substitution group" in sections 5.2.1.1 and 5.2.1.2. Analogous provisions relating to SML's target* constraints and Schematron rules may be found in 5.1.2.1, 5.1.2.2, and 6.3.1. The most recent public draft of SML is at http://www.w3.org/TR/sml/ and the current editors' draft is at http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml.html?content-type=text/html;%20charset=utf-8 This bug report grows out of discussions in the SML Working Group, and reflects an SML WG decision to suggest aligning the two specs as described above; that decision was captured in the form of an action (http://www.w3.org/2005/06/tracker/sml/actions/137) which this bug report discharges. But from a formal point of view, the SML WG has not reviewed or endorsed the issue description above. I am filing this report today in order that it be on record before the close of the last-call comment period; I expect the SML Working Group to consider at its meeting next Thursday whether to endorse it.
On its teleconference of 2008-09-18, the SML working chose to endorse this bug without any objections.
I think it was a mistake to put identity constraints on elements; they should be constraints on types. If that were the case, there would automatically be a constraint of consistency within the type hierarchy, which in turn would force consistency within a substitution group. It's hard to impose a constraint in XSD 1.1 that wasn't there in 1.0 (this comment is another one that has really been misclassified as a 1.1 comment when it addresses things that were equally true in 1.0). So perhaps the answer is for 1.1 to allow identity constraints on types as well as on elements, and enforce the consistency rule only for constraints on types? However, that's a new feature, and we really shouldn't be adding new features after a second last call. (personal comment)
The WG discussed this issue on 10 October 2008, and concluded that while the idea may be a good one, adopting it now would substantially delay XSD 1.1. Accordingly, we are closing it with a disposition of LATER. The originator is requested to convey this result back to the SML WG and let us know whether they are happy with this disposition.
On 11/6 the SML working group endorsed the resolution in comment 3 without objection.