Re: Strawman proposal for modified Transform processing for Streamability

Code complexity and performance can be two contradictory requirements. 
Streaming does bring in a lot of code complexity, but that is the price 
that someone has to pay for getting high performance. But we are not 
disallowing simpler DOM based implementations, for which can one can use 
a readily available DOM based XPath engine.

And besides the complexity is not too much.

For parsing
* at first you need to split up the union expression by "|".   i.e. 
break up the    locationPath | locationPath | ..   into individual 
location paths
* then split up each location paths to get individual steps and the 
final predicate.  i.e. break up  / step / step / step .. / step [ 
predicate ]  to get the steps and optional predicate.  Two slashes 
together indicates descendant axis
* the predicate will have an expression involving attribute names  e.g.  
@a = "foo"  and @b > "bar" 
You need to have an expression parsing and evaluating engine to do this.

For executing
While streaming, at each element node, loop through each of the location 
paths, and match up the steps to the current element's ancestors. If 
they match, evaluate the predicate with the current element's 
expression. If that passes too, this element and all its descendants are 
included.  (Unless there are some exclusions)

I agree that this is complex, but there are lot of specs built on top of 
XML Signature, for example Web Services, and there are mission critical 
products on these, and I think people will be willing to put together a 
team of developers if that solves the performance issue.  That said, I 
also fully see the requirement for a minimum dsig profile, which should 
be easy to implement given a DOM and a basic crypto library, of course 
that should not use XPath.
  
Pratik



Sean Mullan wrote:
> Pratik Datta wrote:
>
>> I understand the concern of streaming XPath parsers, but the XPath 
>> subset that I am defining is simple enough, that an implementor can 
>> define streaming XPath engine at least with less complexity than a 
>> canonicalization engine. Also we are not preventing people from using 
>> a regular DOM based XPath engine, which is very readily available.
>
> Yes, but that is contradictory to what we are trying to achieve. I 
> think if we want to create a successful streaming profile, we should 
> make sure that it is something that can be realistically implemented. 
> I don't want XPath to be the C14N of the streaming profile. It seems 
> to me that the onus will be on XML Signature implementors to create a 
> streaming XPath implementation. If that's the case, I think we need to 
> prove that this is not a really difficult task.
>
>> By the way, what is the NodeSelection transform ?
>
> It doesn't exist, it was just an example of a node selection Transform 
> that would be streaming-friendly and not necessarily tied to XPath 
> (perhaps one could use XPath as the implementation though). I admit I 
> haven't really given this much thought and it may be the case that 
> anything we come up with on our own would be similar enough to XPath 
> expressions that it wouldn't make much sense.
>
> --Sean

Received on Thursday, 4 September 2008 19:19:03 UTC