[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Okay - Let's throw some context on them codes....
Thanks for the responses from Martin Bryan, James Whittle and Stephane Canon to my queries in "The role of context in the re-usability of Core Components and Business Processes - OR Say What???" Now I think I understand that the "context" drivers are applied beforehand to generate new business core components extended or restricted using the base ebXML core components. Kind of like parameter-driven EDI guideline generation which UN/CEFACT EWG D4 Transport and ITIGG are investigating: depending on the mode (e.g., Air, Maritime, Motor, Rail or inter-modal), and/or single or multiple consignment, you can press a button, and whammo! - a new specific EDIFACT guideline is generated with only the segment groups, segments, elements and codes which are applicable in that context marked as used (or usable). But this is done only at the coarsest level. And maybe the jury is still out whether it would have been better to have one big jumbo generic message as opposed to lots of specific (and not necessarily simpler or smaller) messages (e.g., IFTM** or CO****) particular to "context" in UN/EDIFACT. Copious documentation and notes and dependency controls within a single guideline or message can cover a multitude of sins without reverting to "context" rules - which are themselves a form of documentation. Speaking of documentation, or lack thereof: this may be the single biggest problem in EDI of both the X12 and UN/EDIFACT varieties. Though business cases were made for each and every change to a message or segment or element or code, this valuable information is completely lost by the time of publication. All you're left with is a naked UNSM (UN/EDIFACT standard message) or X12 transaction set giving absolutely no "context" for the structures and codes. At best you may have some Transaction Set notes for segments and loops describing their usage, or in UN/EDIFACT "contextual" group and segment notes may appear in the heading. For an example, see the UN/EDIFACT Invoice message at http://www.unece.org/trade/untdid/d01a/trmd/invoic_c.htm. But again, by the time of publication, they're so watered down and generic that you have a hard time figuring out when you'd use the stuff. This is a organizational and publication problem more than a technical one. The simplest case to examine is that of codes. Codes are added at a prodigious rate to relatively generic coded elements, till the point there are hundreds or thousands of codes available. But only a relatively few pertain to an industry sector, which is left for an industry consortium or standards body to sort out (like VICS for X12 or EANCOM for UN/EDIFACT). At the time the codes were added to the standard, it was relatively clear in which context they would be used (e.g., industry and circumstances), because all that had to be explained in the Data Maintenance item. All that valuable verbiage is lost due to publication constraints, though. So you have codes in the X12 Reference Identification Qualifier (D.E. 128) describing "Dentist License Number," "Airline Ticket Number," "Census Tract," and "Escrow File Number," which are all obviously applicable to wildly different business scenarios, covering the gamut from Health claims to mortgage applications. Either different Qualifier Sets should be defined (e.g, HealthCareClaim.ReferenceType, or MortgageLoan.ReferenceType) to be used in the appropriate functional area, or context rules should be attached to the codes themselves. In any event, unless this is done (and am I advocating "context" rules now?), XML is not going to be any cleaner and easier to use than EDI. Witness xCBL: though I realize much of it was carried over from X12 and EANCOM, it seems to have no notion of "context" or else I wouldn't see the same old D.E. 128 reincarnated as "ReferenceTypeCode," with permissible enumerations including "AirlineTicketNumber," "CensusTract," and "DrugEnforcementAdministrationNumber"!!! 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"
Powered by eList eXpress LLC