- From: Michael Kay <mike@saxonica.com>
- Date: Mon, 12 Oct 2009 17:48:09 +0100
- To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>
- Cc: <xmlschema-dev@w3.org>
I agree with all of this, but it leaves the question of xs:redefine. I suspect, but without testing(!) that the strategy can be extended to xs:redefine as follows: (a) if redefinition for a namespace is required, create a new schema document with that targetNamespace that invokes the (previous) primary schema document for that namespace using xs:redefine, and contains all the redefinitions needed. (b) change the driver document to refer to the redefinition documents introduced in step (1) in place of the (previous) primary shcema documents. A similar approach might also work reliably for "chameleon include". But better advice is not to use redefine or chameleon include. Regards, Michael Kay http://www.saxonica.com/ http://twitter.com/michaelhkay > -----Original Message----- > From: xmlschema-dev-request@w3.org > [mailto:xmlschema-dev-request@w3.org] On Behalf Of Henry S. Thompson > Sent: 12 October 2009 16:40 > To: XMLSchema at XML4Pharma > Cc: xmlschema-dev@w3.org > Subject: Re: Escalation mechanism for different > interpretation of W3C XML-Schema specification ? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stimulated in equal measure by this thread, and a request > from the XML Security WG [0], I came up with my personal > 'best practice' guideline for schema document design for > multi-namespace schemas. I include the core bit below -- for > the full context and a worked example, see my reply to the > DSIG WG [1]. > > ht > > [0] > http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0019.html > [1] > http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0023.html > - ------------------------- > HST's best practice guide for multiple-namespace schema composition > > It's helpful in discussions of this sort to be careful with > vocabulary: > > Schema document: An XML document in the W3C XML Schema namespace > Schema: An abstract data object, typically composed from one or more > schema documents according to the rules given in the W3C XML > Schema specs. > > A schema document specifies either one or no target namespace. > > A schema may well contain element & attribute declarations > and/or type definitions for many target namespaces. > > The W3C XML Schema specs provide a number of mechanisms for > assembling the schema documents needed to construct a schema > for a particular validation episode: > > 1) the schemaLocation attribute on xs:include elements. > 2) xsi:schemaLocation (in the instance to be validated); > 3) the schemaLocation attribute on xs:import elements; > 4) the namespace URIs themselves (in the instance to be validated, or > from the namespace attribute on xs:import elements); > > Without going into the details of what's optional and what's > required, or of the range of choices implementations exhibit, > here's my recommendation for multi-namespace schemas: > > 1) For each namespace in your language, there should be one primary > schema document. It may be the only schema document for that > namespace, or it may use xs:include (which must have a > schemaLocation attribute) to allow for modular development by > including multiple as-it-were secondary schema documents; > > 2) Whenever reference is made to names in another namespace from a > primary or secondary schema document, use an xs:import _without_ a > schemaLocation attribute; > > 3) Create a driver schema document, whose target namespace is the > namespace of the (most common) document element of instance > documents in the language. It should contain an xs:include of the > primary schema document for that namespace, and xs:imports for all > the other namespaces, _with_ schemaLocation attributes pointing to > the primary schema documents for those other namespaces. > > Then, by passing the location of the driver schema document > to schema validation tools and/or by including an > xsi:schemaLocation attribute on the document element of > instances to be validated which associates the target > namespace of the driver schema document with its location, > you will get the behaviour you need from all the > tools/implementations I am aware of. > > Schematically, this looks like > > driver.xsd -- TNS = http://www.example.org/rootNS > /|\ > / | \ > / | \ > / | \ > xs:include | \ > schemaLoc= | \ > / | \ > / xs:import \ > / NS=...NS2 \ > / schemaLoc= \ > / | xs:import > / | NS=...NS3 > / | schemaLoc= > / | \ > primary1.xsd primary2.xsd primary3.xsd > TNS=...rootNS TNS=...NS2 TNS=...NS3 > / \ /|\ > / \ / | \ > / \ / | \ > / \ / | \ > xs:import xs:import / | \ > NS=...NS2 NS=...NS3 xs:include | \ > schemaLoc= | \ > / | \ > 3.1.xsd | \ > xs:include \ > schemaLoc= \ > | \ > 3.2.xsd \ > xs:include > schemaLoc= > | > 3.3.xsd > > - -- > Henry S. Thompson, School of Informatics, University > of Edinburgh > Half-time member of W3C Team > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) > 131 650-4440 > Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail really from me _always_ has this .sig -- mail without > it is forged spam] -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFK0021kjnJixAXWBoRAmPMAJ9dLLKZsj+r2y/tUtIsJ/wAjuL0kQCfWwzT > LqnqG7FgzH5zwP3XMIrNsb4= > =vK80 > -----END PGP SIGNATURE----- >
Received on Monday, 12 October 2009 16:48:52 UTC