W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

RE: Need Union and RE: Should I organize a call on the XPath Filter?

From: John Boyer <JBoyer@PureEdge.com>
Date: Thu, 21 Mar 2002 15:03:29 -0800
Message-ID: <7874BFCCD289A645B5CE3935769F0B523284AD@tigger.PureEdge.com>
To: <reagle@w3.org>, "merlin" <merlin@baltimore.ie>
Cc: "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>, "TAMURA Kent" <kent@trl.ibm.co.jp>, <w3c-ietf-xmldsig@w3.org>


Hi Joseph,

A profile of XPath or XPtr that does not preserve knowledge of the full
document is fundamentally broken according to those specs.  At any point
in the evaluation of an XPath expression, I can start traversing the
ancestor axis all the way up to the root of the document.  This is even
a property of the XPath filter 1.0, which may start at a given node in a
nodeset, but then can traverse anywhere in the document to make a
determination of whether or not the node is to be included in the
output.

We can put in an editors note to make sure everyone understands this,
but defining a lot of new terms might make it seem that something is
broken in what we are doing where clearly there is no error in our
approach.

John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
Sent: Thursday, March 21, 2002 2:55 PM
To: John Boyer; merlin
Cc: Christian Geuer-Pollmann; TAMURA Kent; w3c-ietf-xmldsig@w3.org
Subject: Re: Need Union and RE: Should I organize a call on the XPath
Filter?



Ah, I was confused about the distinctions between the "input document"
and 
"input nodeset." I've realized we should promintly highlight and define

the difference between the input nodeset, and the root element of the
whole 
tree that still exists in context.

Also, I have a *little* bit of concern in that we're implicitly thinking
in 
terms of DOM implementation and the relationship to the whole of the
tree 
being preserved when we are handed a nodeset. (If this design is 
unavoidable/desired, perhaps we could make it more explicit?) What
happens 
if I had a stream-like implementation of a profile of XPtr or XPath, or 
some weird conversion between an Infoset? XPath defines a node-set as, 
"node-set (an unordered collection of nodes without duplicates)" so
there's 
nothing there that guarentees the preservation of relationships with
other 
nodes, right?

I don't disagree with the distinction, I'm just not confident we aren't 
relying upon some implicit statement somewhere that the result of one of

our XPath transforms (or profiled XPtr) MUST preserve its relationships
to 
nodes not in the node-set. Perhaps we need to define an "input nodeset" 
"document nodeset" and "evaluated nodeset" and state the relationships 
between the "evaluated nodeset" and "document nodeset" MUST be
preserved.

On Wednesday 20 March 2002 13:35, John Boyer wrote:
> <merlin>
> To answer 2, in case it's not clear from my last message (which
> hopefully
> addresses 1), the XPath expression is evaluated in the context of the
> input document and then the result is applied to the input node set.
> </merlin>
> <jb>
> Yes, and I would further assert that the set operation transforms
*are*
> operating over the output result of the preceding transform in a
natural
> way, esp. given that we want to avoid running lots of XPath
expressions.
> An Xpath evaluation context takes one node.  If we want to run the
Xpath
> over each node of the input, then use Xpath filter 1.0.  Otherwise, we
> run one Xpath over the document from which the input node-set is
drawn,
> then we perform a set operation between the Xpath result and the input
> node-set....
Received on Thursday, 21 March 2002 18:04:00 GMT

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