- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Fri, 21 Aug 2026 14:55:57 +0000
- To: ixml <public-ixml@w3.org>
- Message-Id: <1787323896109.703163021.1914983133@cwi.nl>
It has been pointed out that it is easy to let an empty alternative slip in to a grammar unintended, and therefore it would be advantageous to require an empty alternative to be explicitly marked as such, in other words, this would no longer be permitted:
thing-option: thing; .
and you would be required to write
thing-option: thing; SOMETHING HERE.
We have to agree on what that SOMETHING HERE is.
Strictly speaking, empty alternatives are not necessary, since anywhere you can write
a: b, c, d; .
you can just as easily write
a: (b, c, d)?.
So one option is just to forbid empty alternatives altogether. This would also be backwards compatible: existing implementations would still do the same thing.
On the other hand, converting grammars from other syntax languages would be made (slightly) harder if they have empty alternatives.
The syntax of a rule (for clarity leaving spacing out) is currently
rule: naming, -["=:"], -alts, -".".
and alts is
alts: alt++-[";|"].
alt: term**-",".
-term: factor;
option;
repeat0;
repeat1.
-factor: terminal;
nonterminal;
insertion;
-"(", alts, -")".
The fact that an alt can be empty is because of the ** in that rule.
That means that to require an alt to be non-empty needs to change the ** to ++, and add an explicit thing for the empty case:
alt: term++-","; empty.
empty: SOMETHING HERE.
Note that alts can also be bracketed in a rule:
a: b, (c, d; ), e.
so the visible empty alternative would be needed there too, but we don't have to do anything special for that case, since the syntax would already cover it.
OPTIONS
1. As mentioned above, remove the concept of an empty alternative altogether:
alt: term++-",".
2. Use some particular symbol(s) to mark an empty alternative, such as:
a special character such as &, 0, *, 𝛆
(note this latter is not a Greek letter but a maths symbol)
an empty string ""
an empty bracket pair ()
an empty comment {}
Ideally it would be good to use something that is backwards compatible with existing implementations, so that grammars that used the new syntax still worked with old implementations.
That would rule out the special characters, and the empty string. Empty comment would be hard to implement, since comments are already part of the definition of whitespace.
This leaves "()".
alt: term++-","; -"()".
Advantages: Backwards compatible; produces exactly the same XML serialisation of alts, still allows empty alternatives.
Steven
Received on Friday, 21 August 2026 14:56:11 UTC