Re: [ubl-ndrsc] Code lists: discussion kickoff

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

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.          |