[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