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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Versioning of Enums

[ Lists Home | Date Index | Thread Index ]

Thank you, this look very interesting.  MISMO has been struggling with three
identified use cases for enumeration management.

1) Lists which MISMO manages for the real estate finance community.  For
example there needs to be a standard list of values and definitions for the
kinds of amortization.  Loans are given, mortgages bought sold and
aggregated into financial instruments. Everyone needs the same industry wide
definition.

2) Lists that are managed by an external central authority.  For example the
UN list of value codes for countries, languages, currency etc.

3) Lists which are external to MISMO but have no central management either.
For example the scoring model product names of all the providers of credit
scoring service.

We have never had a good solution for cases 2 and 3.  The approach you have
documented may be a solution to those use cases.

If I understand correctly UBL is planning to use this methodology in case 1
as well.  We will look at it fo possible inclusion in our version 3.x
architecture.

Thanks again.

Greg Alvord 

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Sunday, February 12, 2006 7:37 AM
To: XML-Dev Mailing list
Subject: Re: [xml-dev] Versioning of Enums

At 2006-02-12 12:42 +0000, Fraser Goffin wrote:
>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 ?

We are abandoning that approach in the Universal Business Language 
(UBL) schema expressions.

>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.

Indeed ... it is particularly for the desire of extending, though 
also conveniently for the need for restricting the values that 
trading partners using our W3C schemas would not be successful if UBL 
enumerated our code lists as sets of values in the schema expressions.

Code lists (also called controlled vocabularies) really do have a 
life of their own.

>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 ?

It didn't in our case ... the UBL W3C schema expressions are 
sacrosanct.  We want our users to be able to accommodate their needs 
with UBL without touching the UBL schema expressions so they can 
formally agree on the structures of their documents without risk of 
inadvertently messing things up.  We are undertaking a new position 
where the schema expressions are going to be used solely for 
structural validation, and then the code list value validation (as 
agreed upon by trading partners) is a separate step.  Then we went 
the next step and formalized the expression of the members of the 
code lists using some ground-breaking work in this area by Tony 
Coates called genericode[1].

To see what we are doing, there is a draft of the UBL Code List Value 
Validation Methodology[2] posted that I'm contributing to the UBL 
committee, which uses genericode and describes a formalism with which 
two trading partners can unamibiguously express their agreement on 
which code list values to use where in their documents.  I'm working 
this week on a revision to be ready by Friday.  I gather from the 
reaction that a number of other projects are already considering 
adopting this methodology, so you may find that it will fit with your 
objectives.

But ... and this isn't palatable to everyone ... it isn't a 
schema-oriented solution ... it is a Schematron-oriented solution ... 
in effect the trading partners are asserting what code list values 
are allowed to be where in their documents.

One last note ... the UN/CEFACT W3C Schema expressions of a few key 
code lists (four in total) have indeed been brought into the UBL 2.0 
schemas under development, thus constraining trading partners to 
agree only on a restriction (if necessary) of those particular code 
lists, not an extension.  This is because the W3C Schema expressions 
cannot be extended.  Looking at the Naming and Design Rules for these 
UN/CEFACT code lists[3] you will see that in section 9.1 that they 
only provide for restricting code sets, not extending them.  For the 
*dozens* of other code lists in UBL we are providing an environment 
where trading partners can unequivocally express agreed-upon sets of 
values, and include such formal expressions in trading partner agreements.

We think this new approach solves a major issue in information 
interchange involving controlled vocabularies, code lists, 
enumerations, whatever you want to call them.  I'm finding the work 
quite interesting and satisfying.  Stay tuned.

I'm submitting my conference paper on the UBL code list value 
validation methodology at both XTech 2006 and XML 2006 and I hope 
that it is accepted in order to bring out some discussion of these 
points in public fora.

I hope this helps.

. . . . . . . . . . . . Ken

[1] - http://www.genericode.org
[2] - http://www.oasis-open.org/archives/ubl-dev/200512/msg00034.html
[3] - http://lists.oasis-open.org/archives/ubl/200601/msg00090.html


--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


-----------------------------------------------------------------
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





 

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

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