[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Versioning of Enums


tony coates genericode
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@C...>
>To: XML-Dev Mailing list <xml-dev@l...>
>Subject: Re:  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@C...
>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>
>



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.