Grammar rules: redundancies

[ChristianGruen]

I’m a humble user of our grammar rules, and I’m definitely not an expert when it comes to their definition (my main obstacle is that changes to the XQuery grammar rules need to be compatible with the XPath and possibly XSLT grammars).

What made it difficult for me to read them in the past were the numerous redundancies (with some of them attached). Is this just “history”, or are there particular reasons for preserving or even enforcing redundance? I noticed that, sometimes, symbol names are used in the prose, but I failed to detect any reasonable pattern.

Do we believe it would be helpful to clean up the grammar rules, or does it rather feel out of scope?

# currently
ParamWithDefault ::="$" EQName TypeDeclaration? (":=" StandaloneExpr)?
Param ::= "$" EQName TypeDeclaration?
# could be
ParamWithDefault ::= Param (":=" StandaloneExpr)?`
Param ::= "$" EQName TypeDeclaration?

# currently
SchemaAttributeTest ::= "schema-attribute" "(" AttributeDeclaration ")" 
AttributeDeclaration ::= AttributeName 
AttributeName ::= EQName 
# could be
SchemaAttributeTest ::= "schema-attribute" "(" EQName ")" 

# currently
WindowVars ::= ("$" CurrentItem)? PositionalVar? ("previous" "$" PreviousItem)? ("next" "$" NextItem)?
CurrentItem ::= EQName
PreviousItem ::= EQName
NextItem ::= EQName
LetBinding ::= "$" VarName TypeDeclaration? ":=" StandaloneExpr
PositionalVar ::= "at" "$" VarName
VarName ::= EQName
VarRef ::= "$" VarName
# could be
WindowVars ::= ("$" EQName)? PositionalVar? ("previous" Var)? ("next" Var)?
LetBinding ::= Var TypeDeclaration? ":=" StandaloneExpr
PositionalVar ::= "at" Var
VarRef ::= Var
Var := "$" EQName

# currently
MapConstructorEntry ::= MapKeyExpr ":" MapValueExpr
MapKeyExpr ::= ExprSingle
MapValueExpr ::= StandaloneExpr
# could be
MapConstructorEntry ::= ExprSingle ":" StandaloneExpr

# currently
ForwardAxis ::= ("child" "::") | ("descendant" "::") | ("attribute" "::") | ("self" "::") |
  ("descendant-or-self" "::") | ("following-sibling" "::") | ("following" "::")
# could be
ForwardAxis ::= ("attribute" | "child" | "descendant" | "descendant-or-self" |
  "following" | "following-sibling" | "self") "::"

# currently
CompNamespaceConstructor ::= "namespace" (Prefix | EnclosedPrefixExpr) EnclosedURIExpr
Prefix ::= NCName
EnclosedPrefixExpr ::= EnclosedExpr
# could be
CompNamespaceConstructor ::= "namespace" (NCName | EnclosedExpr) EnclosedURIExpr

# currently
Argument ::= StandaloneExpr | ArgumentPlaceholder
ArgumentPlaceholder ::= "?"
# could be
Argument ::= StandaloneExpr | "?"

…and so on.

PS: If we tweak the grammar, I would propose to rename ExprSingle to SingleExpr.

[michaelhkay]

Some of the redundancy is probably historical cruft, or plain oversight of the refactoring opportunities.

Some may be to provide a handle for grammar productions that can be used in the prose when describing the semantics, for example the rule SwitchCaseOperand ::= Expr allows the prose to speak of the SwitchCaseOperand.

Some may be due to quirks of the technology that was used in the past to generate the executable code of the Java applets that were once published on the W3C website.

One thing to bear in mind is that the names of grammar rules may appear elsewhere than in the specs. They can find their way into books and tutorials, and into product error messages. Renaming ExprSingle to SingleExpr may therefore have wider implications than you first imagine.

[ChristianGruen]

Thanks for the recent PR, which has addressed some of the suggestions from the initial comment. I am reopening this issue as some simplifications have not been considered yet:

"$" VarName is used multiple times in the grammar. Would it make sense to introduce Var := "$" EQName to reduce redundancy, as proposed above?

In addition, we have production rules like GroupingVariable ::= "$" VarName, but GroupingVariable is used nowhere in the text. We could simply use Var instead.

[michaelhkay]

I have done some further refactoring of productions relating to variable names under PR #1498