- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Sat, 18 Sep 1999 22:46:35 -0400
- To: w3c-ietf-xmldsig@w3.org
- cc: dee3@us.ibm.com
I've been looking at XPath (9 July 99) and XPointer (9 July 99). Maybe I'm just confused but I'm not at all sure that, by themselves, they are what we want as a basis to implement exclude or include or much of anything. Maybe I'm all wrong and have just missed some crucial bit and someone can enlighten me... It seems to me that a "node" in XPath is really a pointer into the full original XML tree because you can always apply operations to a node that find children, ancestors, attributes... Many XPath operations produce unordered node sets... So, for example, a descendent-or-self::* expression produces something like a node set of the root node and every node in the tree (except for attribute or namespace nodes)... If you then apply predicates to knock out some signature element nodes, for example, so they can be added later or whatever, what exactly do you have? Seems like you have this possibly huge unordered set of nodes, all of which are effectively pointers into the original complete XML tree... So what then? Where does it say that magically, on return from the xptr, a new string is created based on all the nodes in such a node set without the nodes not in the node set? A node set isn't a string. XPointer doesn't help all that much, as far as I can see. It is supposed to return a reference to a part or parts of an XML dcoument. I guess an unordered set of nodes is that all right. But what does it mean to sign such a set (obviously it can be canonically ordered in any one of several ways...)? In fact, what does it mean to sign even a single "node" as returned by XPath or Xpointer? Does signing a node include its attributes? descendents? There is a "string" function defined in XPath which claims to return the "value" of a node which is defined to include all its descendents (see section 5, Data Model). You could imagine a function that would take an unordered node set and pretty-print it back into XML which I guess would do the trick. (But the examples that have been given in the past don't seen to encompass, for example, a filter that wanted to mask out one or more attributres. To do that, you would need to expand the node set to include all attribute nodes.) And it seems to me that as you are reconstituting the filtered document you have lost where the original namespace declarations were. Even if you add in namesapce nodes, they are defined to exist everywhere a namespace declaration is in scope, not just where the declaration was in the original (see 5.4, Namespace Nodes). XPath sounds to me like it is written assuming DOM handling where each node knows that name space it is in as a URI, etc., and reconstituting a string from its output would force somthing close to DOM canonicalization. XSLT seems more appropriate since it can explicitly take an XML document and return a transformed XML document. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 914-276-2668 dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-784-7913(work) dee3@us.ibm.com Carmel, NY 10512 USA
Received on Saturday, 18 September 1999 22:46:48 UTC