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

Multiple schema best practices?

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Fri, 9 Oct 2009 10:39:44 -0400
Message-Id: <9B6BC0EF-6A4F-4C10-A075-85A1622C0346@nokia.com>
To: W3C XML Coordination <w3c-xml-cg@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Scott Cantor <cantor.2@osu.edu>, Ed Simon <edsimon@xmlsec.com>, XMLSec WG Public List <public-xmlsec@w3.org>
[cc'd public XML Security WG list]

The XML Security WG is creating a 1.1 version of XML Signature that  
builds on the original XML Signature, Second Edition  
Recommendation[1]. As a result there is a namespace for the XML  
Signature, Second Edition specification as well as a new namespace for  
1.1 specific extensions, such as identification of new elements that  
can be added as children of an existing element (e.g.  
DEREncodedKeyValue as a child of KeyInfo), as well as new algorithm  

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  

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)?


regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

[1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm

[2] http://www.w3.org/2008/xmlsec/track/issues/142

[3] http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0012.html

This message should complete ACTION-384.
Received on Friday, 9 October 2009 14:40:34 UTC

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