- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Mon, 19 Oct 2009 10:07:03 -0400
- To: "ext Henry S. Thompson" <ht@inf.ed.ac.uk>
- 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>
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 UTC