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 15398 - [XP3.0] Inline functions and XPath 1.0 compatibility mode
Summary: [XP3.0] Inline functions and XPath 1.0 compatibility mode
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.0 (show other bugs)
Version: Member-only Editors Drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2012-01-03 09:33 UTC by Michael Kay
Modified: 2013-06-19 09:10 UTC (History)
0 users

See Also:


Description Michael Kay 2012-01-03 09:33:45 UTC
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 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.)
Comment 1 Jonathan Robie 2012-01-10 17:51:42 UTC
The Working Group agrees. I will implement these changes.