Re: UNSPSC - and code lists in general

["William J. Kammerer" <wkammerer@foresightcorp.com>]

After I pooh-poohed David RR Webber's suggestion of having "a central
location that people can reference [to find applicable code lists],"
mostly because there's just so darn many code lists by so many different
agencies, Mark Crawford, of LMI Logistics Management Institute, wrote in
to say:

   If I understand correctly, one of the premises of ebXML is that
   the repository will provide a business (initiating party) with
   the ability to download a potential partners profile and process
   model(s) to create transaction(s).  If the potential partner
   relies on a code list to differentiate components of an element,
   won't the initiating party need access to that code list?  If so,
   then how will he access it unless the partner profile provides a
   URL, or the list is in a central repository such as XML.ORG?  I
   understand your concerns with the scope of the problem.  However, if
   my understanding is correct, David is right and this is something
   ebXML needs to address.

Mark:

We'd have to ask the Repository folks whether "one of the premises of
ebXML is that the repository will provide a business (initiating party)
with the ability to download a potential partners profile and process
model(s) to create transaction(s)."  But it sure sounds reasonable to
me.  I've had a real hard time going through the ebxml Registry and
Repository Part 1- Business Domain v1-0 document at
http://www.ebxml.org/specdrafts/RegRepv1-0.pdf because it's so darn slow
to render in Adobe.  Are you having the same problem? Maybe they could
rebuild the PDF file from the original Word document.  Anyway this is
the specification with all the stick figures and talk about "actors."
That went over my head.

But, yes, I would think that, like in the eCO framework, you should be
able to "discover" new trading partners, and having done that,  to
"query" your real or potential trading partner to find all sorts of
things - including trading partner agreements and schemas, etc. etc.

As Bob Miller has explained in the past on Core Components, there's a
couple different types of code lists: 1) Text alias, 2) element alias,
and 3) reference service; see
http://lists.ebxml.org/archives/ebxml-core/200007/msg00073.html.
Element Aliaii (like "Ship to") look like the type of codes that
differentiate or parameterize a core component, much like segment and
loop qualifiers determine function in EDIFACT and X12.  These are
undoubtedly the type you're referring to, and I would think somehow that
they would be properties or somesuch of the component.  They would
probably be devised by the Core Components group, like the element alias
qualifiers are devised by the EDIFACT and X12 bodies.

But I thought David RR Webber and I were talking about the first type of
code list (the text alias) and sometimes the third type (the reference
service, as in UOM), generally promulgated by some type of external
agency or standards body.  These would just have to be cataloged as they
are encountered.  And it would be wishful thinking to think the creator
will produce an XML rendition of the code list; as a matter of fact, the
list may be too big to do so - as in the case of SCACs, UPC/EANs, etc.
The best we can hope for is a nice annotation in the repository to tell
you what one means by a "SCAC code" and where to find more information,
much as we see in Appendix A: Code Sources of the ASC X12 manual.

And in the real world, your trading partner rarely needs access to all
the possible codes, even for the smaller, finite lists like Unit of
Measure.  If you deal only in Eaches, Barrels and gallons today in
EDIFACT or X12, your EDI implementation guide probably has the
restricted list defined for the elements in question.  Then your trading
partner is saved the trouble of tracking down the UOM list.  Actually,
with all of Bob Miller's concern about "semantics," maybe he has in mind
some kind of exotic system which will take my "barrels" and convert them
to your preferred "liters."

Other times, you or your trading partner deal with only a certain few
motor carriers.  There's no need to buy the entire NMFTA SCAC code list
to get the few 4 character motor carrier codes you use.  Those few codes
are known because your carriers will tell you what they are (every
carrier knows his own SCAC), and you would put them in your own "schema"
or "guideline" or whatever.  And that's another point: many lists are
for sale only and are unlikely to be "shared" in the ebXML global
repository - the best you can hope for is a link to the people doing the
selling.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"