Issue: duplicate attributes

[James Clark <jjc@jclark.com>]

At the moment, the following pattern is allowed:

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

This is clearly a useless pattern, which could only result from a user
error; it would be nice if the TREX processor could catch this.  I
haven't succeeded in coming up with a satisfactory general rule on
this.  Here are some of the problems I've run into.

It's common to have a collection of common optional attributes:

<define name="common.atts">
  <optional>
    <attribute name="id">
      <data type="xsd:ID"/>
    </attribute>
  </optional>
  ...
</define>

Sometimes, you want one of the common atts that is normally optional to
be required on one particular element.  With TREX at the moment, you can
simply do this:

<element name="def">
  <ref name="common.atts"/>
  <attribute name="id">
    <data type="xsd:ID"/>
  </attribute>
  ...
</element>

If the rule was that a pattern must not permit duplicate attributes,
then the above approach would not be possible.

If instead you have a rule that a pattern must not *require *duplicate
attributes, then consider the following:

<define name="a-or-b">
  <choice>
    <attribute name="a"/>
    <attribute name="b"/>
  </choice>
</define>

<start>
  <element name="foo">
    <ref name="a-or-b"/>
    <ref name="a-or-b"/>
  </element>
</start>

This would be OK, because it matches <foo a="xxx" b="xxx"/>.  On the
other hand,

<start>
  <element name="foo">
    <ref name="a-or-b"/>
    <ref name="a-or-b"/>
    <ref name="a-or-b"/>
  </element>
</start>

would be illegal because all matches have duplicate attributes.  This
seems very hard to implement.

James