David
As ever you mix apples with oranges and confuse people. I will concentrate on the
generalized statements at the end of your message.
>The whole issue here that is not being addressed is code tables
generally. Plenty of focus on Schema - but now we moving closer
to a use model right there, we need to solve this bottom layer
question definitively - particularly so industry groups evolving
XML based exchanges have a reference point of contact.
The ebXML core components group has been working on this issue for the last month or
so. There are three key issues:
- How should the codes be represented in an ebXML message
- How should the meaning of each code be made accesssible to applications and their
users
- How can code sets be subsetted so that particular applications only need to use the
minimum subset that is applicable to their domain and business process.
These three issues are intimately connected and must not be treated in isolation.
>Maybe we need an ebXML WG on code tables? Liaison to
OAG and ISO would make sense - or maybe a joint effort
between sich bodies? Its not really a question of
re-inventing anything - there are plenty of ISO and other
standards out there - but we do need a central point - and also
XML'ized versions of these reference tables. ebXML will provide
the API - but how is the secretariat?
There is no "one secretariat"! Lets be realistic here for a change. Different code
sets need to have different "owners". Some code sets clearly need internationalization
within the ebXML initiative (e.g. code sets identifying code set defining agencies!):
some are clearly already fully internationalized and the existing registration bodies
should not be changed (e.g. 3166 country codes, 4137 currency codes, 31 SI measurement
units, etc) when someone creates an XML representation of the code set; some are
clearly national in scope, and need to be handled by national standardization bodies
(e.g. postcodes); others are the responsibility of well respected organizations and
businesses (e.g. EAN and Dun & Bradsheet) and will need to be made available by them
in an XML-compatible format, while yet others are company specific and should clearly
remain the responsibility of one of the partners of a transaction.
Now which set of code sets are you thinking in terms of? You started talking
specifically about UNSPC and then went on to generalize this. If what you are talking
about is simply the classification of Standard Products and Services into Segment,
Family, Class, and Commodity then clearly this remains the domain of the UN. However,
if we are talking about the use of a classification scheme such as this as the basis
for identifying the business segments that ebXML will use to differentiate markets,
players, etc, then clearly this is not enough. At present the Core Components team has
a list of 10 possible classification areas, though some of us expect this to drop to
between 6 and 8 factors in the final analysis. We have been looking at the
categorizations used by the European Commission's Statistics office, which extend
those used by UNSPC, but even these need some extension. This is an area that needs to
be discussed in San Jose next month as part of the process of harmonizing the business
process and core components models within ebXML.
Martin Bryan
------ XML/edi Group Discussion List ------
Homepage http://www.XMLedi-Group.org
Unsubscribe send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
