[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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@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
|
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
|