W3C home > Mailing lists > Public > xmlschema-dev@w3.org > December 2002

Enumerated List management

From: Danny Vint <dvint@mindspring.com>
Date: Fri, 27 Dec 2002 12:22:49 -0800
Message-Id: <>
To: xmlschema-dev@w3.org
Cc: dvint@dvint.com

I have a question about enumerated lists and part of the hangup/issue is 
that my organization has implemented them in 2 different ways; one uses 
them as attribute content and the other uses them as element content. The 
difficult occurs when we want to allow the EXTENSION and RESTRICTION of our 
code lists. To get around the EXTENSION issue I think we have to define 
some extra types, something like this (note this isn't proper schema markup 
but I think you can follow it):

I belive the only way to may extension as well as restriction to work is 
you will have to have something like this:

<!-- ACORD Schema -->

<simpleType name="GenderCodes" type="xsd:string">

<simpletype name="Genders" type="GenderCodes">
<enum value="male"/>
<enum value="female"/>

<!-- End ACORD Schema -->

Now if you want to extend the list you have a "base" common type to go back 
to which means they are compatible types, but you are defining your own 
values (all restrictions off the wider "string" type, rather than the ACORD 
specific list).

So Acme Company would do something like this for extension (Genders would 
now be part of the ACME namespace when used):

<simpletype name="Genders" type="ACORD:GenderCodes">
<enum value="male"/>
<enum value="female"/>
<enum value='other'/>

or this for restriction:

<simpletype name="Genders" type="ACORD:GenderCodes">
<enum value="male"/>

or this for both:

<simpletype name="Genders" type="ACORD:GenderCodes">
<enum value="male"/>
<enum value='other'/>

Note that restriction would really have two ways to be defined (with either 
of the two types in the ACORD schema) but I think we would want to specify 
that you use the method that allows both to occur so you don't shoot 
yourself in the foot later when you need to extend it as well.

To use this I think you then need to use the xsi:type attribute to define 
which list you are actually using (xsi:type="ACME:Genders". Now this simple 
method I hate to say doesn't work (I believe) for attributes because of the 
need for the xsi:type attribute - I believe this can only be applied to 
element content and not attributes. Is this true?

Does anyone have an alternate solution that works and provides validation 
of the values as well as allowing extension and restriction and hopefully 
works nicely with code generators so they would produce the same or a 
related class object.

Danny Vint

Received on Friday, 27 December 2002 15:20:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:59 UTC