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.

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 09:38:23 UTC