RE: Compatibility story for RetrievalMethod and Reference in v2

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