equivClass: common ancestor type

Section 2.2.2.2

All such members must have type definitions which are either the same as the
exemplar's type definition or restrictions or extensions of it. Therefore,
although the names of elements can vary widely as new namespaces and members
of the equivalence class are defined, the content of member elements is
strictly limited according to the type definition of the equivalence class
exemplar

--------

This implies that the justification for the constraint is somehow related to
simplication of validation becuase content is strictly limited....

However, this "limitation" is circumventable by creating an abstract
examplar with a minimal type such as empty.

<complexType name="empty"/>

<element name="resourceDefRef" abstract="true" type="empty"/>


<element name="resource" equivClass ="resourceDefRef">
    <complexType base="empty" content="mixed">
            <any maxOccurs="unbounded" minOccurs="0"/>
    </complexType>
</element>

<elementType name="resourceRef" equivClasss="resourceDefRef">
    <complexType base="empty">
        <attribute name="href" type="uriReference"/>
    </complexType>
</elementType>

By which we have created an equivClass with two members that are about as
structurally dissimilar as possible.  I think it is a good thing to be able
to do that since it should be common, as in this example, that logically
equivalent things have radically different XML representation.

But then why go through the hoops of manufacturing a common ancestor type?
I have a guess that it is so that final='restriction' or final='extension'
makes sense, but that I think that is putting the cart before the horse.

Like the concept of interfaces in OOP, equivClasses reason for being is to
allow structurally dissimilar but conceptually similar items to be
substitutable.  Interfaces do not make any demands on the structure of the
implementing class and one class may support many interfaces.

I would strongly recommend that:

a) the restriction on equivClass members having a common ancestor type be
removed.
b) that the final attribute of <element> be a boolean.  A value of true
would inhibit the use of the element as an exemplar.
c) that the equivClass attribute of <element> become a list of QNames.

I believe this would simplify schema authoring by eliminating the
manufacturing of common ancestor classes, would simplify schema validation
by eliminating the need to ensure common ancestor classes and would be
consistent with the use of interfaces in OOP.

Received on Friday, 5 May 2000 05:35:14 UTC