#482 path grammar

[VladimirAlexiev]

Related to #482, here are 2 variants:

• plantuml

  • pros: can automate with make file, the base case predicate comes first
  • cons: worse rendering, ugly EBNF source (took some staring at https://plantuml.com/ebnf to write it), have to put it in 1 line

  @startEbnf
  path = predicate | "(", {path}-, ")" | "[", 
  ("sh:inversePath"|"sh:alternativePath"|"sh:zeroOrMorePath"|"sh:oneOrMorePath"), path, "]" ;
  @endEbnf
  

  

• rr

  • pros: better rendering (I like the yellow), easy to write source, can split in multiple lines
  • made by hand at https://www.bottlecaps.de/rr/ui (check SVG, uncheck Embedded, download), need to build & deploy to automate;
    the base case predicate is shown second and I can't control that

  path ::= predicate | 
    '(' path* ')' | 
    '[' ('sh:inversePath'|'sh:alternativePath'|'sh:zeroOrMorePath'|'sh:oneOrMorePath') path ']'
  

  

[VladimirAlexiev]

@HolgerKnublauch do you like this sort of thing?

• @afs , @jeswr I think we definitely want it for some aspects of the SHACLC grammar? (I added such to Andy's RULEs gist).
• I personally think it's also useful for SHACL RDF constructs! Reading through those pfps-inspired obtuse clauses is not easy...

[afs]

Does not work in dark mode.

[HolgerKnublauch]

I have mixed feelings about all this TBH. We are adding more and more work to keep all this consistent and correct.

[afs]

for some aspects of the SHACLC grammar?

The rules compact syntax is standalone and has EBNF generated from the same source as the HTML.

SHACL-C style is more towards "abbreviated Turtle". It may be too constraining (on either side) to have one compact syntax that works for both. The rule language can change its name to avoid the word "compact".

The use of SPARQL keywords may not fit with the editors of SHACL-C view of writing node expressions. Restricting the filters to node expression syntax is "unintuitive" and also a barrier to a compact-rules-syntax only implementation based on conjunctive query generation whereas for SHACL-C maybe the right thing to do. There is already keyword clash between the two.

Other W3C specs (RDF ones, XML, ...) use this W3C EBNF: https://www.w3.org/TR/xml11/#sec-notation

puml ebnf looks to be different and has it's own features.

[VladimirAlexiev]

hi @afs!

• PlantUML has a "dark mode", eg see https://www.plantuml.com/plantuml/duml/SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKiX8pSd9vt98pKi1IW80

  

  I don't yet know whether it's adaptive (i.e. interrogates @media in the browser) but it seems so: Is there a way for the plantuml diagrams to honor the context style (light or dark)? plantuml/plantuml#882

• RR doesn't have "dark mode", but the diagram looks nearly ok, only the edges need to be made more prominent.

  

  I posted adapt or change colors to work in "dark mode" GuntherRademacher/rr#58

---

PUML ebnf is indeed weird and I much prefer the RR ebnf.

• So far the only real benefit of PUML grammar diagrams is "dark mode" support. But I hope @GuntherRademacher addresses this, or I could try to tackle it.
• I'll

@HolgerKnublauch, @afs , @jeswr I think every effort should be made to make the specs easier for the reader.
Perhaps active authors are "unqualified" to judge how difficult the pfps-inspired sequential clauses are to a new reader!
I will undertake to keep all diagrams up to date.

[afs]

Perhaps active authors are "unqualified" to judge how difficult the ...

The purpose of a standard is first-and-foremost to define.

No other document can do that.

The responsibility of the working group is achieve that goal. Sooner is better. If other work is taking time and attention away from reviewing then that detracts from the quality and timeliness of the standard.

[HolgerKnublauch]

At the very minimum any such diagram needs to be wrapped with a warning that this is purely informative, illustrative and if it contains errors then the written spec has precedence.

[VladimirAlexiev]

@afs

If other work is taking time and attention away from reviewing then that detracts from the quality and timeliness of the standard.

So Andy, are you saying the readability of a standard doesn't matter? That readability has no import on adoption and correct implementation?

I've done it and I undertake to keep it up to date. So your argument "it will take time to do" doesn't really apply.

@HolgerKnublauch

warning that this is purely informative,

Agree!

---

PS: The discussion taking part here needs to play out, because it sets a precedent.
If it's accepted, my intent is to pepper the specs with illustrations (I also added a ValidationResult UML diagram).