[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] Code lists: discussion kickoff
I don't understand (3) below. Could you provide a simplified example? "Gregory, Arofan" wrote: > > Folks: > > I've thought a lot about this issue, and I believe the trade-off is this: > > (1) Using elements to represent codes is one possibility, that gives us the > advantage of being able to validate a code from a controlled list. Also, if > we wrap these in a parent type, the list can be extended. (Ugly, but it > works.) For companies that have expensive validation software to handle > code-lists, this isn't a problem, but it is a problem for the little guys. > We can get free code-list standardization and validation from this approach, > which I think is good. The down-side is that designing and maintaining these > code-lists is a bitch. (Many, many versions of our schemas that do nothing > but update code-lists). Perhaps we could have special namespaces for > codelists, and have special rules so that versioning is not done by > namespace but with an attribute? Just a thought. > > (2) Using the "string" approach will absolutely defeat any hope of > interoperability without benefit of expensive translation software. The EDI > experience has shown that people will happily invent their own > non-interoperable codes. In xCBL we allowed for this with the "CodedOther" > approach: all code lists have an enumeration of choices, and then a sister > element that holds a non-standard code. If you choose the "Other" code, then > you have to fill in the string. This approach is not, in my opinion, the > best solution, but it may be the best we can do with XML Schema. Using just > a string makes it not necessary to maintain codelists at all, but sacrifices > much of the benefit of having a UBL, in my opinion. > > (3) Codelists as enumerated data types. This is my preferred approach - a > codelist is, in fact, an enumeration of specific semantics, and this format > makes it clear and easier to manage. What we need is an ability to extend > these (a major failing of XML schema). > > Let me suggest: > > (1) Dedicated namespaces for codelists (one per codelist, or related group > of codelists) > (2) Alow these namespaces to be static - that is, not versioned. > (3) Have a "version" associated with the codelist in a way that does not > change the name of the namespace. (Could we use XSD "version" for this?) > > This way, we could version our structures and our codelists separately. > This models the best part of EDI, where it is common practice to update > codelists versions within an older version of message structures. And all > this, while not throwing away the ability to validate codelists with a > parser. > > The down-side, of course, is that codelists are in a special class in terms > of how they are versioned and use namespaces, but I don't think it will be > that confusing - if they weren't special, we wouldn't be having this > discussion. And this approach is, after all, very much a part of the > existing EDI standards culture. > > Cheers, > > Arofan > > -----Original Message----- > From: Eve L. Maler [mailto:eve.maler@sun.com] > Sent: Thursday, January 31, 2002 10:26 AM > To: ubl-ndrsc@lists.oasis-open.org > Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff > > At 11:46 AM 1/31/02 -0500, CRAWFORD, Mark wrote: > > > Finally, regarding the "enumerations of the xsd:string type" vs. "one > > > element per code list value" choice itself, I'm not sure I > > > buy the argument > > > that the latter is better. It could potentially swell the > > > number of UBL > > > elements by orders of magnitude, and the infrastructure > > > needed to document > > > and manage elements would seem to outweigh the benefits for > > > these little > > > values. > > > >Not sure I understand. Could you expand pls. > > My (probably flawed) understanding of the main issue covered in Mike's > position paper was that he was advocating <vanilla/>, <chocolate/>, > <strawberry/> elements rather than <IceCream flavorCode="vanilla">... If > there are really thousands of values in some code lists, I quail at the > thought of having to maintain definitions and documentation for all those > elements. > > Eve > > -- > Eve Maler +1 781 442 3190 > Sun Microsystems XML Technology Center eve.maler @ sun.com > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM XML Technology Center | Phone: (510) 986-3651 x73651 Sun Microsystems Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC