1665 2005-07-16 16:18:06 +0000 user-defined tree navigation primitives 2005-09-29 12:48:13 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 1.0 Last Call drafts Macintosh All CLOSED INVALID P2 normal --- 1 lafanasi chamberl public-qt-comments oldest_to_newest 4749 0 lafanasi 2005-07-16 16:18:06 +0000 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 } 4757 1 mike 2005-07-17 01:45:13 +0000 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) 5024 2 mike 2005-07-20 20:24:57 +0000 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.