Okay - Let's throw some context on them codes....

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

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"