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: Issue: duplicate attributes


> I think allowing multiple attributes is potentially confusing for
> users, and not hard to work around, so I'm inclined to forbid it.

I have remembered some more problems I ran into.

1. Attributes can use name classes.  Presumably, something like

<element name="foo">
    <attribute>
      <choice>
          <name>a</name>
          <name>b</name>
      </choice>
     </attribute>
     <attribute>
         <name>a</name>
     </attribute>
  </element>

would also need to be an error.  In general, I guess the rule would be that
in

  <group>p1 p2</group>

the intersection of the set of attribute names possible in p1 and the set of
attribute names possible in p2 must be empty.  Is it always possible to
determine whether the intersection of two name classes is empty?  (I think
so, but I would need to do some work to be sure.)

2. What about applying oneOrMore or zeroOrMore to attribute?  If

  <group>
    <attribute name="a"/>
    <attribute name="a"/>
  </group>

is an error, then a fortiori so should

  <oneOrMore>
     <attribute name="a"/>
  </oneOrMore>

? But we can't completely disallow the application of oneOrMore or
zeroOrMore to patterns containing attributes because we need:

  <zeroOrMore>
    <attribute>
       <anyName/>
    </attribute>
  </zeroOrMore>

or

  <zeroOrMore>
     <attribute>
         <not>
            <nsName/>
          </not>
      </attribute>
    </zeroOrMore>

I don't see a good solution to 2.  We could distinguish two kinds of name
class: wildcards and non-wildcards.

wildcard ::=  <anyName/>
                     | <nsName/>
                     | <choice> wildcard wildcard </choice>
                     | <difference> wildcard nameClass </difference>

nonWildcard ::= <name>...</name>
                           | <choice> nonWildcard nonWildcard </choice>
                           | <difference> nonWildcard nameClass
</difference>

Then the nameClass for an attribute would be either a wildcard or a
nonWildcard; the semantics of attribute when it is a wildcard would be to
allow zero or more such attributes.  Or perhaps we could use a separate
<anyAttribute/> element in this case.

It all seems a lot of complication just to detect an error.

James








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


Powered by eList eXpress LLC