[relax-ng] Attribute grammars

[James Clark <jjc@jclark.com>]

> On Tue, 24 Sep 2002 02:20:06 +0900
> "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> wrote:
>
> > I have created an attribute-grammar version of A.1.  It is not complete
yet,
> > but it is good enough to demonstrate the idea.  I think that use of
attribute
> > grammars make this spec more readable.
>
> Here is a more complete version of "A. Formal description".
>
> http://www.asahi-net.or.jp/~eb2m-mrt/hidden/compactMurata.html
>
> Please let me know if this is readable.

I finally got round to looking at this.  Sorry for the delay. Some comments:

1. In the semantic rule for the nameClass production:

x.elem := elem.rng

should not elem.rng be _.elem?

2. There ought to be a list of sematic attributes along with a precise
description of their types (single element, sequence of elements, string,
etc)

3. I would suggest renaming the elem attribute to isElem.

4. I would suggest combining the annoElems and rng attributes into a single
attribute and calling it xml; the type would be a sequence of zero or more
elements in the data model.  I don't think there's a useful distinction
between these two attributes; for example, look at the rule for
innerParticle:

 _.rng := (applyAnnotations(_.anno, x.rng), y.annoElems)

5. I would also use the xml attribute instead of the annoCont attribute,
chaning the type of the xml attribute to be a sequence containing zero or
more elements and strings.

6. I find it confusing that there is no distinction between semantic rules
that pass information down the parse tree and semantic rules that pass
information up the parse tree.  To a programmer these are very different
things (arguments v return values); I think the notation insufficiently
distinguishes these.

7. There's a formatting glitch with the := operator: the colon in the
operator in the first semantic rule for an alternative comes out italic and
bold, whereas the colon in the second and subsequence alternatives comes out
roman and non-bold.

8. I would merge nsAtts, dataAtts and annoAtts into a single semantic
attribute names atts, whose value is a set of zero or more attributes in the
data model.

9. In the rule for prefixedAnnotationAttributes and annotationAttributes,
the semantic rule for epsilon should assign an empty set, not an empty
sequence.

10. There's no description of plus on two sets, used in eg
prefixedAnnotationAttributes.

11. The semantic rule for ref is wrong. Should be _.val = x.val I think.

12. When there are multiple rules in a single set of braces, then I think it
would look prettier if the second and subsequent rules where indented to
align with the start of the first rule rather than with the opening brace.

13. In the description of various functions before the grammar, why is
everything suffixed with rng? (e.g. prefix(x.rng) returns the prefix of the
qualified-name x.rng).

My overall feeling is that this new notation is more rigorous and less
ad-hoc than my original notation.  However, I think the main audience for
this Annex is implementors, who are primarily programmers not computer
scientists.  We need to make sure the notation makes sense to a programmer
who I would guess would be more likely to be familiar with parser generators
(JavaCC, yacc etc) than with attribute grammars.  If we can find a good way
to fix my comment 6, then I think we can have a notation that both makes
sense to our main audience and has a solid formal basis. Another worry I
have is that it is going to take significant effort to fix all the problems
in this new notation and make sure all the bugs have been squashed.

James