W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2012

[Bug 15398] New: [XP3.0] Inline functions and XPath 1.0 compatibility mode

From: <bugzilla@jessica.w3.org>
Date: Tue, 03 Jan 2012 09:33:47 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-15398-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15398

           Summary: [XP3.0] Inline functions and XPath 1.0 compatibility
                    mode
           Product: XPath / XQuery / XSLT
           Version: Member-only Editors Drafts
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath 3.0
        AssignedTo: jonathan.robie@gmail.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


Inline functions and dynamic function calls are new in 3.0 so there are no
backwards compatibility requirements. Nevertheless, we currently invoke the
function conversion rules, and the effect of these rules depends on the setting
of XPath 1.0 compatibility mode.

There are a number of difficulties with this:

* it's an unnecessary complication for implementors

* since the setting of XPath 1.0 compatibility mode can vary from one
expression to another, the spec needs to be clear about which setting applies
(is it the declaration of an inline function, or the point where it is called;
and what about partial function application?)

* sometimes the invocation of the function is not in user-written code at all,
but within the logic of a higher-order function such as fn:filter or
fn:fold-left.

I would therefore propose that XPath 1.0 compatibility mode should apply to the
function conversion rules only in the case of traditional "static" function
calls.

This can be achieved by changing the start of the first bullet of 3.1.5.2 from
"If XPath 1.0 compatibility mode is true and an argument is not of the expected
type, then" to "In the case of a static function call for which XPath 1.0
compatibility mode is true, when an argument is not of the expected type,"

Perhaps we also should add a note to emphasize that compatibility mode does not
come into play as part of the function conversion rules (a) in dynamic function
calls, (b) in converting the result of an inline function to its required type,
(c) in partial function application, (d) in implicit function calls that occur
when evaluating functions such as fn:map and fn:filter.

(A more radical solution, of course, is to drop XPath 1.0 compatibility mode
for XPath 3.0. This proposal isn't intended to prejudge whether that's a good
idea.)

-- 
Configure bugmail: https://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 Tuesday, 3 January 2012 09:33:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:47 UTC