> 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.
So this is an implementation issue, in large part?
> 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.
If foo is present, the interpretation I suggest is that next must come
(bar11, bar21). I am not suggesting (bar12,21) | (bar12, bar22).
> 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).
(Aside: I think it is better to write foo="..." rather than
foo="", b.t.w.)
Why isnt the appropriate derivative the following? (eliding
the choice) Isn't this what would happen if foo was an element?
<group>
<ref name="bar11"/>
<ref name="bar21"/>
</group>
...
> This allows only (bar11, bar21), and is thus incorrect.
But (bar11, bar21) is the thing I am suggesting is correct.
Sorry being thick, but I don't understand this answer at all.
Cheers
Rick
