-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serialization of the outermost nonterminal as an attribute should be a grammar error #47
Comments
👍 |
I thought we agreed to disallow @ on the root.
I had consequently changed the spec to read:
"The first rule in a grammar may not be marked as an attribute. If it is marked as hidden, all of its productions must produce exactly one non-hidden non-attribute nonterminal and no non-hidden terminals before or after that nonterminal."
|
I was wrong, we had not agreed to it, just raised it as an issue. -root: a; b. The proposed text "The first rule in a grammar may not be marked as an attribute. If it is marked as hidden, all of its productions must produce exactly one non-hidden non-attribute nonterminal and no non-hidden terminals before or after that nonterminal." attempts to cover such cases. |
It should be noted in passing that such a restriction doesn't reduce the power of a grammar, since @ root: a, b, c. can be rewritten -dummy: ^root. |
I agree that referring to the start symbol does not suffice, but the proposed wording does not refer to the start symbol. In the wording change I made, I read the preceding sentence as having implicitly defined the term "the root node" as denoting the outermost nonterminal being serialized, not necessarily the start symbol of the grammar. If there are other or better ways to express the change, that's fine. |
We discussed this on the call of 22 February 2022. ACTION (20220222-03): Steven - Issue #47 - @root (Outermost effective nonterminal as attribute) - to be proposed in the spec as a dynamic error. ACTION (20220222-04): Steven - simplify the spec to require the output of 'well-formed' XML. Does that have some subcodes in terms of the violation of well-formedness. (Issues #25, #18, #23, #31, #47.) |
Steven reports this is resolved. |
Consider the grammar
The current spec says the sentence "
a
" should be serialized as<S>a</S>
despite the@
marker, since otherwise we won't have XML output.But in other cases which seem parallel (i.e. they involve a conflict between the rule that the output of an ixml processor is XML and the rule that the marks on nonterminals are to be obeyed), the spec -- or what I take to be consensus in the group -- says (sometimes not quite explicitly) that there is an error in the grammar:
All these cases should be treated on the same footing. They can all be grammar errors, or they can all be situations for which recovery is allowed or prescribed. Their common characteristic is that they involve a conflict among the principles:
I think these principles are all good ones and should be preserved. Since any recovery from the error will involve violating one or the other of them, I do not think error recovery should be prescribed or allowed as conformant behavior.
Concrete proposal: in the section "Serialization", delete
and insert
This assumes that at some point we are going to insert a definition of dynamic errors and say something about how they are signaled.
The text was updated successfully, but these errors were encountered: