This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'm reading the latest editor's draft of XML Schema 1.1 structures spec (ref, http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html dt: 15 August 2010), and I have a suggestion for an editorial improvement. In the section "3.7.2 XML Representation of Model Group Definition Schema Components" it's said (just after "XML Representation Summary: group Element Information Item"): If there is a name [attribute] (in which case the item will have <schema> or <redefine> as parent) I think the above sentence should be rephrased as follows: If there is a name [attribute] (in which case the item will have <schema>,<redefine> or <override> as parent) It seems <override> is also the desired parent instruction of the schema instruction xs:group name=.. PS: the same textual description is there in the latest public draft of XSD 1.1 structures spec at, http://www.w3.org/TR/xmlschema11-1/.
In Lyon: The WG discussed this issue and instructed editors to add a note to each section on XML Representation the rules apply after conditional inclusion and override processing.
To clarify comment #1 for the benefit of the originator: XML Representation Rules apply to the schema document AFTER the preprocessing that is carried out to implement the xs:override rules. In this preprocessed document, the Model Group Definition will never have a parent xs:override element. So the text is technically correct. But it is easy for the reader to miss this subtlety, so the editors were instructed to clarify this.
Decision on telcon 2011-02-04: to accept the proposal for 11179 as submitted, and bounce back the proposal for 11354 to the editors with instructions to prepare a proposal to define two schemas and two DTDs for schema documents, one for the raw and one for the cooked.
A further observation on comment #3: note that the XSLT transformation to implement xs:override is a schema-aware transformation, and it assumes that both the input and the output documents can be validated against the schema for schema documents. Note also that it's not possible to define a schema-aware XSLT transformation in which the input and output are valid against two different schemas unless the union of those schemas is itself a valid schema (which means they can't contain different definitions of like-named elements or types). Having said that, it would not be difficult to replace this transformation with one that isn't schema-aware. (However, this would be something of an admission of failure. Managing applications where there are multiple document types with overlapping vocabularies is a problem our users face every day, and if we can't do it, there's something wrong. It's particularly ironic that the problem should arise as a consequence of xs:override, which was designed explicitly to help in managing this situation.)
Is there any property of XSD schemas that makes it difficult or impossible to solve the problem of working with documents conforming to multiple overlapping schemas? Or is the difficulty Michael Kay alludes to just a consequence of the rules imposed (or assumptions made) by XSLT 2.0? It seems to me that if we are to use qualified names to identify things of interest (like the definitions of types and elements), and if those things of interest may vary (so that what we regard as a single element may be defined differently in different formal definitions of a vocabulary), then the unique definition of an element or type requires a triple (the qualified name of the element or type, and some third item -- perhaps the URI of a schema, or perhaps the URI of a schema document. Some people have favored -- some perhaps still favor -- a view in which the qualified name of the element or type suffices to identify a single formal definition. In the world at large, that position became untenable when the Web community decided to give the different flavors of (X)HTML the same namespace; it might have been easier to adopt that view if XPath and other technologies had made it easy to write "html:p" and match the 'p' element in any of an enumerated list of HTML namespaces, but they didn't, and I'm benefiting from hindsight: I don't remember anyone suggesting at the time that this would help. XSD reflects the explicit assumption that the world may have more than one formal definition, in XSD, of the same expanded name. I agree that it's a problem that schema-aware transformations work from the contrary premise but am unsure what the XSD spec of the XML Schema WG can do about it. Surely the world would be a better place if we had had more success helping other WGs understand the XSD spec and how best to use it (assuming, of course, that we know how best to use it); we might have had better success in that if we had made the spec easier to understand and use in the first place. But really I think the variability of definitions for qualified names is one of the places where XSD has been clearest (by its lights) all along.
>Is there any property of XSD schemas that makes it difficult or impossible to solve the problem of working with documents conforming to multiple overlapping schemas? Or is the difficulty Michael Kay alludes to just a consequence of the rules imposed (or assumptions made) by XSLT 2.0? It's more the absence of a property than its presence. The XSD spec provides a simplistic view of a world in which there is only one schema. Within that schema, names are global and unique, redefines has ubiquitous effect, the meaning of ##notDefined is well-defined, nothing ever changes - it's a toy world. There's nothing to stop people developing a richer world view on top of this, one in which there are multiple schemas (identified by another level of indirection in naming), versions and variants and what-have-you. But developing a model for this, given how complex the XSD model already is, is a pretty daunting prospect, and I can't imagine anyone having the stomach for it.
Created attachment 962 [details] Wording proposal as adopted. For the record - the proposal mentioned in comment 3 is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11179.html (member-only link) An abbreviated version of the proposal including all the proposed changes but not the complete text of the spec, is attached for reference by readers without member access to the W3C site.
As discussed on this morning's WG call, this issue needs to be reconsidered in light of our discussions of bug 12184 and bug 11354, so I'm changing its keyword accordingly. Specifically, since the override transform specified in the spec does not eliminate all override elements, it is not true that once override pre-processing is performed the processor will not see any override elements. We may be able to change the description of the process to make that true (in which case the change considered and adopted earlier will still work), but at the moment it seems more likely that we will end up expecting override elements to be present in schema documents after pre-processing.
Reflecting the decision on bug 11354
A wording proposal intended to resolve this issue is on the server at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11179bis.html (member-only link) This proposal - revises the passages which currently mention special conditions for source declarations which are children of 'schema' elements, or children of 'schema' or 'redefine' elements. Since children of 'override' do not always unconditionally map to components, 'override' has not simply been added to the list of possible parents, but notes have been added to explain that the rules or special handling in question may apply to children of 'override' as well. (Preparing this summary, I see that the description in the status-of-the-document section is outdated and no longer accurate; sorry.) - mentions that the XML Representation constraints given in the spec apply after the approriate pre-processing, not before; in some cases conditional inclusion and chameleon pre-processing are explicitly mentioned. - makes a minor change to the schema and DTD for schema documents. (This minor change is all that's left of the old proposal for bug 11354.) If the WG adopts this change, I'll put a document illustrating the changes adopted into the attachments to this bug, for the consideration of the originator.
Since I raised this bug report, I feel obliged to comment on the editorial changes made to solve this bug. I've read the changes made as published, and I find them to be fine. Thanks for making changes (and clarifying the issues involved) at so many places, for closure of this bug. This bug may be officially closed, subject to review by members of the XML Schema WG. (though I seem to be bypassing this step, "If the WG adopts this change, I'll put a document illustrating the changes adopted into the attachments to this bug, for the consideration of the originator." by writing this note now) Thanks. (In reply to comment #10) > A wording proposal intended to resolve this issue is on the server at > > http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11179bis.html > (member-only link) > > This proposal > > - revises the passages which currently mention special conditions for source > declarations which are children of 'schema' elements, or children of 'schema' > or 'redefine' elements. Since children of 'override' do not always > unconditionally map to components, 'override' has not simply been added to the > list of possible parents, but notes have been added to explain that the rules > or special handling in question may apply to children of 'override' as well. > > (Preparing this summary, I see that the description in the > status-of-the-document section is outdated and no longer accurate; sorry.) > > - mentions that the XML Representation constraints given in the spec apply > after the approriate pre-processing, not before; in some cases conditional > inclusion and chameleon pre-processing are explicitly mentioned. > > - makes a minor change to the schema and DTD for schema documents. (This minor > change is all that's left of the old proposal for bug 11354.) > > If the WG adopts this change, I'll put a document illustrating the changes > adopted into the attachments to this bug, for the consideration of the > originator.
RESOLVED: adopt the proposal linked to comment 10 as ammended. Ammendment for the note in 3.6.4.2: Note: If the <attributeGroup> is a child of <override>, and it overrides a corresponding declaration in the ·target set· of its parent, it will also correspond to an attribute group definition as shown below. See Overriding component definitions (<override>) (§4.2.5) for details.
The change agreed upon in the call of 13 May has now been integrated into the status quo document, as amended, so I'm marking this issue resolved. Mukul Gandhi, I think you have access to the status quo document at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html (member-only link) Ideally you should review the new status quo document to check that the changes in question have been made correctly, and then close this issue to signal that you are satisfied with the result, or else reopen it to signal that you are dissatisfied. Since you've already reviewed the changes and expressed satisfaction, this is in some sense a formality; if we don't hear from you otherwise in a week or so, we'll assume remain satisfied with the changes. Thank you for the comment!
I've looked at the changes in status quo document, and all the changes as proposed in the agreements appear to be there in the status quo specification text. As suggested, therefore I'm marking this issue as closed. Many thanks.