This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1665 - user-defined tree navigation primitives
Summary: user-defined tree navigation primitives
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 1.0 (show other bugs)
Version: Last Call drafts
Hardware: Macintosh All
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-16 16:18 UTC by Loredana Afanasiev
Modified: 2005-09-29 12:48 UTC (History)
0 users

See Also:


Attachments

Description Loredana Afanasiev 2005-07-16 16:18:06 UTC
Dear Members of W3C XQuery working group,

We have the following question/remark regarding the user-defined functions.

Q: How easy is it to define and use tree navigation primitives in XQuery?

There are very natural cases of user-defined navigation axes that
would profit, both in readability and efficiency, from the applicative nature of
the navigation paths (as opposed to the {\em iterative style} of programming
that XQuery adopted). See for example \cite{bird:exte05} that extends XPath with
linguistically motivated navigation axis.

Let's consider the following example
based on a virtual XML document called \verb|example.xml| in which all the
elements contain an attribute \verb|a| of type \verb|xs:integer|. And suppose
your application makes frequent use of queries containing a \verb|desc_a|
primitive. \verb|desc_a| applies on a context set of nodes and returns all the
descendants with the \verb|@a|-value bigger then the \verb|@a|-value of the
context node.

The following XQuery query  below describes the \verb|desc_a| primitive as a
user-defined function and applies it on a initial sequence of nodes obtained by
evaluating an abstract location path \verb|path1|. The result of evaluating the
user-defined axis step is passed as {\em
  evaluation context} to another abstract location path \verb|path2|.

\begin{verbatim}
declare function desc_a($x as element()) as element()*
{
   for $y in $x/descendant::*
   where $x/@a < $y/@a
   return $y
}

for $x in doc(example.xml)/path1
return desc_a($x)/path2

\end{verbatim}

It seems natural (and we believe, more efficient) to express this in a path-like
manner:

\begin{verbatim}
doc('example.xml')/path1/desc_a()/path2
\end{verbatim}

Here \verb|desc_a()| is the same user-defined function as above,
except we would like in this case, the evaluation results of the
\verb|path1| to be passed as the evaluation context to
\verb|desc_a()|. To achieve this it is required that the {\em dynamic
  context} applies to user-defined functions, which is not the case in
XQuery.

Now let's try to express a location path that contains the
\verb|desc_a()| primitive in the scope of a filter expression.

\begin{verbatim}
doc('example.xml')/path1[desc_a()]
\end{verbatim}

We cope with this query in XQuery for example, using the
\ver|for-where| expression.

\begin{verbatim}
for $x in doc('example.xml')/path1
where exists(desc_a($x))
return $x
\end{verbatim}

This example might not convince you that XQuery should allow for
user-defined navigational axes, but our concern here is the
compositionality of the approach above. What happens in case we want to express
a location path that contains \verb|desc_a()| primitive in the scope of a nested
filter expression, like the example below.  We believe that the pseudo XPath
query below requires effort both to
express it in XQuery and also to interpret it  afterwards.

\begin{verbatim}
doc('example.xml')/path1[path2/desc_a()[path3/desc_a()/@a = 10]]
\end{verbatim}

We would appreciate your comments on this issue.

Best regards,
Loredana Afanasiev 
Maarten Marx

----
References:

@InProceedings{bird:exte05,
  author =          {S. Bird and  Y. Chen and  S. Davidson and
                  H. Lee   and Y. Zheng},
  title =          {Extending {XPath} to Support Linguistic Queries}, booktitle
=          {Proceedings of Programming Language
Technologies for XML (PLANX)},
  pages =         {35-46},
  year =         2005
}
Comment 1 Michael Kay 2005-07-17 01:45:13 UTC
I find your presentation of this requirement very confusing: what's this strange

\verb|desc|

syntax that you use?

As far as I can see, what your're asking for is for a function to be able to
take the context item either as an implicit argument, or as the default value of
an explicit argument, so that you can write

a/b()/c

rather than having to write

a/b(.)/c

Is the saving of one character really worth the trouble?

Michael Kay
(personal response)
Comment 2 Michael Kay 2005-07-20 20:24:57 UTC
At its meeting today, the XSL and XQuery working groups decided to endorse the
response I made personally. I am therefore closing the bug as "INVALID" (which
simply means that we have decided there is no error in the spec that needs to be
fixed).

I would be grateful if you could confirm your acceptance of this resolution by
marking the bug entry as CLOSED; alternatively, if you have further comments to
make, or if you feel the requirement has been misunderstood, please feel free to
respond to that effect. In the absence of further comments, we will close the bug.