James Clark wrote:
> > At present, nesting of grammars is freely allowed. I propose
> > to disallow such nesting in V1.0.
>
> I strongly disagree with this. I believe it to be a very good feature of
> TREX that it allows all forms of pattern to be composed with very few
> restrictions. A grammar is just another kind of pattern.
With respect, I disagree. I do not think it is a good feature. I am not
sure if the restrictions can be easily explained. I think that unsatisfiable
patterns (e.g., elements within attributes) confuse users.
Here is a rewrite of the BNF for the basic syntax. It is ad-hoc but
tighter: elements/attrbutes within attributes are excluded and
the restriction on combining datatypes is not required.
grammar ::=
<t:grammar> <t:start> nonTextPattern </t:start> definition* </t:grammar>
definition ::= <t:define name="NCName"> (textPattern | nonTextPattern) </t:define>
textPattern ::= <t:anyString/>
| <t:string white-space> string </t:string>
| <t:data type="NCName" ns="namespaceURI"/>
| <QName t:role="datatype" attributes> anything </QName>
| <t:empty/>
| <t:notAllowed/>
| <t:choice> textPattern textPattern </t:choice>
| <t:ref name="NCName" parent/>
nonTextPattern ::=
<t:element> name-class (textPattern | nonTextPattern) </t:element>
| <t:attribute> name-class textPattern </t:attribute>
| <t:oneOrMore> nonTextPattern </t:oneOrMore>
| <t:group> nonTextPattern nonTextPattern </t:group>
| <t:choice> nonTextPattern nonTextPattern </t:choice>
| <t:choice> textPattern nonTextPattern </t:choice>
| <t:choice> nonTextPattern textPattern</t:choice>
| <t:interleave> nonTextPattern nonTextPattern </t:interleave>
| <t:ref name="NCName"/>
name-class ::= <t:name ns="namespaceURI"> NCName </t:name>
| <t:anyName/>
| <t:nsName ns="namespaceURI"/>
| <t:choice> name-class name-class </t:choice>
| <t:difference> name-class name-class </t:difference>
white-space ::= whiteSpace="preserve"
| whiteSpace="normalize"
> Yes, it is easy for computers. But for humans, it means they have to create
> a copy of a pattern and rename definitions. This renamed copy has to be
> kept in sync with the original whenever it changes.
Yes. But a simple XSLT stylesheet would work.
> > Second, I believe that modularization mechanisms requires further study.
> > I think that it is dangerous to provide nested grammars without fully
> > understanding modularization.
>
> Wherein lies the danger?
In XML Schema and RELAX, each module has a target namespace. A multi-lingual
schema consists of a collection of such modules. In other words, modularization
in these language is based on namespaces.
TREX does not provide any such high-level mechanisms. Rather, it provides a
low-level mechanism: each name is an URI-localName pair.
I agree not to introduce a high-level mechanism in V 1.0 of our language, but
I would like to keep the door open. However, I am not sure if nesting of
grammars does not prevent such future mechanisms. If you convince
me that the door is open, I can probably be persuaded.
Cheers,
Makoto
