[
Lists Home |
Date Index |
Thread Index
]
Thanks Ken. I will certainly give this material a thorough read. Tony Coates
was I believe one of the original proponents of the method I was suggesting
below, so evolution of this thinking sounds promising (plus you know I am a
big fan of schematron already :-).
I am certainly interested in your final revision and who knows I may come
along to one of the conferences you mention to hear it first hand.
I will send you any feedback that comes to mind after a read and possibly a
bit of experimentation with my own specific use cases.
Cheers
Fraser.
>From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
>To: XML-Dev Mailing list <xml-dev@lists.xml.org>
>Subject: Re: [xml-dev] Versioning of Enums
>Date: Sun, 12 Feb 2006 08:36:45 -0500
>
>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>
>
|
