Attribute markings - a question

Consider the grammar 

S : @able, baker, @charlie.
able: string.
baker: string.
charlie: string.
string: ~[]*.

Is this grammar OK?  (Yes, it’s hopelessly ambiguous, but that’s beside the point.)

If we ignored the annotations, a raw parse tree for this grammar might look like this:

<S>
  <able mark=“@"><string>aaa</string></able>
  <baker><string>aaa</string></able>
  <charlie mark=“@"><string>ccc</string></able>
</S>

Note that ‘string’ is implicitly marked serializable (^).  

When a nonterminal marked to be serialized as an element appears as a child of a nonterminal marked to be serialized as an attribute (as ’string’ here appears as a child of @able and @charlie), is the rule 

- Raise an error because the grammar cannot be serialized that way?

- Omit the content of ’string’ from the value of @able and @charlie by analogy with what happens when we calculate the text node children of an element?

- Ignore the marking on ’string’ on the grounds that we have already been told that @able is an attribute.  Since elements cannot appear within attributes, the implicid ^ marking on ’string’ is ignored.

The grammar for ixml offers two examples that seem relevant:  in a raw parse tree, @name will dominate nodes labeled namestart and namefollower, which are explicitly marked non-serializable (-).  @dstring and @sstring similarly dominate nodes labeled dchar and schar, which are implicitly marked ^.  The attributes @from and @to directly dominate nodes labeled ‘character’ (marked -) and indirectly dominate  nodes labeled ‘dchar’ and ’schar’ (implicitly ^).

In the spirit of making things as simple as possible for the grammar authors, I suppose the right rule is “when constructing the value of an attribute, treat nonterminals marked ^ and - the same:  recur through them” (the last possibility mentioned above).

I apologize if this has been discussed before - I have the guilty sensation that it has been, and that I did not retain the answer.

Michael

Received on Wednesday, 13 October 2021 02:19:24 UTC