[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [relax-ng] Attribute grammars
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC