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 15:40:18 UTC