ubl-ndrsc message

Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

From: "Gregory, Arofan" <arofan.gregory@commerceone.com>
To: 'Eduardo Gutentag' <eduardo.gutentag@sun.com>,"Gregory, Arofan" <arofan.gregory@commerceone.com>
Date: Thu, 31 Jan 2002 12:04:39 -0800

Title: RE: [ubl-ndrsc] Code lists: discussion kickoff

Certainly:

I have an "Identifier" type, which has two fields: a string, which is the value of the identifier, and a code, which tells me which standard ID scheme is used - that is, which Agency defines the identifier value's meaning. For example, I have a DUNS (Dun & Bradstreet) number, a common scheme for identifying company organizations. (The sample is a tiny subset of the list from xCBL).

So, the field AgencyIDCode has a value of AgencyCode, which allows us to maintain a list of valid values in the schema.

For complete examples, look at the PartySample.xsd I sent out before the F2F - this has about 4 or 5 codelists in it, all handled exactly this way.

Cheers,

Arofan

-----Original Message-----
From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
Sent: Thursday, January 31, 2002 11:17 AM
To: Gregory, Arofan
Cc: Maler, Eve; ubl-ndrsc@lists.oasis-open.org
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.          |