Re: Will XPath/XPointer Do It?

I think the important thing is that  we want to sign byte streams. If given
an XPointer span we can simply and unambiguously get a corresponding byte
stream without any implicit or explicit dependence on the rest of the
document, we should probably be fine. What would be nice, is to get the
corresponding parts of the original byte stream without it having been
translated into and out of DOM. Without this, use of XPointer seems to
imply full canonicalization. 

Peter

At 06:58 AM 9/19/99 -0400, you wrote:
>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 Monday, 20 September 1999 16:11:53 UTC