Compatibility story for RetrievalMethod and Reference in v2

Quick summary of the discussion just now:


1. RetrievalMethod is broken since the target elements (children of  
ds:KeyInfo) don't have ID attributes.  Since the content model of  
ds:KeyInfo is extensible, it is possible to replace these elements  
with elements in a new namespace *without* having to break the overall  
schema.  That would (a) let us add the necessary ID attributes, and  
(b) permit assorted fixes to the content models of these elements.


2. Reference has two interesting extension points:

(a) URI is an optional attribute.  There can only be one ds:Reference  
element without a URI attribute according to the current spec;  
however, that constraint is not enforced in the schema.  Therefore, we  
could move the URI from that attribute into a special-purpose transform.

(b) Type is optional and largely unused.  That attribute could be used  
to describe the content model of what is being referenced in a  
different way, to (e.g.) discern between octet-stream, node-set, and  
the-other-thing (whatever that be in detail).  That would also solve  
the current ugliness around dispatching between node-set and octet- 
stream based on URI's same-document-ness.


These two points are orthogonal to each other. Together, though, they  
mean that the two reasons we had so far for changing namespaces in 2.0  
can be avoided, making it easier to plug a vesion 2.0 of signature  
into formats like SAML which are unlikely to change their own schemas  
(and include a hardwired ds:Signature).


--
Thomas Roessler, W3C  <tlr@w3.org>