Compare the different W3C Streaming profiles ACTION-728

As we discussed in TPAC 2010 in the joint call with XSLT working group,  there is streaming XPath subset in XSLT too, but it is different from the streaming XPath subset in Signature.  These difference are because the processing models are different.



Streaming processing of XML Signaturs

Signatures verification can be done in two passes. The first pass is a very cursory pass, in this pass collect the signature element and signing keys from the document. Signatures are often present in the beginning of the document, so this usually a very short pass. At the end of the first pass, take in the IncludedXPath and ExcludedPath from each reference, and construct "state machines" from these Xpaths. 

Then begin the second pass. For this pass parse the document using a streaming XML parser, which generates xml events. Feed these events into a state machine, if the event is accepted by an IncludedXpath, but not accepted by an ExcludedXPath then it is included, in that case pass on this event to a streaming canonicalizer, and then to a streaming digestor.

At the end of the second pass, end up with digests for each reference.





Streaming processor of XSLT templates   http://www.w3.org/TR/xslt-21/#streaming

In XSLT processing the XPaths are not known in advance. The XSLT processor has to be ready to process any XPath that it comes across. So it maintains a context. This context consists of all the ancestors of the current element and some histograms so that it can process the position() function.  The XPath needs to evaluated with only this context and nothing else. This is a fundamental difference from XML Signature model. In XML Signature, the XPaths are known in advance, and being continuously evaluated for every node.  But in XSLT, they are evaluated only once. 

The XPath subset is defined here as what kind of subset can be evaluated with this context. So for example all sideways axis are disallowed by this subset i.e. following, preceding, following-sibling, or preceding-sibling. But the Signature subset allows following, and following-sibling.  

Another big difference is the way this subset is defined. XML signature defines the subset by syntax. Although this kind of definition is simpler to define and understand, it results in XPaths that are allowed in one syntax, but not allowed in another syntax. E.g. /a/b is allowed, but (/a)/b is not allowed in XML signature.  XSLT defines the subset by a "data flow graph". This has restrictions like once you start going up, you can't go down. See the 7 such rules in http://www.w3.org/TR/xslt-21/#streamability-conditions  While XML Signature is very strict in allowing only attributes in predicate, XSLT is much more lax, E.g. /a[b] is not allowed in XML Signature, but is allowed in XSLT, because the rule 4 says that it is ok to go downwards as long you don't revisit a node more than once.

Another difference arising from this evaluation model is that XSLT allows relative XPaths, in fact that is a very important part of XSLT. There is always a current context node, when evaluating the XSLT xpath.  So it allows parent and ancestor axis.





Bottomline: These two subsets have completely different purpose and there is no benefit in making them similar, that will only cripple both the use cases.
However there are subsets whose use cases are similar to XML Signature, i.e. XPaths known in advance and Xpath uses for selection. E.g. WS-Transfer's use case was exactly similar to XML signature.

Pratik

Received on Sunday, 19 December 2010 21:44:50 UTC