W3C home > Mailing lists > Public > www-ql@w3.org > January to March 2003

RE: filter() function: what happened?

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Tue, 21 Jan 2003 13:07:51 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E621060453DF91@daemsg02.software-ag.de>
To: kifer@cs.stonybrook.edu, www-ql@w3.org

> 
> Sorry if this has already been discussed, but can somebody 
> explain (or point to an explanation) of why did the filter() 
> function disappear from the spec in the middle of last year?
> 

The filter() function was very poorly specified, and attempts to specify it
more precisely proved difficult - it appeared that different people had
different ideas what it should do. As specified in the April 2002 draft, it
took an Expression as an argument, which would have made it a second-order
function, something which the language semantics does not allow. Defining
what was meant by "preserving any relationships" was difficult - the idea
seemed to be that this referred to descendant relationships, but not
necessarily sibling relationships, though examples also suggested that
people expected relative ordering to be preserved. No-one had even started
to explore questions about the preservation of namespace nodes or type
annotations; or even to define whether a "shallow copy" of an element should
contain any immediate text node children.

The example in the April draft suggested using a path expression that
selects three nodes X, Y, and Z, in which Y and Z are descendants of X. It's
not actually very convenient to write such a path expression. It becomes
grossly inconvenient if you have to select both the elements you want
copied, and their text nodes.

Another objection was that core XPath functions should not create new nodes.
XPath is used in many contexts where creation of nodes is not appropriate.
When functions do create nodes, questions arise about side effects: if the
function is called twice with the same arguments, does it return the same
nodes or different nodes?

A further objection concerned implementability. Given an arbitrary set of N
nodes, determining all the ancestor-descendant relationships among these
nodes is computationally complex. The effect is that this is a very
inefficient way of doing a selective copy of a tree, compared with
algorithms that rely on recursive descent.


Michael Kay 
Software AG
Received on Tuesday, 21 January 2003 07:08:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:18 GMT