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

Re: Will XPath/XPointer Do It?

From: Daniel Veillard <Daniel.Veillard@w3.org>
Date: Sun, 19 Sep 1999 06:58:36 -0400
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: w3c-ietf-xmldsig@w3.org, dee3@us.ibm.com
Message-ID: <19990919065836.C32047@w3.org>
On Sat, Sep 18, 1999 at 10:46:35PM -0400, Donald E. Eastlake 3rd wrote:
> 
> 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...

  Hum, guess it's time to jump in ...

> It seems to me that a "node" in XPath is really a pointer into the
> full original XML tree

  XPath is defined in term of the Infoset ... I don't know what 
you mean by the "full original XML tree". If there is an original form
that's the entity(ies) content. Once parsed it should be available as
an infoset, XPath and XPointer work on that Infoset.

> 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)... 

  yes and they are ordered by the document order !

> 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.

  But the string() value applied to an element is quite precisely
defined, recheck xpath ...

> 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

  You can perfectly build XPointer expressions to select one node 
a sequential range of node or go finer and select at the caracter level
Again the semantic of those operation is defined in a quite precise way
if there is parts left to interpretation, please send back feedback to
the comment list linked from the draft "Status of this document" section.

>  a single "node" as returned by XPath or Xpointer?  Does signing a node

  I would define it as signing the part of the entity containing
the given node from the "<" of the beginning of that node and up
to the ">" of the closing declaration. XPointer/XPath is a mean to
design those nodes, but not the proper way to retrieve the content
for signing.

> 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.

  XSLT is completely based on XPath and then on the infoset view of
the document. Think of XPath/XPoint as generic ways to describes
your nodes or ranges. Don't try to use them to retrieve the content
to sign. You will still have to keep the entity original content
around for this operation. When building your infoset, just keep
the correspondance between your nodes and the original entity indexes.

 Daniel

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
Received on Sunday, 19 September 1999 06:58:42 GMT

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