[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Reopening Issue 26: regularityConstraint
> I propose to reopen Issue 26 for two reasons. I would like > to disallow <oneOrMore> containing both <attributes> and <ref ..> > (which references to a named pattern representing an element). I think it is clearer to treat this as a new issue: issue 26 is quite broad, whereas your issue is restricted to whether or not we should allow mixing both <ref> and <attribute> inside a single <oneOrMore>. > For example: > > <oneOrMore> > <choice> > <ref name="foo"/> > <attribute name="bar"/> > </choice> > </oneOrMore> > > First, after the decision for Issue 26, we changed the semantics > of oneOrMore so that it disallows colliding attributes. One could > thus argue that the keyword oneOrMore represents two different constructs: > one is to allow repetition of elements freely and the other > is to allow non-colliding repetition of attributes. I don't buy this argument. <oneOrMore> just like <group> treats attributes differently from children. So what? We don't disallow <group> <choice> <element name="foo"><empty/></element> <attribute name="foo"/> </choice> <choice> <element name="bar"><empty/></element> <attribute name="bar"/> </choice> </group> so why should we disallow <oneOrMore> <choice> <element name="foo"><empty/></element> <attribute name="foo"/> </choice> </oneOrMore> ? > Second, the BNF created by James becomes simpler if we disallow > coexistense of attributes and elements in <oneOrMore>. That's true. On the other hand, this prohibits something reasonable and indeed useful. The simplest, easiest way to write a pattern that matches any element is: <define name="any"> <element> <anyName/> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <text/> <ref name="any"/> </choice> </zeroOrMore> </element> </define> I have used this in many RELAX NG schemas. I wasn't trying to be tricky; it just seemed to be the simplest, easiest way to do things. The other restrictions are justified either by helping to catch user errors or by facilitating implementation. I don't think this proposed change would either help catch user errors or facilitate implementation. Rather it would make the language harder to learn: users would have to remember that one natural, straightforward way to writing a pattern that matches any element doesn't work. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC