W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2010

[Bug 9838] New: Axes as functions

From: <bugzilla@jessica.w3.org>
Date: Thu, 03 Jun 2010 08:56:42 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-9838-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9838

           Summary: Axes as functions
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XPath 2.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


In meeting 427 there was some discussion about the equivalence of axes and
functions, and I was actioned (A-427-23) to summarize the discussion in a new
Bugzilla entry so that it could be considered as a basis for enhancements for a
future release. The discussion at meeting 427 is minuted at
http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Feb/0189.html
(member-only link): see agendum J4.2.5.

First, we observe that the semantics of axes could be defined in terms of
functions of the form fn:child(node()) -> node()* (for some of the axes, the
cardinality of the return type can be given more precisely than this). Making
the axes available explicitly as functions would have a number of benefits:

(a) semantic clarity: it makes it clear that there's nothing magic about the
semantics of axes

(b) it would make them available for use as function items that could be passed
as parameters to higher-order functions or returned by higher-order functions.

(c) function composition involving axes would no longer require use of the "/"
operator, which has reordering side-effects. For example one could write
map(child#1, descendant(.)) to get the children of the descendants without
reordering. Using function composition rather than path syntax might also be an
attractive option for code generators.

Conversely the path notation a/b/c is attractive from a usability point of view
in comparison with map(c, map(b, a)). It is already possible to use a function
call as a step in a path expression of the form 

customer/f:cust-orders(.)/product-code/f:product-for-code(.)/price

However, the asymmetry here between built-in navigational functions (the 13
axes) and user-defined navigational functions is striking. Allowing axis
notation (including node tests) for user-defined navigational steps would add
symmetry. The above could then be written

customer/f:cust-orders::*/product-code/f:product-for-code::*/price

Here I have used a node-test of "*", but of course any node test could be used.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 3 June 2010 08:56:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:31 UTC