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


For dtds: "When more than one AttlistDecl is provided for a given element
type, the contents of all those provided are merged. When more than one
definition is provided for the same attribute of a given element type, the
first declaration is binding and later declarations are ignored." from
http://www.w3.org/TR/REC-xml.html#attdecls

This to me suggests that:

if attribute decl 1 == attribute decl 2, then decl 1 wins and decl 2 (plus
any others that == 1) are ignored.

what else is necessary? Let users write "useless patterns" i.e. multiple
matching atts, but don't call such patterns valid?

-Mike F.

> -----Original Message-----
> From: James Clark [mailto:jjc@jclark.com]
> Sent: Tuesday, April 24, 2001 8:32 PM
> To: TREX Discussion List
> Subject: Issue: duplicate attributes
>
>
> 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
>
>



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


Powered by eList eXpress LLC