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 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>.

This sounds fine to me.

>I don't buy this argument. <oneOrMore> just like <group> treats attributes
>differently from children.  So what? We don't disallow

It is true that <group> plays two roles:  merging of attribute sets, and 
concatenation of contents.  These two roles are orthogonal: they 
can be always separated and can also be combined.

For example, 

<group>
  <group>
    <element name="foo1"><empty/></element>
    <attribute name="foo1"/>
  </group>
  <group>
    <element name="foo2"><empty/></element>
    <attribute name="foo2"/>
  </group>
</group>

is equivalent to

<group>
  <group>
    <element name="foo1"><empty/></element>
    <element name="foo2"><empty/></element>
  </group>
  <group>
    <attribute name="foo1"/>
    <attribute name="foo2"/>
  </group>
</group>


Meanwhile, <oneOrMore> also plays two roles.  But they are *not*
orthogonal; if we do not impose any restrictions, we deviate from the
realm of the tree regular language.

We have introduced restrictions.  Having clarified the semantics 
of <oneOrMore>, I think that this construct now plays two non-orthogonal 
roles and that it is much more appropriate to have two constructs 
(which may have the same tag name).

>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>

We only have to write:

  <define name="any">
    <element>
      <anyName/>
<!-- attributes-->
      <zeroOrMore>
        <attribute>
          <anyName/>
        </attribute>
      </zeroOrMore>
<!-- contenst-->
      <zeroOrMore>
        <choice>
          <text/>
          <ref name="any"/>
        </choice>
      </zeroOrMore>
    </element>
  </define>

I think that this rewrite is easier than your original.

>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.

I think that the current restriction is extremely hard to understand.
Do you really think that the BNF in 7.1 is easy to learn?

In my proposal, we can get rid of "repeatable" and rewrite 
the production rule for "nonEmptyPattern".

nonEmptyPattern   ::=   attributeGroup
| value
| mixed
| <choice> pattern nonEmptyPattern </choice>
| <group> attributeGroup nonEmptyPattern </group>
| <group> nonEmptyPattern attributeGroup </group>
| <interleave> attributeGroup nonEmptyPattern </interleave>
| <interleave> nonEmptyPattern attributeGroup </interleave> 

Simply put, the content of <oneOrMore> is either:

(1) attribute-free, or

(2) <attribute> or <choice><attribute>...<attribute>.

Cheers,

Makoto


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


Powered by eList eXpress LLC