[Bug 6021] New: Stylesheet for xs:override

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6021

           Summary: Stylesheet for xs:override
           Product: XML Schema
           Version: 1.1 only
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: mike@saxonica.com
         QAContact: www-xml-schema-comments@w3.org


There's some missing text in 4.2.4 in the explanation of how xs:override works
("4.1.1  Let D2&#8242; 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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 2 September 2008 21:41:52 UTC