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

[John C Dumay <jcd@progressivemanagement.com.au>]

Title: Message

Folks,

 

I also agree with the view on eliminating large code lists of enumerated values fro the UBL specification. We should really be specifying the source of the codelists aka some ISO standard, and allowing this to be the basis of the values used in the element. Having a standard list of codes within UBL is in my view helping UBL not becoming a useful standard.

 

An earlier comment by Phil Griffin pointed out:

 

"Seems to me, as an example, if I only ship to the US and Canada, that for my document only USA and CAN might be valid out of the list of all country codes. What benefit would I get from JAP and FRA being valid?"

 

So why not let us specify only CAN and USA (and maybe AUS) in our application, provided it meets the context in which it would be used. It should not be difficult for an application to also validate these choices at run time. For example we could have a middleware application receiving and processing a SOAP message that checks to see if CAN, USA or AUS is used in a <Country/> element. If the application MustUnderstand the three choices, then let the application do so. If it doesn't work, it sends the message back to the originating application. Also we need extensibility for legacy data as well. The recent introduction of the Euro is a good example. When the old currencies are no longer part of the ISO standard - what do we do with the legacy data we need to exchange?

 

Also if we stick to strict enumerated list we would be placing to rigid a control on what UBL documents could contain. I had a look through the party.xsd sample that was sent by Arofan. While on the surface everything appeared to be in order, I could not begin to comprehend the need, for example,  for the list of AgencyCode's that were available. I'm sure this list satisfies the historical use for the EDIFACT 3055 (Code list responsible agency code) and X12 559 (Agency Qualifier Code) uses from which it was derived, but what utility would it be to a SME in outback Australia or deepest darkest Africa. Most notably these SME's would need to have some way of specifying their own Agency's. Sure it is fine for maintaining the link to the EDI ways, but aren't we supposed to be developing a language that will have "utility" for all of us and not the top 1000 companies that could afford to implement EDI.

 

I hope this adds a bit of fuel to the debate without causing any offence.

 

Regards,

 

John Dumay

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
Sent: Monday, 4 February 2002 1:38 AM
To: 'Gregory, Arofan'; Maler, Eve; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

I think there's one more (a variation of your 2): use strings, but document the allowed types in appInfo or some other schema annotation. It's not entirely clear to me how interoperability is served by having an enumeration and an opt-out (a la xCBL) or a union of enum and string. People can still specify whatever garbage they want. I find the huge enumerations of xCBL to be somewhat unwieldly, leading me to believe that they probably don't belong directly in the schema. Also, in the future these codelists might be provided by a more dynamic source (e.g. a web service), so using an enumeration is somewhat restrictive.

 

The big drawback of this approach is that parser validation of the codelist values is not possible. I'm not sure to what extent this is useful...

 

Matt

 

-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Thursday, January 31, 2002 7:52 PM
To: Maler, Eve; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

 

Folks:

I missed one:

(4) Codelists as Union Type: we could create a "union type" that allows any one of a set of choices (an enumeration), or a string. And - assuming someone writes a parser that supports the post-validation info set - you are supposed to be able to detect the difference afterwards, assuming that you have access to the schemas when you parse. This is the cleaner equivalent of the "codelist other" approach used in xCBL.

-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Thursday, January 31, 2002 10:47 AM
To: Maler, Eve; ubl-ndrsc@lists.oasis-open.org
Subject: RE: [ubl-ndrsc] Code lists: discussion kickoff

 

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