- From: John Boyer <JBoyer@PureEdge.com>
- Date: Thu, 21 Mar 2002 15:03:29 -0800
- 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 UTC