Ah, yes. It is always java... Guess it shows how much time has passed since I used Grammatica myself. ;-)
The problem is in the rule CellParameterList (found that out by commenting out the suspicious rule bodies one by one). It seems that the rule bodies "... (A B C?)? ..." are problematic, i.e. using nested optional elements. Better to break this out as separate rules.
The reason for the loop here is probably related to the Grammatica analysis of the tokens used in each rule. When too much is optional, this set grows very large and risks triggering these kind of issues.
Solution:
CellParameterList = "(" CellParameters ")" ;
CellParameters = CellParameter ("," CellParameter)* ;
CellParameter = "width" "=" NUMBER
| "height" "=" NUMBER
| "verticaloffset" "=" NUMBER
...
Better still might be to break out these even further:
HeightParameter = "height" "=" NUMBER ;
VerticalOffsetParameter = "verticaloffset" "=" NUMBER ;
A few further comments:
1. XML is hard to parse properly with a tool like Grammatica, since its structure cannot be fully captured in regex tokens and LL(k) productions in a sensible manner. That said, it is still possible to create something useful for machine-generated inputs.
2. The grammar would be easier and faster if fewer regexes were used. Use case-insensitive tokens for example. And create tokens that have a "higher level". Like this:
CASESENSITIVE = false
...
WHEN_START = "<xsl:when>"
WHEN_END = "</xsl:when>"
3. Use the token strings in the rules to make things more readable. Such as in the example Cell* rules above.