xml-dev - EquivClass & Derived Type

[Michael Anderson <michael@research.canon.com.au>]

Hi,
Thanks for all the replies to my previous questions on equivClass.  I
now have a new problem based on my new understanding.  At the moment
there exists equivClass and derived type, but I do not see why both are
necessary as derived type could do the same job.

In a previous message (on this topic about 2 weeks ago), I used the
following example:

<element name="A" type="Atype"/>

<element name="B" type="Btype"/>
<type name="Btype" source="Atype" derivedBy="extension">
    <element name="notimportant"/>
</type>

<element name="C" >
   <type>
       <element ref="A"/>
   </type>
</element>

I expected that it was okay to declare in the document instance:
<C>
  <B> B stuff in here </B>
</C>
I will call this instance 1 thereafter.  I thought that this was what
most people would expect from other OO systems.  Also, if I remember
correctly, this was also supported by archetype in the previous XML
Schema WDs.

Subsequent responses to me pointed out that I should have written
<C>
  <A xsi:type="Btype"> B stuff in here </A>
</C>
I would call this instance instance 2.

I take that this means instance 1 is not valid.  It is not clear to me
why it is not supported.  There may be good reasons, but the reasons are
not apparent in the WD.  There is mention of ambiguity issues, but these
will not occur if instance 1 is allowed as the B stuff is tagged as B
and not as A (as in instance 2).

It does not seem to me that there is any difficulty in supporting
instance 1 technically.  Indeed, by simply changing the definition of
element B to:
        <element name="B" type="BType" equivClass="A" />
The instance becomes valid.

By separating equivalence from inheritance, are we saying that even
elements of the same type or subtypes of the same type are not
necessarily substitutable by one another in every context.  For
instance, even if elements "name" and "account number" are both of type
string, they could not be used in place of one another in most context.
Is this the main reason behind the separation of inheritance and
equivalence?

Michael.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************