Support for XPath and XQuery Functions and Operators 3.1

[ebremer]

Why?

SPARQL 1.1 supports XQuery 1.0 and XPath 2.0 Functions and Operators. Support for XPath and XQuery Functions and Operators 3.1 would add useful missing trigonometric and exponential functions not supported in XPath 2.0.

Previous work

https://www.w3.org/TR/sparql11-query/#FunctionMapping https://www.w3.org/TR/2007/REC-xpath-functions-20070123/

Proposed solution

https://www.w3.org/TR/xpath-functions/

[jpcs]

+1 MarkLogic already supports access to most XPath functions from SPARQL.

Some don't have much relevance without access to an XML document database (ie: fn:collection(), fn:node-name(), etc.). But moving to a "justify exclusion" mode rather than a "justify inclusion" mode would seem to make sense.

[JervenBolleman]

Started on making a list of all functions

With proto specifications for the maths cases.

Big question I have is dealing with 'NaN' and 'infinities'.

[kasei]

Looking over F&O 3.1, AFAICT this would introduce some changes to the current SPARQL semantics.

For example, when comparing dateTime values, 2.0 could lead to an incomparable result, whereas 3.1 seems to always allow comparisons, as it relies on an implementation-defined implicit timezone. I think this would be a backwards-incompatible change to SPARQL, as it would be changing the meaning of the operator mapping table (although while the table is described as being defined by "XQuery 1.0 and XPath 2.0 Functions and Operators," I'll note that the links in the table now all point to 3.1, as it was updated in-place).

[afs]

Personally, I don't like the use "implicit timezone" for something that is used for publishing data on the web. Client timezone != server timezone and it is even more complicated when the server is running UTC regardless of location.

[kasei]

Personally, I don't like the use "implicit timezone" for something that is used for publishing data on the web.

I agree, and haven't been using any sort of implicit timezone in the tests I've been writing for #32. But if we choose not to use implicit timezones, it seems we're either entirely precluded from supporting 3.1, or have to diverge from 3.1 for certain functions and operators.

[afs]

One way is to define what happens when there is no implicit timezone, seeing it as a bit of an extension of F&O.