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

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> 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 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.

> 
> 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.
> 
> Cheers,
>     Steve