This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There's some missing text in 4.2.4 in the explanation of how xs:override works ("4.1.1 Let D2′ be a <schema> information item obtained by .). But I think the intent is to use the stylesheet in Appendix G to do a transformation at the schema document level. The transformation, however, seems to be designed for a syntax that doesn't match the final syntax of xs:override - it assumes the existence of an xs:replace element. More seriously, I think there is a big usability problem with this mechanism. If you are trying to define a local variant of a complex schema (say FpML), then it won't be possible to override definitions in any module (schema document) of that schema other than the top-level module. For example, if the base schema has a typical structure with a root module schema.xsd that includes many other modules a.xsd, b.xsd, c.xsd (many of which probably include another module called lib.xsd), then it's hard to see how a customisation layer can override a definition in b.xsd or lib.xsd. If you attempt an xs:override of that module, you will end up with an inconsistent schema that contains both the original and overridden versions of the component. Working at the schema document level does have the merit that the specification is very clear about what happens (much clearer than with xs:redefine). But that's not much use if the facility doesn't achieve its objectives. It might be possible to rescue things by developing the approach. Let's say that there exists a mapping of URIs to schema documents, and that xs:include and friends work by applying this mapping. Then let's say that xs:override changes this mapping, so for any URI it can define a modified schema document. Then if the customization layer does an include on fpml.xsd, the effect is that all includes/imports etc processed while expanding this reference use the modified mapping, that is, they interpret URIs as referring to the modified schema documents. However, I'm wary of doing this at a stage where we ought to be finishing the spec. The pessimist in me says it would be more prudent at this stage to pull the plug on this facility and try and do it properly next time round, along with the rest of the schema composition story.
Thank you for the heads-up on the garbled text in section 4.2.4. A quick review of the source shows that when the WG adopted the relevant change proposal [1] on 6 June 2008, some but not all of the changes included in the proposal were included in the status quo, including the one that deleted the end of the sentence to which you refer. Others were not included, owing to a clerical error made by me, including the change group that inserted the replacement text for the end of that sentence. (We normally have a deletion and its replacing insertion marked with the same identifier, to ensure that this doesn't happen; these had different identifiers, for reasons I won't bother to reconstruct or rehearse here. The same clerical error caused the inclusion of the wrong stylesheet in the appendix; the correct stylesheet refers to xs:override, not to xs:replace. The working group may wish to issue a corrected last-call draft with these errors corrected. On the utility of xs:override, I think you are right that there will be cases where it is less helpful than one might wish. But I am reluctant to remove it, if only because that would raise the question of removing the deprecation note against redefine, which I regard as the single most constructive step the WG has been able to take w.r.t. schema composition. [1] http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b4767.html
Created attachment 571 [details] Corrections to last-call draft of 20 June 2008 As noted already, a clerical error has introduced a number of errors into the Last-Call working draft of XSD 1.1 Structures. The attachment shows corrections for these errors, in the form of a colored diff showing material that should be deleted or added to the last-call draft.
Michael Kay writes: > More seriously, I think there is a big usability problem with this > mechanism. If you are trying to define a local variant of a complex > schema (say FpML), then it won't be possible to override definitions > in any module (schema document) of that schema other than the > top-level module. For example, if the base schema has a typical > structure with a root module schema.xsd that includes many other > modules a.xsd, b.xsd, c.xsd (many of which probably include another > module called lib.xsd), then it's hard to see how a customisation > layer can override a definition in b.xsd or lib.xsd. If you attempt an > xs:override of that module, you will end up with an inconsistent > schema that contains both the original and overridden versions of the > component. I think it's worth observing that mechanisms that override or redefine at the component level are more likely to be effective in cases where multiple modules (schema documents) are composed and the intention is to further refine or override the definition resulting from that composition. Regardless of the details, doing this in a stylesheet seems to require a transform that operates on all of the input modules, and that to some degree reconstructs the partial orders and derivation chains the result from composing such modules. By doing redefine and/or override at the component level, one at least has the opportunity to define the override operation in terms of the existing rules for composing the other input modules. (and I grant that those rules aren't currently as clear as we'd like them to be.) I am not specifically asking to reopen the decision to adopt a source-transform based override mechanism, though I have always had my doubts that it is the best way to go. If it some point a decision is made to reconsider the composition story, I hope careful consideration will be given to the tradeoffs involved in going with source-based vs. component-based approaches (and I do think there are advantages to each.) Noah
Wondering whether we can get away by saying roughly: "Whenever a schema document S=source is overridden by O=override, then any <include> or <import> to S are as if they were to O, unless the <include> or <import> was meant for a namespace different from that of O (think chameleon include/override). If S is overridden by multiple documents, then use any one of them as O." This way: - It's still at the syntax level, so the rule is deterministic. (We had difficulties specifying redefinition rules at the component level.) - It helps solve many more use cases than the current rule, in particular, if A includes B, B can still be overridden. (The pervasiveness.) (The current rule will most likely make this case invalid.)
I'm always a bit averse to "as if" specifications, because they always leave a lot of room for interpretation. But I think it probably is possible to make the facility work. The big question is how one overrides definitions in multiple namespaces. One mechanism that might work is to require xs:override to appear like this <xs:schema> <xs:override schemaLocation="abc.xsd"/> <xs:import namespace="one.uri" schemaLocation="one-override.xsd"/> <xs:import namespace="two.uri" schemaLocation="two-override.xsl"/> <xs:element name="eeee"/> </xs:schema> Then we say that if xs:override appears in a schema document, it must be the first child of the xs:schema element; only one xs:override element is allowed in a schema document, and everything else in the schema document whether present directly or imported/included from elsewhere is there to override (or supplement) what is present in the overridden schema documents. The processing is then (ignoring any interaction with xs:redefine for the moment): (a) in the graph of schema documents, where the arcs joining them are xs:include, xs:import, and xs:override elements, there must be no cycle that includes an arc labelled xs:override. (b) in this graph if any two nodes M and N are connected by a path that includes an xs:override arc, then there must be no path from M to N that does not include this arc (c) it is thus possible to partition the schema documents in the graph into a tree of schema-document-sets where A is the parent of B in the tree if A contains an xs:override element that refers to a document in B. Call this the override tree. (d) within this tree, every schema document is transformed as follows: for every top-level declaration D, if an ancestor in the override tree contains a schema document that contains a top-level declaration with the same kind and expanded name as D, then D is deleted from the schema document (e) the entire graph of schema documents is then processed as if the xs:override elements were xs:include or xs:import elements. One way to handle redefine is simply to ban mixing it with override: it is an error if the override tree includes an xs:redefine element.
The WG approved the base proposal for 6021: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6021.html With instructions for the editors to carefully consider the following comments from Michael Kay and Noah Mendelsohn: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jan/0013.html http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jan/0015.html A further late-breaking comment from Sandy (it's not clear whether there was consensus to consider it): http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jan/0018.html Editorial proposals to be decided by WBS by COB Tuesday: http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.ep29.html (optional) http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.ep29k.html http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.ep30.html
The XML Schema WG, in its call of 16 January 2009, accepted the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6021.html (member-only link) as resolving this issue. The editors are expected to prepare a follow-on proposal reflecting some of the suggestions received in email discussion of the proposal, but the issue is regarded as resolved in any case. I'm updating this record accordingly. Michael, it would be helpful if as the originator of the issue you would indicate your satisfaction or otherwise with the WG's disposition of the issue by closing or reopening it in the usual way. If we do not hear from you in two weeks, we will assume you are content.