Simplification of equivClass functionality

There are currently two distinct mechanisms to achieve "substitutability" of
elements in XML Schema that achieve the same goal.  For example, the
interchangability of "facets" in schema datatypes could be accomplished by
either:

1. Use of a choice group

<group name="facet" order="choice">
	<element ref="precision"/>
	<element ref="scale"/>
	...
</group>

  <type name="datatype" source="annotated" derivedBy="extension"
        abstract="true">
    <group ref="facet" minOccurs="0" maxOccurs="*"/>
    <attribute name="name" type="NCName" minOccurs="0">
...
</type>

2. Use of an abstract element and equivClass attributes 

 <element name="facet" type="facet" abstract="true"/>

  <element name="precision" type="numFacet" equivClass="facet"/>
  <element name="scale" type="numFacet" equivClass="facet"/>

 <type name="datatype" source="annotated" derivedBy="extension"
        abstract="true">
    <element ref="facet" minOccurs="0" maxOccurs="*"/>
    <attribute name="name" type="NCName" minOccurs="0">
   ...
</type>

The equivClass formulation provides an alternative way to basically declare
group membership in the definition of the member not in the definition of
the group.  However, it does so by adding a decent amount of conceptual
complexity that could be eliminating by unifying "equivClass" behavior with
"choice group" behavior.

What I would propose is to rename the "equivClass" attribute to be "groups"
that would be a blank separated list of groups into which the element should
be inserted.  Since equivClass is roughly approximate to the interface
concept in Java (structurally distinct items performing the same conceptual
service), it would be useful to say that a element participates in more than
one "equivClass/group" in the same way one class can have many interfaces.
When resolving a schema, all elements with "groups" would have their element
added to the corresponding group.  Since it may not be possible to define an
appropriate order of insertion, it would be good to require that the target
group be either "choice" or "all". 

This would also eliminate the need to the "abstract" and "exact" attributes
on elements, since an "abstract" element serves no purpose except as the
target of an equivClass and "exact" would not be needed since you could use
an explicit element ref to get only the "facet" element (if there had been
one) and reference the group to get all the equivClass members.

With these changes, the second form would look like:

 <!--   some elements could have be explicitly added into the group   -->
 <group name="facet" order="choice"/>

  <element name="precision" type="numFacet" groups="facet"/>
  <element name="scale" type="numFacet" groups="facet"/>

 <type name="datatype" source="annotated" derivedBy="extension"
        abstract="true">
    <group ref="facet" minOccurs="0" maxOccurs="*"/>
    <attribute name="name" type="NCName" minOccurs="0">
   ...
</type>

I believe this accomplishes the same objectives as the equivClass without
introducing as many complicated topics as the current "equivClass" approach.

Received on Monday, 10 January 2000 12:26:17 UTC