Re: XPTr bare names and XPATH id()

"Henry S. Thompson" wrote:
> 
> "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.

But the whole point is: we don't necessarily want to serialize
all the descendants. We're trying to to use XPath to pick *which*
descendants to serialize.

>  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

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/