- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 23 Jul 2008 15:15:09 +0200
- To: Sean Mullan <Sean.Mullan@Sun.COM>
- Cc: public-xmlsec@w3.org
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? > > > -- Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 23 July 2008 13:15:46 UTC