[
Lists Home |
Date Index |
Thread Index
]
In MISMO we have had a lot of discussions about enumerated values. We have
come to the conclusion that semantically the definition of an enumerated
field is its enumerations. Therefore changing the enumerations changes the
definition.
If someone wants to limit the list of values used in a particular use case
that is something that the business logic can detect. If the list can be
portioned into two disjoint sets for two different use cases then
semantically there are two different definitions and one should consider
making that clear in the standard.
Adding enumerations locally seems like a poor practice. If the local
definition is semantically different from that of the standard you should
not have it masquerading as if it was the same. It should be made obvious
that to exchange data with others in the standard way you cannot just send
the local data.
MISMO allows transport of off list values by including "Other" in all
enumerations and providing a field "TypeOtherDescription" for each
enumerated data field. This can be subject to a lot of abuse. We try to
keep a lid on it by encouraging people to only use it where the pace of
business change is faster that the pace of standards making.
For example, a credit provider might want to implement a new scoring model.
MISMO defines when the enumeration will look like in a future release and
the model name can be carried in the (Other, TypeOtherDescription) structure
for all previous versions.
Certainly two trading partners could agree to use "other" or to have
expanded enumerations, but then they can no longer say that its compliant
with the standard.
We have looked at a variety of methods of inheritance available in W3C XSD,
however the tools support is so spotty that we have been uncomfortable in
using it in the standard.
Members of our group have worked out using xs:redefines to allow the
standard definition enumerations to be added to or filtered for local use.
within a know set of tools it seems to work. This method documents the
difference in business semantics between the local and standard definitions.
Greg
-----Original Message-----
From: Fraser Goffin [mailto:goffinf@hotmail.com]
Sent: Sunday, February 12, 2006 6:43 AM
To: xml-dev@lists.xml.org
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>
smime.p7s
|
