Re: attributes containing subordinate attributes

[Murata Makoto <mura034@attglobal.net>]

James Clark wrote:

> I would like to consider this in a general way, rather than on a case by
> case basis.  I am very keen to avoid complicating both the spec and
> implementations with numerous ad hoc restrictions.

Here is my rewrite, which you would probably call ad-hoc.

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:oneOrMore> textPattern </t:oneOrMore> 
/* If we do not need <t:oneOrMore><t:empty/></t:oneOrMore> or
   <t:oneOrMore><t:notAllowed/></t:oneOrMore>,  this is not very useful.  
   <t:oneOrMore><t:string>foo</t:string></t:oneOrMore> is already covered by 
   the list construct of XML Schema Part 2.
*/

 | <t:group> textPattern textPattern </t:group> 
/* If we do not need <t:group>hedgePattern <t:empty/></t:group> or 
   <t:group>hedgePattern <t:notAllowed/></t:group>, this is not very userful.
*/

 | <t:choice> textPattern textPattern </t:choice> 
/* Do we really need choice of datatypes or string literals?  XML Schema 
   Part 2 already provides it.  */

 | <t:ref name="NCName" parent/> 
/* Do we really need another mechanism for user-defined datatypes?  XML Schema 
   Part 2 already has one.*/


hedgePattern  ::= textPattern
 | <t:element> name-class hedgePattern </t:element> 
 | <t:attribute> name-class textPattern </t:attribute> 
 | <t:oneOrMore> hedgePattern </t:oneOrMore> 
 | <t:group> hedgePattern hedgePattern </t:group> 
 | <t:choice> hedgePattern hedgePattern </t:choice> 
 | <t:ref name="NCName" parent/> 
 | <t:grammar> <t:start> hedgePattern </t:start> definition* </t:grammar> 

Cheers,

Makoto