[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Versioning of Enums
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|