- From: Scott Cantor <cantor.2@osu.edu>
- Date: Wed, 13 May 2009 16:45:12 -0400
- To: "'Thomas Roessler'" <tlr@w3.org>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
Thomas Roessler wrote on 2009-05-13: > 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. Agreed. > 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. Per discussion, since this gets treated as somewhat of an application-specific case, and for uniformity with the existing references, I think it's an improvement to leave the URI of the root of the tree you're doing the new simplified subsetting/c14n of inside the Reference. > (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. Also per discussion, the existing language for the Transforms chain defines two possible inputs/outputs for a Transform, a XPath node set and an octet stream. Code today is required to understand what Transforms take as input and provide as output in order to handle the implicit conversions between them. Further, code today optimizes the dereferencing of the URI until it knows what the first Transform requires. So my suggestion rather than changing how Type is interpreted is to define a third "input" option which would be perhaps a URI. If the first transform takes that input, then the code is trivial, the Reference hands it to the URI. The output of the new transform would be an octet stream (for digesting). I think everything "just works" if you do that, and if there are concerns about preventing other transforms from appearing, it's simple to write text to disallow it. -- Scott
Received on Wednesday, 13 May 2009 20:45:54 UTC