Re: Strawman proposal for modified Transform processing for Streamability

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.

Pratik



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
>
>
>