Re: Issue: Should we disallow nested grammars?

[Murata Makoto <mura034@attglobal.net>]

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