OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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

    <element name="foo"><empty/></element>
    <attribute name="foo"/>
    <element name="bar"><empty/></element>
    <attribute name="bar"/>

so why should we disallow

     <element name="foo"><empty/></element>
     <attribute name="foo"/>


> 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">
          <ref name="any"/>

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC