W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

Re: XPTr bare names and XPATH id()

From: Dan Connolly <connolly@w3.org>
Date: Fri, 09 Jun 2000 10:07:50 -0500
Message-ID: <39410846.48F6FEDC@w3.org>
To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
CC: John Boyer <jboyer@PureEdge.com>, "Joseph M. Reagle Jr." <reagle@w3.org>, Daniel Veillard <veillard@w3.org>, w3t-tech@w3.org, w3c-ietf-xmldsig@w3.org
"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/
Received on Friday, 9 June 2000 11:06:51 GMT

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