good afternoon; On 21 Aug 2013, at 11:29 AM, Steve Harris wrote:
> On 20 Aug 2013, at 23:42, Rob Vesse <[email protected]> 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
