Casting Behaviour Standard Compliance

[liss-h]

Hi,
so my team and I had a long discussion about casting bool to numerics in SPARQL and how to correctly implement it. For reference we checked to see what Fuseki does and found that it does not fit with any of our interpretations.

Our first interpretation is when implementing XPath: https://www.w3.org/TR/xpath-functions/#casting-across-hierarchy would suggest that
SELECT xsd:positiveInteger("true"^^xsd:boolean) WHERE {} should return "1"^^xsd:positiveInteger as step 3 requires down casting to the requested type. In Fuseki however it returns "1"^^xsd:integer. Note, that the same does not happen when casting xsd:int -> xsd:unsignedInt for example, that cast returns xsd:unsignedInt directly and not xsd:integer.

Our second interpretation is that when not implementing all of XPath and instead just implementing SPARQL: https://www.w3.org/TR/sparql11-query/#FunctionMapping would suggest that the same query should return an error since the constructor is not defined in SPARQL.

It would be highly appreciated if you could share your thoughts on this behaviour, just to double check that neither Fuseki nor us is misinterpreting the standard. Thanks :)

[afs]

xsd:positiveInteger("true"^^xsd:boolean) isn't a single step cast by https://www.w3.org/TR/xpath-functions/#casting-across-hierarchy - it would involve steps 2 and 3. (If we treat xsd:integer as special - while it isn't a primitive datatype, it has a special status as shown by "1"^^xsd:int + "3"^^xsd:int being an xsd:integer.

Fuseki (actually ARQ - the query engine) is failing to apply step 3 after step 2 has happened.

On the second part - SPARQL allows for extensions where error happens in minimal spec-complete SPARQL. Normally, Fuseki is running SPARQL 1.1+extensions.

[afs]

Fixed by #1624

I only found the case of a cast from boolean to an integer derived datatypes (Jena only handles atomic datatypes with no additional facets).

Did you identify any other problems?