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

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

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

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

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

Also, I have a *little* bit of concern in that we're implicitly thinking
terms of DOM implementation and the relationship to the whole of the
being preserved when we are handed a nodeset. (If this design is 
unavoidable/desired, perhaps we could make it more explicit?) What
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
nothing there that guarentees the preservation of relationships with
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
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

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
> operating over the output result of the preceding transform in a
> way, esp. given that we want to avoid running lots of XPath
> An Xpath evaluation context takes one node.  If we want to run the
> 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
> then we perform a set operation between the Xpath result and the input
> node-set....
Received on Thursday, 21 March 2002 18:04:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC