[relax-ng] Re: Attribute grammars

["MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>]

"James Clark" <jjc@jclark.com> wrote:

> 1. In the semantic rule for the nameClass production:
> 
> x.elem := elem.rng
> 
> should not elem.rng be _.elem?

Right.  This is a bug.

> 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)

Hers is such a list.

1) Synthesized semantic attributes

- rng
	a pattern constructed for the current 
	non-terminal

- synthesizedContext

	namespace or datatype declarations that
	are declared in or precedes the current non-terminal

- val
	a string value

- anno
	a set of annotation attributes and a sequence of 
	annotation elements

Note: should we omit this and rather use annoElems and annoAtts only?

- annoElems
	a sequence of annotation elements

- annoAtts
	a set of annotation attributes

- annoCont
	a sequence of annotation elements or strings

Note: should we omit annoElems and use annoCont?

- dataAtts
	attributes for a <data> pattern

- nsAtts
	an empty set or a set containing an "ns" attribute.
	
2) Inherited semantic attributes

- context
	namespace or datatype declarations that
	precedes the current non-terinal

- isElem
	a boolean indicating whether a name class represented 
	by the current non-terminal applies to <element> patterns


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

Good idea.  

> 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)

That is a possibility.  However, does it help to distinguish 
RELAX NG patterns and annotations.

One problem in my rewrite is too many semantic attributes for annotations.
I think that two would be enough: one for RELAX NG patterns and another for 
sequences of annotation elements or strings.

> 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.

Right.

> 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.

Does the above list of semantic attributes address this concern?  We 
can introduce two sets of operators (e.g., ":=" and "<-") if your like.

> 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.

Agreed.

> 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.

I think that this separation helps readability.  At least, I would like to 
distinguish annotation attributes and other attributes, since handling of 
annotations is the most difficult part of A.1.

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

Right.

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

Agreed.  It represents the union of two sets.

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

Right.

> 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.

Agreed.

> 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).

This is another bug of my XSLT.

Cheers,

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>