[
Lists Home |
Date Index |
Thread Index
]
Greg,
thanks for your perspective, as always it is thought provoking.
As you observe one of the principle use case for local extension to code
lists occurs when the standards body cannot keep pace with the business need
(and sometimes they don't agree with adding some items). Additions are not
semantically different from their peer group, the current set is simply not
adequate. I also think there is a valid case for extensibility in schema
types specifically to enable private relationships to be represented within
a standard message. Of course such extensions (by a non schema owner) should
be clearly identified in their own namespace (not sure if this is possible
for enums though ?).
We also have issues with maintaining fidelity when mapping standard code
list values to internal applications. Clearly it is not always possible for
internal applications to implement the data model described by the market
schema, and this sometimes gives rise to pressure to add to the lists (for
internal use).
Using subsets is a little less prevalent and is often to do with UI
processing, so is not really a relevant use case.
Some suggest that we should just remove embedded enums from schema and that
will solve the problem. But of course that makes the assumption that all
users of that schema are able to obtain the set of valid values by some
other 'out of band' mechanism and they are able to relate these lists to the
correct item in the schema. Otherwise they have a semantically and
syntactically incomplete description. For web services where we want to
assume as little as possbile about the capabilities of calling clients, this
is a problematic position.
Typically our standards body (Insurance sector) likes to 'timebox'
activities around changes to schema and this can be a few as twice yearly !
Sometimes we may be in the position of having to wait more than 6 months to
get changes made. The schema also include no extensibility therefore it is
not possible for communicating parties to transfer locally agreed additional
data to represent a private relationship without being schema invalid as far
as the standard is concerned. Part of the reasoning given for not allowing
extensibility is that they are concerned that the standard will be
deminished by parties over-use of extensibility rather than supporting
changes to the base standard. Frankly I think this argument is flawed, in
the sense that if I don't want to use the standard there is nothing stopping
me not doing so, so why would I go to the bother of wholesale use of
extensions. And of course, if standards ever get in the way of business
operations then I know which of these will be surrendered !
Yeh xs:redefines along with xs:restriction and xs:union all seem to provide
capability within XML schema for manipulating simple type definitions, so
I'm I'm happy that technically I *can* do it, it just a matter of what
circumstances is it going to be genuinely useful and not strore up a problem
for later !
Ken's suggestion looks interesting.
Fraser.
>From: "Greg Alvord" <greg.alvord@comcast.net>
>To: "'Fraser Goffin'" <goffinf@hotmail.com>,<xml-dev@lists.xml.org>
>Subject: RE: [xml-dev] Versioning of Enums
>Date: Sun, 12 Feb 2006 10:31:13 -0600
>
>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 >>
|
