Re: Possible Errata re CONCAT and COALESCE for SPARQL 1.1 Query

On 21/08/13 13:05, james anderson wrote:
> good afternoon;
>
> On 21 Aug 2013, at 11:29 AM, Steve Harris wrote:
>
>> On 20 Aug 2013, at 23:42, Rob Vesse <rvesse@dotnetrdf.org
>> <mailto:rvesse@dotnetrdf.org>> wrote:
>>
>>> I have some comments around the definitions of CONCAT and COALESCE
>>> that have originated from private discussions with a user and may
>>> lead to additional errata for the SPARQL 1.1 Query specification
>>>
>>> ---
>>>
>>> Starting with Section 17.4.3.12 CONCAT
>>> (http://www.w3.org/TR/sparql11-query/#func-concat) it states the
>>> following:
>>>
>>>> The |CONCAT| function corresponds to the XPath fn:concat
>>>> <http://www.w3.org/TR/xpath-functions/#func-concat> function. The
>>>> function accepts string literals as arguments.
>>>
>>> If you follow the link to the fn:concat definition it states the
>>> following:
>>>
>>>> Accepts two or more |xs:anyAtomicType| arguments
>>>
>>> However the grammar allows zero or more through use of the
>>> ExpressionList production and so various implementations (including
>>> my own) happily allow zero or one arguments to be used.
>>>
>>> In this case the specification should really explicitly
>>> allow/disallow those cases.  If the intention was to fully align with
>>> fn:concat then a minimum or two arguments should be required, if
>>> zero/one should be permitted then the spec should note this deviation
>>> from the XPath definition.
>>
>> Yes, agreed. My preference would be to allow zero or one - zero being
>> an error(?), and one returning the string of the argument.
>
> if no argument is supplied, a zero length string would be better.

I agree : zero=> "" and one => the one argument.

This would make CONCAT like GROUP_CONCAT.

It is worth defining as cases

  CONCAT() -> ""
  CONCAT("abc") -> "abc"
and the fn:concat for the other cases so as not to redefine "fn:concat"

GROUP_CONCAT already gets this right.

>> This may help code that generates queries.
>>
>>> ---
>>>
>>> Then we have Section 17.4.1.3 COALESCE
>>> (http://www.w3.org/TR/sparql11-query/#func-coalesce) where the
>>> function definition is given as follows:
>>>>
>>>> The |COALESCE| function form returns the RDF term value of the first
>>>> expression that evaluates without error. In SPARQL, evaluating an
>>>> unbound variable raises an error.
>>>>
>>>> If none of the arguments evaluates to an RDF term, an error is
>>>> raised. If no expressions are evaluated without error, an error is
>>>> raised.
>>>>
>>> Between this and the examples it is implied that COALESCE requires at
>>> least one argument yet again the grammar allows for zero arguments.
>>>
>>> Obviously zero arguments means COALESCE will always give an error so
>>> it is a pointless expression to write yet legal per the grammar, so
>>> again it would be nice if the specification explicitly stated this as
>>> being allowed/disallowed.
>>
>> I don't think this requires an erratum. As far as I remember, SPARQL
>> doesn't really have a concept of "disallowing" expressions that can be
>> written in the grammar, other than it being an error, and as you've
>> seen it's clearly an error by the description of the function.

Agreed.

>>
>> Cheers,
>>     Steve
>

	Andy

Received on Wednesday, 21 August 2013 17:10:12 UTC