[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: UNSPSC - and code lists in general
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"
Powered by eList eXpress LLC