[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: More on throwing some context on them codes....
William: The code lists in xCBL were put there at the request of EDI users who wanted to make sure we wouldn't miss the codes they wanted to use! I admit that ebXML is setting out to solve this problem, by doing exactly as you argue: attaching meaningful data about what the relevant use of a code (or any other semantic structure) is. If we had an automated concept of "context" today, xCBL wouldn't look the way it does - it would be much cleaner and leaner. I think that's why my employer pays for me to fly all over the world and attend ebXML conferences, actually. I would point out that the phenomemnon associated with codes is one that is encountered in amny different ways in different e-business vocabularies (in EDI syntaxes, that are very code-intensive, it is focused on qualifying codes; in XML vocabularies, you tend to see a similar phenomenon around the use of containing elements, which serve as semantic qualifiers in amny cases. Same problem. Industry-specific is industry specific, and it's not common.) I agree with your point: we need to be able to match (and include or exclude) specific codes and other constructs on the basis of their explicit relationship to the business that *we're doing with the message in question*. Cheers, Arofan Gregory -----Original Message----- From: William J. Kammerer [mailto:email@example.com] Sent: Thursday, March 15, 2001 2:22 PM To: ebXML Core Subject: More on throwing some context on them codes.... In 1998, Transaction Set 284 - Commercial Vehicle Safety Reports - was added to ANSI ASC X12 004020 (Version 4 Release 2) by DM#098198. The message has something to do with commercial vehicle safety reports. In order to identify relevant parties to such a report, new codes were added to D.E. 98 Entity Identifier Code for Co-Driver, Complainant, Interviewee, Law Enforcement Agency, Towing Agency, Party Performing Verification, and Victim. Certainly the folks intending to use this transaction set had yet other parties in mind, but it stands to reason that the - by now - mature X12 standard already had existing codes for things like Repairing Outlet, Inspection Location, and the like. But somehow these very same codes, perhaps peculiar to American public highway safety, found their way into enumerations for the XML Common Business Library's (xCBL) PartyRoleCode as "Co-Driver," "Complainant," "Interviewee," "LawEnforcementAgency," "TowingAgency," "PartyPerformingVerification," and "Victim"!! See http://www.xcbl.org/. The same thing repeats itself for enumerations within yet other xCBL elements: e.g., xCBL's QuantityQualifierCode has "Arrests" and "Lanes" - introduced with and for transaction 284 - and which most certainly don't have anything to do with the xCBL's coverage of Direct and Indirect Procurement! The point is not to make fun of xCBL, or to pick on my friends at Commerce One certainly, but to illustrate how a glaring deficiency in EDI (maintenance and documentation) may get propagated into ebXML - viz., the failure to annotate codes with their expected functional utilization; at a minimum, in this case, of either the subcommittee X12G (Government) which devised the code, or a general category like "Highway Safety." Commerce One could have avoided picking these codes up if their categories - or "context" - failed to match those desired when building their schema components. The result would have been a much leaner and more maintainable standard, without obviously ridiculous ("arrests"???) codes littering xCBL documentation. William J. Kammerer FORESIGHT Corp. 4950 Blazer Pkwy. Dublin, OH USA 43017-3305 +1 614 791-1600 Visit FORESIGHT Corp. at http://www.foresightcorp.com/ "accelerating time-to-trade" ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: firstname.lastname@example.org
Powered by eList eXpress LLC