I would like to see if we can achieve this streaming hint with forward compatibility.
By that I mean, we put in the hint in such a place that older implementations can still verify such a signature by ignoring the hint, whereas newer implementations can take advantage of this hint and do streaming.

If we add a completely new transform, an older implementation will error out. So how about adding it as a new attribute to an existing transform?  Implementations will probably ignore unknown attributes. Or maybe add a new transformation parameter?

The main transform that causes all the headaches is the XPath Filter transform. XPath is too generic, and given an XPath it is hard for an implementation to figure out what it intends to do. Most of the XPath expressions that I have seen are very simple, fall into one of the following types
 a) include/exclude elements (and all descendants) whose name is foo
 b) include/exclude elements (and all descendants) which has an attribute foo=bar
 c) exclude attributes whose name is foo
If we can provide this alternative description of this XPath transform as a hint, then an implementation would not need to run a full fledged XPath engine, but just use some simple logic.

Enveloped Signature transforms is pretty streamable.

C14N transform can be streamed, if we don't have to worry about namespaces and xml: attributes in missing ancestors - maybe there could be a hint about them.

Pratik


Thomas Roessler wrote: 
On 2008-07-23 09:11:29 -0400, Sean Mullan wrote:

  
It seems like it is definitely worth exploring. So, as I understand, 
something like:

<Transforms>
  <Transform Algorithm="http://www.w3.org/.../streaming-transform"/>
</Transforms>

would trigger the implementation into expecting a streaming
node-set output from the URI dereferencing.
    

Yep, that's the basic idea.

  
I would need a little more time to think about this, but I think the JSR 105 
API should be able to be extended to accomodate a model like this.

--Sean

Thomas Roessler wrote:
    
Some quick notes on some ideas that came up in the last hour or so
of the face-to-face, on how to use ds:Transforms as an extension
point:

- We could define an "assertion transform" that isn't really a
  transform, but permits an implementation to make certain
  assumptions -- either about the structure of the data, or about
  the structure of further transforms within the chain.

- Assuming that we define an extended transform model (which doesn't
  use node-sets, but operates on some other representation of
  subsets of the infoset), we could define a special-purpose
  transform that switches implementations into this model without
  breaking the compatibility story.
    More specifically, implementations could be entitled to lazily
  dereference the URI parameter in a ds:Reference, and not even
  generate a node-set when the transform in question is the first
  one.

- There's also the pattern of a dereferencing transform (known from
  WS-Security).

Thoughts?