SPARQL VERSION string formatting

[jitsedesmet]

Hi all, again great work.

Today I implemented the version announcement of SPARQL 1.2.
I wonder whether we need/ want the versionSpecifier rule.
I see why you would want to limit the version not to be multi-line. The problem is that this rule does not restrict the usage of multi-line string. One could still use the suggested single-line strings ' ' and " " but make them multi-line using the escape sequences in strings like VERSION "SPARQL \n 1.1. As such, I do not think it makes sense to arbitrarily limit the structure of the string definitions. It makes the implementation of the grammar larger (since we need the VersionSpecifier rule instead of reusing the String rule, without effectively tackling an issue you would have (multi-line strings). From a user perspective I think this also does not make sense, throughout all of the SPARQL grammar we use the string rule (so 4 ways to declare it) but in this arbitrary scope of VERSION, we cannot. Imo, that's not consistent.

I would also like to get back at an issue previously raised on the PR: #210 (comment)
I think a limited semantics of re-declarations is already in order?
The spec provides rules on re-declarations of PREFIX and BASE through section 19.5

A prefix declared with the PREFIX keyword may not be re-declared in the same query. See section 4.1.1, Syntax of IRI Terms, for a description of BASE and PREFIX.

I think a similar approach could be taken here (so you could only have 1 definition of VERSION).
So, what about future proofness? I think when the problem would arise where you want to declare multiple versions, this could be done by extending the grammar to:
[7] VersionDecl ::= 'VERSION' VersionSpecifier +

To summarize:

1. I think the versionSpecifier rule introduces inconsistency in the language
2. I think we need to restrict that the version is not allowed to be redefined. - And specifically declare what happens when it is redeclared in the context of SPARQL update queries (where the prologue can be repeated between updates)

[TallTed]

'VERSION' VersionSpecifier + would not make sense, as it says "this query contains multiple SPARQL versions" but does not offer any info about where content of one version stops and content of another begins.

However, declaring VERSION 1.1 at line x (perhaps within a SERVICE block), VERSION 1.2 at line y, and VERSION 1.1 at line z lets a processor handle each section according to that version's rules (and of course, the overall VERSION of this query must be 1.2 or later, and be declared near line 0).

[afs]

The strings are defined in RDF Concepts, section 2.1.
It is expected that there would be few of them and related to RDF and SPARQL standard versions.

"SPARQL \n 1.1" is not a spec-defined version string.

VERSION is specifically for the evolution of RDF and SPARQL standards.There is already a proper way to have modified languages using new media types.

[afs]

Currently, VERSION appears in the prologue, not at any point in the syntax.

A query has a single prologue; an update has a possible prologue at each section.

[gkellogg]

Notably, Turtle doesn't proscribe any behavior for changing or mismatched version numbers, as it's entirely informative. Similar for RDF/XML.

[jitsedesmet]

@TallTed , I understand. The 'VERSION' VersionSpecifier + suggestion was meant as a way out in the future. I just suggest we define what an engine should do if the same prologue contains VERSION multiple times :) (and if we say, you cannot define multiple times, and for some reason we would still want to allow that in SPARQL version X, we could just extend the rule (from a grammar perspective)).

@afs the existence of RDF Concepts, section 2.1 makes my comment of 'why limit string notation syntax' even stronger. You are already saying the versions should follow RDF Concepts, section 2.1, there is thus no reason not to use the string grammar rule [155]? - In short, I still think [155] would be a better fit instead of [8].

Aha, if the VERSION is informative, then I guess there is no reason to explicitly mention what happens when the VERSION is defined multiple times in the same prologue? I would expect the version declaration to be more binding (having repercussions if it is wrong) could we reference that it doesn't in the Version Announcement?

Already big thank you for spending the time to reply! :D

[afs]

There are always choices. The WG settled on:

• strings were necessary (not raw numbers) because of "1.2-basic".
• single-quoted strings are a better choice because there less variety when text searching files
• A new terminal for this purpose was low-value, and high-cost for implementations.

IMO triple-quoted strings are for content blocks, often taken from some other source, or compounds like rdf:XMLLiteral or rdf:JSON.

[jitsedesmet]

A new terminal for this purpose was low-value, and high-cost for implementations.

This I find interesting because the spec does introduce the non-terminal VersionSpecifier instead of reusing the non-terminal String.
Regardless, I understand that this may be a personal preference for consistency, and I do see merit in (but don't think it outweighs):

single-quoted strings are a better choice because there less variety when text searching files

Anyways, I just wanted to express my worries, and don't need to push my opinion. From my part this issue can be closed if no one else thinks the same as me ;)
Thanks again for putting in the work!

[afs]

Copntinued on #241.