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 (duplicateAttributes)


I am totally confused.  If more than one <attribute ...> element
within a single content model is satsified by an attribute, are ALL of
them consumed?  Or, is only ONE of them consumed?

James Clark wrote:

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

As an example, consider:

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

and 

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

You first replace <ref name="common.atts"/> with the body of the first
define element and obtain

<element name="def">
  <optional>
    <attribute name="id">
      <data type="xsd:ID"/>
    </attribute>
    <attribute name="bar">
      <data type="xsd:short"/>
    </attribute>
  </optional>
  <attribute name="id">
    <data type="xsd:ID"/>
  </attribute>
  <attribute name="bar">
    <data type="xsd:short"/>
  </attribute>
</element>

Suppose you encounter a start tag of the tag name "def".  You create 
a content model:

<group>
  <optional>
    <attribute name="id">
      <data type="xsd:ID"/>
    </attribute>
    <attribute name="bar">
      <data type="xsd:short"/>
    </attribute>
  </optional>
  <attribute name="id">
    <data type="xsd:ID"/>
  </attribute>
  <attribute name="bar">
    <data type="xsd:boolean"/>
  </attribute>
</group>

Suppose this tag name has id="f" and bar="1" in this order.  By
removing <attribute...> elements that match id="f", you create:

<group>
  <optional>
    <attribute name="bar">
      <data type="xsd:short"/>
    </attribute>
  </optional>
  <attribute name="bar">
    <data type="xsd:boolean"/>
  </attribute>
</group>


Here I assume that you consume ALL attribute elements that
match id="f".

Then, by removing <attribute ...> elements that match bar="1", 
you create 

<group>
  <optional>
  </optional>
</group>

Again, I assume that you consume ALL <attribute...> elements that
match bar="1".

I might be wrong.  If you consume ONE <attribute ....> element, 
you first obtain 

<group>
  <optional>
    <attribute name="id">
      <data type="xsd:ID"/>
    </attribute>
    <attribute name="bar">
      <data type="xsd:short"/>
    </attribute>
  </optional>
  <attribute name="bar">
    <data type="xsd:boolean"/>
  </attribute>
</group>

and then obtain

<group>
  <optional>
    <attribute name="id">
      <data type="xsd:ID"/>
    </attribute>
    <attribute name="bar">
      <data type="xsd:short"/>
    </attribute>
  </optional>
</group>

This does not mandate any attributes, and is thus satisfied.  Which 
interpretation is correct?

James Clark wrote:

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

I do not understand.  Even if you have three <ref name="a-or-b"/> 
elements, you create:

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

If you have <foo a="">, you create a content model

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

and rewrite it by consuming ALL <attribute> elements 
and obtain 

<group>
</group>

This looks perfectly fine to me.  If you consume ONE attribute 
element, you create 

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

Which interpretation is correct?

Cheers,
  

Makoto


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


Powered by eList eXpress LLC