[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Comments on RELAX NG 2001-06-08
Rick Jelliffe wrote: > Issue 21. duplicateAttributes: prohibiting duplicate attributes > -------------------------------------------------------------------------- > > Why not make duplicate attribute declaration operate in parallel? > > Since it is impossible to have duplicates in XML, any regular expression can > only act as if it were a logical expression w.r.t. attributes. So any > operation that is not an OR will be an AND: sequence should AND, so ( @a, > @a ) would be perfectly fine: > @a AND @a which = @a. In an early version of RELAX Core, I did the same thing. But this makes type assignment for simple types ambiguous, since two <attribute> for the same attribute name can have different datatypes. In particular, Relaxer had a big problem about such duplicated declarations. Thus, I later dropped this feature from RELAX Core. Furthermore, this appoarch makes validation of RELAX NG very difficult or even impossible. As an example, consider <group> <choice><group><attribute name="foo"/><ref name="bar11"/></group> <ref name="bar12"/> </choice> <choice><group><attribute name="foo"/><ref name="bar21"/></group> <ref name="bar22"/> </choice> </group> In your approach, when the attribute "foo" is present, this is equivalent to (bar11, bar21) | (bar12, bar21) | (bar12, bar22) . If it is absent, this is equivalent to (bar12, bar22). However, I do not think we can implement this semantics. When we have <... foo="">, what is our derivative? If we simply consume both <attribute>s, we have <group> <choice><ref name="bar11"/> <ref name="bar12"/> </choice> <choice><ref name="bar21"/> <ref name="bar22"/> </choice> </group>, but this incorrectly permits (bar12, bar22). If we consume one of the two <attribute>s, we do not have the AND interpretation in other cases (e.g., <group><attribute name="foo"/> <attribute name="foo"/></group>). Suppose we consume both <attribute>s after introducing <doesNotExist>. (More about this, see http://lists.oasis-open.org/archives/relax-ng/200106/msg00118.html) Then, we first have <group> <choice><group><attribute name="foo"/><ref name="bar11"/></group> <group><doesNotExist><attribute name="foo"/></doesNotExist> <ref name="bar12"/></group> </choice> <choice><group><attribute name="foo"/><ref name="bar21"/></group> <group><doesNotExist><attribute name="foo"/></doesNotExist> <ref name="bar22"/></group> </choice> </group> and then have <group> <choice><ref name="bar11"/> <group><doesNotExist><attribute name="foo"/></doesNotExist> <ref name="bar12"/></group> </choice> <choice><ref name="bar21"/> <group><doesNotExist><attribute name="foo"/></doesNotExist> <ref name="bar22"/></group> </choice> </group> This allows only (bar11, bar21), and is thus incorrect. Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC