OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [relax-ng] Further comments on the compatc syntax spec


1. General

1) Use of attribute grammars.

Having read Annex A.1 more carefully, I more strongly believe that
we should use attribute grammars.  First, attribute grammars provide
a standard technique in computer science.  Second, we can more
clearly separate syntactical rules and semantic rules.  Third, we
can explicitly name synthesized attributes thus improving
readability.  Fourth, by replacing arguments and parameters by
inherited attributes, we can make this BNF more readable.

James, please send me the XML source file and XSLT stylesheet.  I
will then create an attribuge-grammar-version of A.1.

2) Checking constraints

A.1 provides many constraints.  In my understanding, they are
powerful enough to ensure that conformant translators do not create
XML documents that violates the XML recommendation and the namespace
recommendation.  However, they are not powerful enough to ensure
that thus created documents are correct RELAX NG schemas.
Nevertheless, some constraints (e.g. Constraint: name class except),
are borrowed from the RELAX NG spec.  Are they really required?
After all, RELAX NG validators will check every constraint in the
RELAX NG spec.


2. Specific

- The third para of A.1.  "named non-terminals" should read
  "named terminals".  (Does the spec use two BNFs (one for 
  lexical analysis and another for real work) or one BNF?

- What is a context in this spec?  It appears that contexts include
  datatype declarations.  However, contexts are not defined in this 
  spec, and contexts in this spec are different from contexts 
  defined in the RELAX NG spec.  It is probably a good idea to 
  pick a different word.

- foo(x, y) should read foo(x, y, ...), since more than two
  arguments are allowed.  

- bindDatattypePrefix and lookupDatatypePrefix are unclear, since
  contexts are not clearly defined.

- stripFirstSpace is not defined.

- semantic rules for particleChoice, particleGroup,
  particleInterleave are incorrect.  (<choice>, <particle>, and
  <interleave> are missing)

- Media types RFC should be introduced as normative references.

- I do not quite understand A.2.5.  I might be wrong, but comments
  beginning with not ## but # do not appear to be addressed anywhere 
  in Appendix A.

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC