Re: Reopening Issue 26: regularityConstraint

[James Clark <jjc@jclark.com>]

> 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