"Expanding" an enumeration

 I am trying to find a mechanism whereby I can achieve the effect of
extending an enumeration. I know that, by definition, enumerations are
restrictions on a simple type. But that doesn't stop my schema users from
needing to expand a defined base set of enumerations and have the full,
extended set be correctly validated. So I'm hunting for something that has
an equivalent effect. 
 
Making matters more complex, my users also want a simple mechanism whereby
the enumeration can be extended, without requiring a complex solution that
involves full type specialization. That is, they would like to have an
element Partner of type PartnerType (an enumerated restriction of
xs:string), and they would like to add additional values to PartnerType
without having to create, e.g., either a new "myPartner" element and/or a
new "myPartnerType" element, or a similar use of namespaces (ex:Partner
and/or ex:PartnerType) to distinguish different types. I understand that one
of these approaches would be a more conceptually pure application of types,
but that doesn't eliminate the practical need.
 
In the process of experimenting, I found something that XML Spy supports
(incorrectly, I believe), but which is not supported by to Xerces or XSV and
looks to be illegal according to the Schema Rec. It would solve my problem
if it were legal.
 
The mechanism that I came up with  uses the union type (
http://www.w3.org/TR/xmlschema-0/#UnionDt
<http://www.w3.org/TR/xmlschema-0/#UnionDt> ) to combine a base set of
enumerations with an additional set (or sets). It uses redefine to achieve
an equivalent of extension.
 
I define a BasePartnerType that contains the enumerations in the current
PartnerType:

<xs:simpleType name="BasePartnerType">

    <xs:restriction base="xs:string">

        <xs:enumeration value="ShipTo"/>

        <xs:enumeration value="BillTo"/>

        <xs:enumeration value="Publisher"/>

        <xs:enumeration value="Manufacturer"/>

        <xs:enumeration value="ShipFrom"/>
    </xs:restriction>

</xs:simpleType>

I then reestablish PartnerType as a union type with only one class
mentioned, "BasePartnerType":

<xs:simpleType name="PartnerType">

    <xs:union memberTypes="BasePartnerType"/>

</xs:simpleType>

I then define an additional enumerations in another type, PartnerTypePlus: 

<xs:simpleType name="PartnerTypePlus">

    <xs:restriction base="xs:string">

        <xs:enumeration value="Mistress"/>

        <xs:enumeration value="Frontman"/>

        <xs:enumeration value="Shill"/>

    </xs:restriction>
</xs:simpleType>

And I add that type to the union in PartnerType:

<xs:simpleType name="PartnerType">

    <xs:union memberTypes="BasePartnerType PartnerTypePlus"/>

</xs:simpleType>
 

Anything that references PartnerType can use any enum from either of the
unioned types. That's all as it should be.
 
But because I need to leave the original type definition untouched in its
original file, I use "redefine" in another file to redefine and extend the
PartnerType (I also factor out the PartnerTypePlus, which can't, by decree,
appear in the original file):

<xs:redefine schemaLocation="TestUnion.xsd">
    <xs:simpleType name="PartnerType" final="union">
        <xs:union memberTypes="BasePartnerType PartnerTypePlus"/>
    </xs:simpleType>
</xs:redefine>
<xs:simpleType name="PartnerTypePlus">
    <xs:restriction base="xs:string">
        <xs:enumeration value="Mistress"/>
        <xs:enumeration value="Frontman"/>
        <xs:enumeration value="Shill"/>
    </xs:restriction>
</xs:simpleType>

I've attached examples of this.
 
XML Spy does just what I'd want it to: it allows the redefine without
validation errors, and accepts in the instance document only one value from
the union of the two types. (Interestingly, Spy doesn't show the unioned
values anywhere, including in the entry helper for the instance document -
only the initial base set. Still, you can key-in one of the "PartnerType" or
"PartnerTypePlus" values and all is well).  
 
Both Xerces and XSV give very specific messages that this practice illegal:

Xerces 2.0.0b3:
[Error] TestUnion.xml:3:136: src-redefine.5: <simpleType> or <complexType>
children of <redefine> elements must have <extension> or <restriction>
descendants referring to themselves.
 
XSV 1.3:
file:TestUnionExt.xsd:5:3: Invalid: attempt to redefine in terms of type
other than self: PartnerType vs. string

 
I don't fully understand the rationale for disallowing this, but I'm
guessing it somehow violates a separation of extension and restriction. If
it's disallowed because of a lack of a reference implementation, Altova now
has one (if only accidentally :-).
 
If it turns out to be illegal (it certainly looks that way), are there any
other mechanisms that are commonly used for this purpose? Should I be
looking at the problem differently? Is there anything on the horizon that
will support this?
 
 
Thanks,
 
Mark
 
Mark Feblowitz 
XML Architect 
Frictionless Commerce Incorporated 
400 Technology Square, 9th floor 
Cambridge, MA 02139 
(617) 715-7231 
mfeblowitz@frictionless.com