1.2 draft spec language changes semantics of `CONCAT`

[kasei]

The current draft spec text has CONCAT in the description of argument compatibility rules for string functions:

The functions STRSTARTS, STRENDS, CONTAINS, STRBEFORE, STRAFTER and CONCAT take two or more arguments. These arguments must be argument compatible; otherwise, invocation of the function raises an error.

Two string literal arguments are argument compatible if:

• The arguments are literals with datatype xsd:string
• The arguments are literals with datatype rdf:langString and have the same language tag
• The arguments are literals with datatype rdf:dirLangString and have the same language tag and the same base direction
• The first argument is a literal with datatype rdf:langString and the second argument is a literal with datatype xsd:string
• The first argument is a literal with datatype rdf:dirLangString, and the second argument has datatype xsd:string

This seems to be a change from Query 1.1 where the Argument Compatibility Rules section only talks about only STRSTARTS, STRENDS, CONTAINS, STRBEFORE, and STRAFTER.

I think this is a problem (at least without WG discussion and agreement) because it seems to change the semantics of the published description for CONCAT in the 1.1 spec where argument incompatibility simply means that the resulting term is a simple literal:

The lexical form of the returned literal is obtained by concatenating the lexical forms of its inputs. If all input literals are typed literals of type xsd:string, then the returned literal is also of type xsd:string, if all input literals are plain literals with identical language tag, then the returned literal is a plain literal with the same language tag, in all other cases, the returned literal is a simple literal.

I think the 1.1 text means:

CONCAT("foo"@en, "bar"@de) ==> "foobar"

(Modulo the 1.2 changes required to move away from "simple literal" and towards xsd:string.) With the new 1.2 text, I think this would probably be a type error.

Beyond the changed semantics, the 1.2 text seems a poor fit for describing the requirements of the n-ary CONCAT because the last two bullet points on compatibility only talk about "first" and "second" arguments.

My preference here would be to: revert to the 1.1 approach of having the argument compatible section avoid discussion of CONCAT; change the definition of CONCAT to avoid talking about being argument compatible; keep the existing CONCAT language about the two-or-more argument case resulting in a langDirString, langString, or xsd:string, depending on the equality of all the base directions and language tags; and add a few more examples to the CONCAT table showing variations regarding base direction.

[afs]

See #337 and closed by #338.

@kasei - if you agree, please close this issue.