W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

Will XPath/XPointer Do It?

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Sat, 18 Sep 1999 22:46:35 -0400
Message-Id: <199909190246.WAA15947@torque.pothole.com>
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.

 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 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT