This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi, As known, QNames receives different treatment depending on context -- what default namespace that should be used. This could be communicated in the EBNF by having two rules that both expand to the QName token, referenced from the appropriate productions. An example: FunctionQName ::= QName ElementQName ::= QName NameTest ::= ElementQName | Wildcard FunctionCall ::= <FunctionQName "("> (ExprSingle ("," ExprSingle)*)? ")" ... I would find the grammar useful in that way; the question is if that should be valued higher than the increased complexity, and change in EBNF at this stage of development. But it is also nothing more than a suggestion. Cheers, Frans
(In reply to comment #0) I don't believe that our grammar need be designed to reflect this kind of semantics processing. The author of the comment should feel free to organize his own grammar/parser in this way since the change has no external effect.
I see a resemblance to how variable names are distinguished by the VarName construct. But this is really minor, I wouldn't object if it got closed. Cheers, Frans
A joint meeting of the Query and XSLT working groups considered this comment on July 20, 2005. The WG agreed to resolve this issue as per my previous comment. If you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then change the Status of the record to Reopened. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.