SHACL Rule grammar - DATA should not allow variables.

[afs]

The triple forms for data and the rule head are shared but the data block must not allow variables whereas the head does allow them.

There are two possibilities:

• a new set of productions that disallow variables i.e. duplicate the tree under TriplesTemplateBlock which is about another 15-20 productions
• Have a note that forbids variables in the DATA block. In effect, have a context flag.
  (see the SPARQL Grammar Note 6 about
  INSERT DATA, DELETE DATA ; SPARQL also has context restrictions on blank nodes so
  "(no) variables x (no) blank nodes" for Turtle forms is a lot of grammar productions.

[liviorobaldo]

Idea 💡

We define:

[14] | Data | ::= 'DATA' vf(TriplesTemplateBlock)

then we specify in the grammar that vf(...), where vf stands for “variable-free”, is a function that takes the parse tree rooted at a given block and returns the same tree after applying the following transformation:

[65] | VarOrTerm | ::= Var | iri | RDFLiteral | NumericLiteral | BooleanLiteral | BlankNode | NIL | TripleTerm

is rewritten as:

[65] | VarOrTerm | ::= iri | RDFLiteral | NumericLiteral | BooleanLiteral | BlankNode | NIL | TripleTerm

In this way, the specification remains fully formal, as a grammar should, while avoiding the duplication of 15–20 productions.

I find that using a footnote as the one you suggest is risky, as we mix formal definitions with informal or textual explanations. Moreover, many readers overlook footnotes precisely because they are expected to contain only marginal or supplementary material, which is not the case here. Same considerations of course apply to SPARQL 1.2 as well, but I'm not concerned with that.

[afs]

Maybe as a textual marker in the HTML but there are ways to do that without violating W3C EBNF syntax.

Not as a transformation - the grammar is designed to be fed into common parser generators and the concept of transformation does not exist universally.

A textual marker can be done by an intermediate rule TriplesBlockData to introduce a name and and an HTML anchor so the grammar requirement can name the point in the grammar.

In SPARQL, these are not foot notes. They are inline and before the grammar table, then reinforced with negative syntax tests.

[simonstey]

the grammar is designed to be fed into common parser generators

and as such, I think it's totally reasonable to have a dedicated set of production rules that disallow the use of variables (even if that means an additional 20 production rules) .

[simonstey]

that being said, @afs you mentioned at some point that you generated the HTML for the grammar based on a .ebnf? grammar file. probably using a tooling like mentioned here by you #162 (comment) ? you haven't checked in that grammar file yet, right? If not, could you please do so? (unless there's a reason for not doing that)

thx!

[afs]

that being said, @afs you mentioned at some point that you generated the HTML for the grammar based on a .ebnf? grammar file. probably using a tooling like mentioned here by you #162 (comment) ? you haven't checked in that grammar file yet, right? If not, could you please do so? (unless there's a reason for not doing that)

thx!

The grammar is authored in javacc, which means it get checked for things like missing productions and also that is it is LL(1).
That's in a javacc (*.jj) file). javacc can produce text out for productions, not tokens.. This is not the right EBNF.

From that text output, and a curated tokens file, the HTML for the spec is generated by hacking strings.

Everything is in https://github.com/afs/jena-rules/blob/main/Grammar-SHACL/.
It is not pretty.

There is also a [BNF file] (https://github.com/afs/jena-rules/blob/main/Grammar-SHACL/rules-grammar.bnf) produced in the same way. The tooling around it is less mature - I fixed a conversion error today.

If you use for some tool, could you please let me know how that goes?

The HTML is normative.

((
There is more than one EBNF!!

It is the W3C variant of EBNF (defined in XML section 6; it's the same in both XML 1.0 and XML 1.1).

The BNF output for SRL also has newlines within rules. Some productions are very long. Strict W3C EBNF is one line per production.

I have a long-term side-project to produce robust W3C EBNF but that is not a priority.
))

[afs]

the grammar is designed to be fed into common parser generators

and as such, I think it's totally reasonable to have a dedicated set of production rules that disallow the use of variables (even if that means an additional 20 production rules) .

While the grammar has whatever number of nearly identical productions to give an AST, the parser writer still has write code to actually do something at each place in the AST.