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@w... 
> [mailto:xmlschema-dev-request@w...] On Behalf Of Henry S. Thompson
> Sent: 12 October 2009 16:40
> To: XMLSchema at XML4Pharma
> Cc: xmlschema-dev@w...
> 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@i...
>                        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-----
>