- 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>
-----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, 12 October 2009 11:30:28 UTC