- From: John Boyer <JBoyer@PureEdge.com>
- Date: Wed, 29 May 2002 10:55:23 -0700
- To: "merlin" <merlin@baltimore.ie>, <reagle@w3.org>
- Cc: <w3c-ietf-xmldsig@w3.org>
Hi all, An empty node-set as input to an Xpath filter 1.0 yields no output. For Xpath filter 2.0 intersection and subtraction, this result continues to make sense. Only union can cause a problem if the input node-set is empty since the node-set must have an implicit knowledge of the document from which the node-set selects nothing. As for union, perhaps it would be best for the filter to act exactly like XPath would under the same circumstances. The union filter is supposed to perform a union of an empty set S with a node-set obtained by evaluating a given Xpath expression E with an initial context node of the root node R relative to the input node-set S. A pure XPath expression that performs the same sequence of operations is: (S | (S)/ancestor::node()[last()]/E) The ancestor::node()[last()] gets the root node as the starting context for E, but the subexpression only works if set S is non-empty. The way XPath works is that once a location step results in an empty node-set, there are no context nodes on which to perform the next location step so the result of the subexpression S/ancestor::node()[last()]/E is an empty node-set. Since S is an empty node-set, the result of the final union is an empty node-set, regardless of what E would have selected had we been able to obtain the document root. In conclusion, this means that if an empty node-set is given as input to an Xpath 2.0 filter, returning an empty node-set would be behavior consistent with the XPath 1.0 recommendation and with the XPath filter 1.0 in the XML DSig recommendation. To throw an error would be inconsistent. Thanks, John Boyer
Received on Wednesday, 29 May 2002 13:58:18 UTC