RE: New XPath Filter Transform

Hi Christian,

My first read of this is that without a reissue of the XML DSig REC, we wouldn't be able to do it this way.  

Under this formulation, we leave the concept of a node-set travelling from transform to transform and instead have a 'labelled' node-set (or perhaps more desirably, a labelled parse tree).

Also, at first glance I don't understand why set subtraction wouldn't be the better method.

How many labels can a node have?  How do we know when to change the labelled node-set into something c14n can understand?

Also I don't understand what the 'dont-include-self-but-search-forward' label does. Perhaps for each label you could describe exactly what it does rather than relying on the label name (just in case I'm missing something in each).

Finally, note that we are currently discussing how to optimize what, in my opinion, are simpler cases involving only one transform. The method you are describing seems that it might only be better at optimizing sequences of multiple transforms.  Could you demonstrate how it could accommodate the include/exclude that are currently defined?

Thanks,
John Boyer



-----Original Message-----
From: Christian Geuer-Pollmann
[mailto:geuer-pollmann@nue.et-inf.uni-siegen.de]
Sent: Sunday, March 17, 2002 11:27 AM
To: John Boyer; Gregor Karlinger; merlin
Cc: TAMURA Kent; w3c-ietf-xmldsig@w3.org; reagle@w3.org
Subject: RE: New XPath Filter Transform


Hi John,

from what I understood from your mails is that you need a transform which 
allows to easily iterate (tree-traversal) over a structure like a DOM tree 
without evaluating an costly XPath expression against every node in the 
XPath node set.

First of all, if the document [1] should become stable in it's current 
processing model, I would add a comment that this transform only makes 
sense as a first Transform after dereferencing a nodeset or after 
transforms which produced an octet stream which is reparsed. Why? Because 
if I e.g. have an XMLDSIG 1.0 XPath transform prior the new XPath filter, 
the results of the original transform are discarded.

But now to my approach: For me, it's not that clear how to use a sequence 
chain of multiple http://www.w3.org/2002/02/xmldsig-xpath-filter transforms 
to select the correct subset. But anyhow, I recently solved a similar 
problem and I thing that my solution would work in an alternative form of 
your filter.

Let's discuss the example in terms of DOM, even if the input is an XPath 
node set.:

We 'label' the tree with three different labels:

1.) The "dont-include-any-descendant-or-self" label
2.) The "include-descendant-or-self-and-search-forward" label
3.) The "dont-include-self-but-search-forward" label

Let's take Gregor's example to show how this transform works:

The input document is:

<root>
  <child1>
    <grandChild1/>
    <grandChild2/>
  </child1>
  <child2>
    <grandChild1/>
    <grandChild2/>
  </child2>
</root>

And I want to get as output of the transform

<child1>
    <grandChild1/>

  </child1>

Which means all descendant-or-selfs of child1 but not it's grandchild2:

<Transform 
URI="http://www.w3.org/2002/03/xmldsig-the-next-alternative-xpath">

 <!-- don't output / but descend -
      you maybe find subtrees to be outputted -->
 <XPath Filter="dont-include-self-but-search-forward">
  /
 </XPath>

 <!-- We output the subtree under child1 but maybe
      something inside this subtree is omitted -->
 <XPath Filter="include-descendant-or-self-and-search-forward">
  /root/child1[1]
 </XPath>

 <!-- don't output grandchild2 and don't descend -
      you won't find subtrees to be outputted -->
 <XPath Filter="dont-include-any-descendant-or-self">
  /root/child1[1]/grandchild2
 </XPath>
</Transform>

Does this makes sense to you? You can do the same optimizations: You only 
evaluate 3 XPath expressions, you make a simple tree traversal and you 
don't descend into subtrees which only contain unselected information.

Regards,
Christian

[1] http://www.w3.org/Signature/Drafts/xmldsig-xpath

Received on Monday, 18 March 2002 13:24:35 UTC