W3C home > Mailing lists > Public > public-xmlsec@w3.org > July 2008

Re: Some strawman ideas concerning <ds:Transforms>

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
Message-ID: <20080723131509.GL503@iCoaster.does-not-exist.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:54 GMT