search

w3c / rdf-tests

Repository for the RDF Tests Community Group
w3c.github.io/rdf-tests
Other
44 stars 23 forks source link

SPARQL CONCAT(): test the empty and single cases #100

Closed Tpt closed 1 year ago

Tpt commented 1 year ago

Related to:

lisp commented 1 year ago

the CONCAT definition indicate a minimum of two arguments:

https://www.w3.org/TR/xpath-functions/#func-concat
Tpt commented 1 year ago

the CONCAT definition indicate a minimum of two arguments:

https://www.w3.org/TR/xpath-functions/#func-concat

Yes in xPath. In SPARQL zero and one arguments are also supported: https://www.w3.org/2013/sparql-errata#errata-query-4 but behavior was underspecified. Hence the addition of these tests related to this PR to the SPARQL spec: https://github.com/w3c/sparql-query/pull/70

lisp commented 1 year ago

as per vesse´s remark, there are two options.
until a recommendation ratifies one or the other, a change to the conformance suite is not justified.

Tpt commented 1 year ago

as per vesse´s remark, there are two options. until a recommendation ratifies one or the other, a change to the conformance suite is not justified.

The SPARQL 1.1 grammar already states that CONCAT is at least on the syntaxic level already allowed to get 0 or 1 arguments. So, disallowing 0 and 1 parameters seems like a breaking change to me and I believe the ship as already sailed on this topic. But I might be wrong. In this case, we might add these tests to a SPARQL 1.2 test suite if https://github.com/w3c/sparql-query/pull/70 is ratified. What do you think?

TallTed commented 1 year ago

imho, Zero and one argument are (and should be) permitted, and so should be tested.

lisp commented 1 year ago

there are already numerous things which the grammer permits, but the semantics does not. the function definition is the function definition.

TallTed commented 1 year ago

there are already numerous things which the grammer permits, but the semantics does not. the function definition is the function definition.

If, as seems to be your suggestion, the semantics of the function definition rule, then anywhere the grammar currently and erroneously permits something which the semantics do not, the grammar should be corrected, and the tests should likewise be aligned with the semantics.

If, on the other hand, the grammar reflects the intent of the authors and the grammar differs from the semantics of the function definition, then the semantics should be modified to reflect the authors intent.

I am struggling to do so, but cannot think of any reason why CONCAT() should not support zero or one argument just as it does n≥2 arguments. If there is a justification for this forbiddance, it should be easy enough to present, and then we can move forward based on that presentation,

lisp commented 1 year ago

in principle, there is no reason to prefer one of these two paths over the other. in practice, there may be implementation precedents and even deployments which argue for one over the other.
in that regard, while i have no direct stake in the matter, as we (i believe) permit the operations which the grammar suggests, i am concerned with interoperability.

however this may be, it is not an appropriate means to attempt to promote interoperability by following the suggested third path, which is to assert that the inconsistency is resolved by modifying the conformance test(s) only.

i am similarly skeptical of the notion that either of the two initial paths be folded into the effort to ratify a recommendation for rdf-star by elevating it to the standard for sparql-1.2.
more appropriate would be to deal with deficiencies in the 1.1 recommendation as such and ratify an errata document for it.

Tpt commented 1 year ago

which is to assert that the inconsistency is resolved by modifying the conformance test(s) only. more appropriate would be to deal with deficiencies in the 1.1 recommendation as such and ratify an errata document for it.

There is already an errata document and a specific errata about this topic that I refered to in this PR description. Nobody took time to make a new formal revision of the SPARQL 1.1 specification and I am not sure it will ever be done if no one step up to do it, especially now that the SPARQL 1.2 specification is in preparation. This PR comes also alongside with an other PR to amend the SPARQL specification and imho should merged only if the specification PR is adopted so I am not sure that the modifying the conformance test(s) only approach is taken here. This MR only add the test to the sparql folder of this repository that is the version with updates and not in the sparql11 directory that is supposed to be the testsuite related to the stable SPARQL 1.1 recommandation.

I am similarly skeptical of the notion that either of the two initial paths be folded into the effort to ratify a recommendation for rdf-star by elevating it to the standard for sparql-1.2.

Consolidating pending errata is in the RDF-star working group charter: For every recommendation updated by this Working Group, the pending editorial errata will also be addressed. Indeed it would have been better to just amend the SPARQL 1.1 specification but it never got done in 10 years, I am not sure it is reasonable to expect it to be done now.

lisp commented 1 year ago

There is already an errata document and a specific errata about this topic that I refered to in this PR description.

the second sentence of the document which you reference is

Actual changes to a W3C Recommendation must be approved by a chartered W3C Working Group and the W3C Advisory Committee.

the rdf-star charter notwithstanding, i remain skeptical of an approach which bundles the changes required by rdf-star with other corrections to sparql conformance. while it may follow as a matter of convenience and/or political exigency, it is not the best approach to interoperability.

afs commented 1 year ago

rdf-tests is community driven. It has no formal status in W3C process. We can (and have been) doing the "right thing" on a case-by-case basis.

The SPARQL 1.1 REC (dated) can not be amended. A W3C dated RECs is immutable document except for structural errors (e.g. publication errors) and sometimes information about newer documents.

RDF star WG is chartered to update the documents, address errata and publish as 1.2.

afs commented 1 year ago

CONCAT is supposed to support 0 or more arguments. The grammar is covers this and, to me, the grammar is part of the function definition.

@lisp : Which implementations only support 2+ arguments and what do they do about the grammar issue because they can't satisfy both the grammar and a restrictive reading of the text definition.

Currently: https://github.com/w3c/sparql-query/pull/70

This fixes the the definition to clearly cover the zero and one cases. It is the least disruptive approach because it is not a grammar change.

there may be implementation precedents and even deployments which argue for one over the other.

Apache Jena supports zero or more.

lisp commented 1 year ago

@lisp : Which implementations only support 2+ arguments and what do they do about the grammar issue because they can't satisfy both the grammar and a restrictive reading of the text definition.

why should this argument carry more weight in this case than it does with those others there are aspects of the language definition where the grammar does not agree with the defined behavior?

there may be implementation precedents and even deployments which argue for one over the other.

Apache Jena supports zero or more.

as does dydra, but that does not change the intent of first line of the errata document. you evidently follow a different process and you have the necessary authority, so there is no need to discuss it.