RE: More on throwing some context on them codes....

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

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:wkammerer@foresightcorp.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: ebxml-core-request@lists.ebxml.org