RE: Unification of Classification Systems WAS: Comments on ebXML Cor e Components forms

[Arofan Gregory <arofan.gregory@commerceone.com>]

Folks:

>From the perspective of core components, this issue has come up before, and
generally speaking, our intention has been to embrace the use of whatever
common standard classifications exist today *that meet our needs*. In the
case of some things - language codes, country codes, etc. - we have
business-tested classifications that can do the job. In the case of many
other areas, no such classification exists, or existing classifications are
insufficient (e.g., product classifications). Part of "building on the good
parts of EDI" is embracing useful work done in this area.

I do believe that we should generally assume that ebXML is not there to
provide unified classifications, but to recommend which ones should be
supported, and provide referencing mechanisms to allow this to be
implemented by different communities according to their needs. In some
cases, we will have to do a little original work to come up with even a
single useful classification (as in parts of the core components concept of
context classification).

I do agree that we must be flexible here, because of the effort involved in
creating a useful classification in most cases (statistics classifications
can take many years to create!), and for issues around legacy support that
Brian mentions below. We have enough work without taking this on as well,
and I think it is not something we should focus on. Diferent communities
have different legacy requirements, so flexibility allows implementors to
move at their own pace.

Cheers,

Arofan Gregory

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Thursday, June 01, 2000 12:01 PM
To: Brian Hayes
Cc: ebxml-core@lists.oasis-open.org; ebXML Coordination
Subject: re: Unification of Classification Systems WAS: Comments on
ebXML Cor e Components forms


Message text written by Brian Hayes
>
Requiring the use of standardized code lists is great for new
services/applications; they are problematic for legacy applications. 

Allowing code lists/agencies to be specified with the code has the
advantage
of not requiring that application level services that generate documents be
forced to use (or map to) the "standard" code list.  Unfortunately, it does
burden the service that receives and processes documents with the need to
understanding multiple code lists. Of course, trading partners can agree to
only use certain code lists.
<<<<<<<<<<<<<<<

Brian,

Yes - new implementors will have to do both - implement new codes, 
and map to legacy.  Simple conversion lists look possible, but are by
no means problem free.

However - this whole area of service/product classification is one 
that's been left to politicians before (never a good idea!) i.e. US NAICS
codes.

Really the internet is driving the need here, so alot of this is new data.

I really do not see any good answer here - expect to grasp the thorn - 
becuase short term fixes leave long term bigger problems.

DW.