OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Enums as Choices (Was: [xml-dev] Versioning of Enums)

[ Lists Home | Date Index | Thread Index ]

As this is not specific to the details of the original versioning enums 
thread, I thought I'd start a new one...

When I worked with a standards group that used ASN.1, we used to define 
enumerations using a choice with a number of NULLs even though the language 
formally supported enumerations.  I'm not quite sure why, but at one level 
this approach may offer possibilities to the versioning enums in XSD.

For example, you could define an enumeration as:

    <xs:complexType name="MyVersionableEnum">
        <xs:choice>
            <!-- The initial enumerations -->
            <xs:element name="option1" type="MyEmptyType"/>
            <xs:element name="option2" type="MyEmptyType"/>
            <xs:element name="option3" type="MyEmptyType"/>

            <!-- Indicates that 'standards' based versioning is allowed -->
            <xs:element name="extension" type="MyChoiceExtensionType"/>

            <!-- Indicates that third-party extensions are allowed -->
            <xs:any namespace="##other"/>
        </xs:choice>
    </xs:complexType>

    <!-- I'm not sure if this is the right form, but hopefully you know what
         I'm aiming at! -->
    <xs:complexType name="MyChoiceExtensionType">
        <xs:sequence>
            <xs:any namespace="##targetNamespace"/>
        </xs:sequence>
    </xs:complexType>

So the benefits of this scheme is that you can include or excludes the 
various versioning/extension mechanisms and so it gives a great deal of 
expressiveness about what is allowed to be versioned/extended or not.

The downside is that it's only an enumeration (rather than a choice) because 
someone decided it is, and so doesn't seem aesthetically right.

So it has a big pro and a big con.  Hence I'd be interested in what other 
peoples' opinions on this list are about this sort of thing.

Cheers,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Fraser Goffin" <goffinf@hotmail.com>
To: <xml-dev@lists.xml.org>
Sent: Sunday, February 12, 2006 12:42 PM
Subject: [xml-dev] Versioning of Enums


> It appears to be a common practice when, if you have a schema which 
> includes a volatile code-list (enumeration), to externalise it into its 
> own [chameleon] schema and then include that schema into the main 
> [transaction] schema. I just wanted to see whether others have experience 
> of using this approach and if any issues arise from it ?
>
> In our case the enumerated values of of type xs:string (not sure if this 
> matters but it might)
>
> We also get our schema from a standards body who define the standard 
> market values. Naturally :-) my business colleagues are not always 
> satisfied with that and want to both extend and restrict the values used. 
> So in this case I am thinking of :-
>
> a. creating another schema to contain OUR custom enum values
> b. creating another schema that imports my custom codes and the market 
> standard and :-
>    - contains a type which is a restriction of the market standard enum
>    - contains a type which is a union of the restricted market standard 
> and custom enum.
>
> Does this seems reasonable ? here's a rough example using the oft 
> described 'currency code' example :-
>
> Market Standard Schema (BaseCodes.xsd)
> ===============
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
> elementFormDefault="qualified" version="1.0">
> <xs:simpleType name="iso3currency">
> <xs:annotation>
> <xs:documentation>ISO-4217 3-letter currency codes. Only a subset are 
> defined here.</xs:documentation>
> </xs:annotation>
> <xs:restriction base="xs:string">
> <xs:length value="3"/>
> <xs:enumeration value="AUD"/>
> <xs:enumeration value="BRL"/>
> <xs:enumeration value="CAD"/>
> <xs:enumeration value="CNY"/>
> <xs:enumeration value="EUR"/>
> <xs:enumeration value="GBP"/>
> <xs:enumeration value="INR"/>
> <xs:enumeration value="JPY"/>
> <xs:enumeration value="RUR"/>
> <xs:enumeration value="USD"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:schema>
>
> My Custom Schema (MYCurrencyCodes.xsd)
> ============
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
> xmlns="http://www.someorg.com/ws/2006/02/codelists"; 
> targetNamespace="http://www.someorg.com/ws/2006/02/codelists"; 
> elementFormDefault="qualified" attributeFormDefault="unqualified">
> <xs:simpleType name="iso3currency">
> <xs:restriction base="xs:string">
> <xs:length value="3"/>
> <xs:enumeration value="abc"/>
> <xs:enumeration value="def"/>
> <xs:enumeration value="ghi"/>
> <xs:enumeration value="jkl"/>
> <xs:enumeration value="mno"/>
> <xs:enumeration value="pqr"/>
> <xs:enumeration value="stu"/>
> <xs:enumeration value="vwx"/>
> <xs:enumeration value="yza"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:schema>
>
> The schema to INCLUDE in the main transaction (CombinedCurrencyCodes.xsd)
> =============================
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
> xmlns:my="http://www.someorg.com/ws/2006/02/codelists"; 
> elementFormDefault="qualified" attributeFormDefault="unqualified">
> <xs:include schemaLocation="BaseCodes.xsd"/>
> <xs:import namespace="http://www.someorg.com/ws/2006/02/codelists"; 
> schemaLocation="MYCurrencyCodes.xsd"/>
> <xs:simpleType name="iso3currencyRestricted">
> <xs:restriction base="iso3currency">
> <xs:enumeration value="CNY"/>
> <xs:enumeration value="EUR"/>
> <xs:enumeration value="GBP"/>
> </xs:restriction>
> </xs:simpleType>
> <xs:simpleType name="MYiso3currency">
> <xs:union memberTypes="iso3currencyRestricted my:iso3currency"/>
> </xs:simpleType>
> </xs:schema>
>
> The main schema
> ===========
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; 
> xmlns="urn:www.polaris-uk.co.uk/codelist/example" 
> targetNamespace="urn:www.polaris-uk.co.uk/codelist/example" 
> elementFormDefault="qualified">
> <xs:include schemaLocation="CombinedCurrencyCodes.xsd"/>
> <xs:element name="accountSummary">
> <xs:complexType>
> <xs:sequence>
> <xs:element ref="timestamp"/>
> <xs:element ref="currency"/>
> <xs:element ref="balance"/>
> <xs:element ref="interest"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> <xs:element name="timestamp" type="xs:dateTime"/>
> <xs:element name="currency" type="MYiso3currency"/>
> <xs:element name="balance" type="xs:decimal"/>
> <xs:element name="interest">
> <xs:complexType>
> <xs:simpleContent>
> <xs:extension base="xs:decimal">
> <xs:attribute name="rounding" type="roundingDirection" use="required"/>
> </xs:extension>
> </xs:simpleContent>
> </xs:complexType>
> </xs:element>
> <xs:simpleType name="roundingDirection">
> <xs:annotation>
> <xs:documentation>Whether the interest is rounded up, down, or to the 
> nearest round value.</xs:documentation>
> </xs:annotation>
> <xs:restriction base="xs:string">
> <xs:enumeration value="up"/>
> <xs:enumeration value="down"/>
> <xs:enumeration value="nearest"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:schema>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
> 






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS