W3C home > Mailing lists > Public > public-xmlsec@w3.org > October 2009

Re: Multiple schema best practices?

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 12 Oct 2009 12:29:44 +0100
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: W3C XML Coordination <w3c-xml-cg@w3.org>, Scott Cantor <cantor.2@osu.edu>, Ed Simon <edsimon@xmlsec.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <f5btyy43l5j.fsf@hildegard.inf.ed.ac.uk>
Hash: SHA1

Frederick Hirsch writes:

> The question raised in the WG  is how best to implement schema
> processing with multiple schemas - is it necessary for a schema
> validator to be explicitly aware of multiple schemas, or is there a
> practice to allow a validator to take a single schema (that uses
> import or some other method as needed) [2[3]. It may be the case that
> a validator should be aware of multiple namespaces and associated
> schemas.

The W3C XML Schema specs are explicitly designed to support the
definition of XML languages which use elements and attributes from
multiple namespaces, and provide detailed guidelines for validator
implementations in this area.

> Should we recommend or be aware of any specific techniques for schema
> validation involving multiple schemas? Are any best practices recorded
> for either writing a specification that involves multiple namespaces
> or for implementations involving a specification that requires
> multiple namespaces (and associated schema definitions)?

> This message should complete ACTION-384.

I've reviewed your current draft [1] and the other references in your

As far as I can see you have a very common design, and should not have
any implementation problems.

It's helpful in discussions of this sort to be careful with

  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          \

In the particular case of DSIG 1.1, you have already done parts (1)
and (2) of my recommendations.  All you need now is to publish the
driver schema document, which will look like this:

<schema xmlns="http://www.w3.org/2001/XMLSchema"
               version="0.1" elementFormDefault="qualified">


  <import namespace="http://www.w3.org/2009/xmldsig11#"
    <documentation>To be replaced with a permanent location in due course.</documentation>


For instance, using that schema document both the example from section
2.1 of the draft spec. [2] and this modified version can be
schema-validated successfully:

   <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
     <CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
     <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
         <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> 
       <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> 
        <ECKeyValue xmlns="http://www.w3.org/2009/xmldsig11#">
         <NamedCurve URI="urn:oid:1.2.840.10045.3.1.7" />

Hope this helps,


[1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm
[2] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-o-Simple
- -- 
       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]
Version: GnuPG v1.2.6 (GNU/Linux)

Received on Monday, 12 October 2009 11:30:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:12 UTC