- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 2 Dec 2008 06:30:17 +1100
- To: Kartikaya Gupta <lists.webapps@stakface.com>
- Cc: public-webapps@w3.org
Kartikaya Gupta: > The example in the java-modules section has a > typo; it says "org.foo.ext.FooDocument" instead of > "org.foo.ext.ExtendedFooDocument". Thanks, fixed. > Also, I'm not sure if this matters, but while implementing I > realized that having both [TheExtendedAttribute=identifier] and > [TheExtendedAttribute=ScopedName] leads to an ambiguous grammar, since > [foo=bar] can be interpreted as both. Presumably this would lead to > shift-reduce conflicts with a context-free parser generator. For my > implementation I always resolve it to be a ScopedName and then use > either the prefixed name or the unprefixed name depending on which > attribute it is. Indeed, that’s part of why I’ve held off updating the grammar. I plan to change the grammar to parse any balanced content between commas in square brackets as an ExtendedAttribute, and to then have rules like: ExtendedAttributeScopedName → identifier "=" ScopedName along with a statement “if it matches ExtendedAttributeScopedName, then the extended argument takes a ScopedName”. This would happen to make some extended attributes be more than one of these types (like the single identifier matching both the ScopedName and identifier argument forms), but I wouldn’t have any extended attributes defined that could take both. The above would then allow me to say that any other balanced sequence of tokens that was found between commas is some extension that can be ignored. (Where by “balanced” I mean balanced brackets, quotes, etc., which should cover most cases that people would want to do in their own extended attributes.) -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 1 December 2008 19:31:14 UTC