RE: XPTr bare names and XPATH id()

Hi Henry,

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Henry S. Thompson
Sent: Friday, June 09, 2000 6:38 AM
To: John Boyer
Cc: connolly@w3.org; Joseph M. Reagle Jr.; Daniel Veillard;
w3t-tech@w3.org; w3c-ietf-xmldsig@w3.org
Subject: Re: XPTr bare names and XPATH id()


"John Boyer" <jboyer@PureEdge.com> writes:

> Oops, yes I used incorrect terminology.  This replacement should be
> satisfactory:
>
> Furthermore, as I pointed out to the dsig group yesterday, and with which
> you indicate agreement below, we are free to process an Xpath node-set or
> XPointer location-set in any manner necessary.  Therefore, the XPointer
> URI="#E" can
> be processed by XPath serialization (or by the new c14n) by processing
> E plus all nodes that have E as an ancestor.  In other words,
> subtree(id("E")).

I agree entirely, up to the last few lines.  I think it is
unnecessary and indeed somewhat misleading to define your
serialisation in terms of your definition of subtree.  The flattened
set of all descendants has the wrong shape.  It makes serialisation
non-recursive, i.e. you can't say: to serialise an element node (an
XPointer result), do this, that, then serialise its attributes, then
do blah, then serialise its daughters in order, then do zyzzy.  I
suggest that that's precisely what you want, your own, recursively
specified, definition of 'serialisation'.  That's why I brought up
'string-value': I think the definition of 'serialisation' should be
very similar to that of 'string-value'.  Doing the definition in terms
of node sets actually makes it harder, in my opinion.

<john>
The use of node-set doesn't make anything harder. At any point in the
lifetime of a node-set, there must be sufficient internal data structures
necessary to move in along any axis of the parse tree in order to do the
next location step.  The information isn't lost.

The genesis of the view of node-set as a set of nodes began around last
August at a face to face meeting of the dsig group when I presented on the
use of Xpath to perform document subsetting, which solves lots of problems
related to digital signatures.  I'm not going to reiterate the months of
email explanations pertaining to the idea, nor the public specifications of
how it works [1,2], but I will reiterate the point as made in a recent email
by Dan Connolly [3], we're using the notion of set to specify *which*
descendants to serialize, and which to exclude.

Finally, it should be obvious from the archives that I agree with your
definition of the serialization as a recursive process (trees adhere well to
recursive definitions, after all).  Yesterday (and into this morning) I went
to extra lengths to ensure that this recursive nature was clearer than ever
in the new c14n draft, and that the recursive descent was being used in
combination with set membership to decide, for each node, the text that is
generated [4].  It should be clear from the description that an element's
descendants are visited even if the element is omitted from the node-set.

[1] http://www.w3.org/TR/xmldsig-core/
[2] http://www.w3.org/TR/xml-c14n
[3]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0248.html
[4]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000AprJun/0246.html

John Boyer
Software Development Manager
PureEdge Solutions Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com

</john>

ht
--
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Friday, 9 June 2000 12:53:30 UTC