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

Re: Multiple schema best practices?

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Mon, 19 Oct 2009 10:07:03 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, 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: <5ADB6D36-34C2-4987-9B56-47752D684DBE@nokia.com>
To: "ext Henry S. Thompson" <ht@inf.ed.ac.uk>
Henry

Thank you very much for the detailed reply outlining both the correct  
terminology and techniques for dealing with multiple schema documents  
as part of a single schema. Your  message is very useful to our WG and  
a great help.

The XML Security WG  agreed on last week's teleconference to adopt the  
change you suggest (to have a primary schema document), with  
corresponding ACTION-396.

Thanks!

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG



On Oct 12, 2009, at 7:29 AM, ext Henry S. Thompson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> message.
>
> 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
> 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
>
> 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"
>               targetNamespace="http://www.w3.org/2000/09/xmldsig#"
>               version="0.1" elementFormDefault="qualified">
>
>  <include
>   schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd 
> "/>
>
>  <import namespace="http://www.w3.org/2009/xmldsig11#"
>   schemaLocation="http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/xmldsig11-schema.xsd 
> ">
>   <annotation>
>    <documentation>To be replaced with a permanent location in due  
> course.</documentation>
>   </annotation>
>  </import>
>
> </schema>
>
> 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# 
> ">
>     <SignedInfo>
>     <CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11 
> "/>
>     <SignatureMethod
>          Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa- 
> sha256"/>
>     <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
>       <Transforms>
>         <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
>       </Transforms>
>       <DigestMethod Algorithm="http://www.w3.org/2001/04/ 
> xmlenc#sha256"/>
>       <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue>
>     </Reference>
>   </SignedInfo>
>     <SignatureValue>...</SignatureValue>
>     <KeyInfo>
>       <KeyValue>
>        <ECKeyValue xmlns="http://www.w3.org/2009/xmldsig11#">
>         <NamedCurve URI="urn:oid:1.2.840.10045.3.1.7" />
>         <PublicKey>
>            vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7UfgCf8KDO7AtTOsGJK7/ 
> TA8IC3vZoCy9I5oPjRhyTBulBnj7Y
>         </PublicKey>
>        </ECKeyValue>
>       </KeyValue>
>     </KeyInfo>
>   </Signature>
>
> Hope this helps,
>
> ht
>
> [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]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFK0xMokjnJixAXWBoRAq8wAJ9W2I/GOvBTqkxvRENAc8EBebcCoQCePPfj
> Sv++QhDcL9HMo4faLJyfOas=
> =lEVY
> -----END PGP SIGNATURE-----
Received on Monday, 19 October 2009 14:16:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:44:00 GMT