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

Re: Strawman proposal for modified Transform processing for Streamability

From: Pratik Datta <pratik.datta@oracle.com>
Date: Wed, 03 Sep 2008 17:29:32 -0700
Message-ID: <48BF2BEC.3060904@oracle.com>
To: cantor.2@osu.edu
CC: public-xmlsec@w3.org
I have a particular streaming XPath processing model in mind, (one that 
only needs to keep the current element, its attributes, and the ancestor 
elements in memory, and does not require a state engine), and XPath 
subset that I have defined is a direct result of this constraint.

So far all the Xpath expressions that I have encountered are part of 
this subset, but it is definitely possible that we will come across 
something that doesn't fit. I am not sure what to do in that case.  I 
don't want to go down the path of having many different profiles, that 
would make adoption of the signature spec much harder - ideally I would 
like to see if we can arrive at single v1.1/v2 spec, which solves the 
performance issues and can be used by 99% of the current users. For the 
remaining 1% we may take the approach of telling them to use the current 
signature spec.


Scott Cantor wrote:
>> Also ebXML needs to use a condition in their XPath expression, because
> they
>> want to exclude from the signature, all header elements whose actor is
>> nextMSH. That's why I included attribute based predicates, in the XPath
>> subset.
> Isn't that kind of a slippery slope? I imagine most of the features we think
> are complex were put there to address somebody's use case. If we want
> something simpler, the criteria probably shouldn't be based around the fact
> that *somebody* thinks it's useful.
> I am swayed by the idea that the expression language ought to be XPath
> compatible though, unless there's a good reason to make it incompatible.
> Streaming is of no interest to me, for example, so being able to use a
> standard library that exists already is a plus.
> -- Scott
Received on Thursday, 4 September 2008 00:30:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:09 UTC