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 30155 - [XP31] The term "Query environment" is not defined or explained
Summary: [XP31] The term "Query environment" is not defined or explained
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.1 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-28 19:29 UTC by Abel Braaksma
Modified: 2017-12-13 09:08 UTC (History)
3 users (show)

See Also:


Attachments

Description Abel Braaksma 2017-07-28 19:29:30 UTC
The term "query environment" is used in the XPath 3.1 specification, but there is no definition for that term. My guess is it's a left-over from XQuery and that the term should not be used inside XPath 3.1, but I can be wrong.

It occurs in this definition (and in the Glossary):

 [Definition: External functions are functions that are implemented outside the query environment.]

As a result, the term External functions cannot be independently understood from reading the XP31 spec.

This text may be a result of the resolution of bug #29509, which in its resolution primarily mentions XQuery.
Comment 1 Jonathan Robie 2017-07-28 21:11:16 UTC
Nice catch.  I'm not sure when we can fix bugs like this, but this is clearly a bug.
Comment 2 C. M. Sperberg-McQueen 2017-08-29 15:37:59 UTC
Perhaps replacing "query environment" with "XPath environment" would fix the issue?  

In the XQuery spec, we could either leave it at "query environment" or adopt the same change, but one goal of the paragraph is (I think) to divide the universe of functions into those defined by the XPath Functions spec, those defined by users, those defined by the host language, and those defined by the implementation, with "external function" covering host-language functions and implementation-defined functions.  If host-language functions are external, then "outside the XPath environment" seems a clearer description, and has the advantage of keeping the two definitions in synch.  But the current text does not seem impossible to keep, for the XQuery spec.
Comment 3 Michael Kay 2017-10-13 15:16:20 UTC
I propose changing the definition of "external functions" to avoid using the undefined term "query environment". Specifically I propose:

An external function is any function that is neither specified as part of the language specifications (typically, in [Functions and Operators 3.1]), nor defined using the features of the [XQuery|XPath] language. External functions might include functions provided by a particular [XQuery|XPath] vendor, or functions implemented in other programming languages and made available to be called from [XQeury|XPath] using implementation-dependent mechanisms.
Comment 4 Abel Braaksma 2017-10-13 17:11:18 UTC
Note that comment#2 and comment#3 differ in their interpretation. MSMcQ includes host-language functions into the external functions domain, Michael Kay seems to either deliberately omit "host language functions", or means it is not part of "external functions".

I think it is supposed to be part of it though, so perhaps we can change the latter part thus:

[...] External functions might include functions defined in host languages such as XSLT or XQuery, functions provided by a particular [XQuery|XPath] vendor, or functions implemented in other programming languages and mad available to be called from [XQuery|XPath] using implementation-dependent mechanisms.

Assuming that can be clarified/altered, I agree with comment#3.
Comment 5 Michael Kay 2017-10-13 17:22:03 UTC
I took the view that if host languages want to define additional functions then it's up to the host language to say what category they fall into: under this definition they are external, and therefore implementation-defined, and anything that is implementation defined can also be host language defined.

But really, it's not worth the hassle of trying to fix this area. There's no realistic expectation that word-smithing this any further now will have any meaningful impact on the interoperability of implementations.
Comment 6 Abel Braaksma 2017-10-20 09:21:14 UTC
> under this definition [host-language functions] are external, and therefore 
> implementation-defined,
First I thought you meant to drop the definition of host-language functions, but I wasn't aware we defined it already:

   "Definition: A host language function is an external function defined by 
   the host language."

This, I believe, supports your latest comment and makes my comment moot. 

> There's no realistic expectation that word-smithing this any further now will 
> have any meaningful impact on the interoperability of implementations.
Yes, except that we have specific rules pertaining to host-language functions in the spec. For instance, 5.b.iii under "3.1.5.1 Evaluating Static and Dynamic Function Calls", is a rule that applies to host-language functions and *not* to (other) external functions.

That said, I think the definition is sound now.
Comment 7 Andrew Coleman 2017-12-13 09:08:37 UTC
This has been resolved in the errata document:
https://www.w3.org/XML/2017/qt-errata/xpath-31-errata.html#E2