The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???

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

I have taken another look at the ebXML specification: The role of
context in the re-usability of Core Components and Business Processes,
Version 1.01.  I'm making a confession: I still don't get it.

Okay, so I've got a procurement process, and I'm dealing with paint, and
I'm in the U.S, and I'm selling to somebody in France, and it's Tuesday,
and pigs fly, and this thing is going to apply these "contexts" to come
up with.... what?? A schema? Is this being used to build message schemas
(as opposed to document instances) on the fly?  Do these rules determine
what's included as XML elements at execution time when the message
instance is built?

I have a suspicion that this "context" stuff is a little too complex,
and perhaps unnecessary.  Most of this kind of stuff should really
devolve on the application and the people who know the business the
best.  And, besides, "context" isn't really what causes people to have
conniptions when using EDI - they know full well that they need a state
or province code when sending U.S. or Canadian addresses, or that a VAT
(tax) is not used in the U.S., or that they have to add some sort of
hazard designation if so required - or send a separate MSDS - or that
they have to put junk in there for customs if going over the border,
etc. etc. What makes us think we know the application better than the
business using ebXML?  The problem with EDI is figuring where the heck
to put in the VAT - what segment? in the detail or the summary or both?
What code means "VAT" once I find the segment?

Confusion sets in when I read Line 141: "Another [rule] specifies that
if the seller is in France, the product description (in French) shall be
included [in invoice line items.]"  Why?  The seller isn't going to be
reading  the invoice - the buyer does. Is this just a boo-boo? - as the
sample context had the BUYER in France.

In any event, the product description should be in the preferred
language of the buyer, if that's possible.  But it's not necessarily
the predominant language in the buyer's country;  a U.S. buyer may want
the description in both English and Spanish, and so you can't just have
a simple context rule based on the country code of the buyer's ship-to
location.

Maybe this kind of stuff ought just be business rules in the
application - the customer file would say what languages he prefers for
the product description, if any.  The "if any" is important - a SME or
consumer may always want a product description, but a shop with
sophisticated IT capabilities would rather forgo it, as they would load
a catalog with product IDs and descriptions and be able to retrieve the
descriptions themselves.  Sure - these decisions seem like a lot of
effort, but that's why they call it "work." There's no reason for us to
take on application work - and do a half-assed job of it in the
process - all the while putting the user in a straight-jacket.

Now, I'll be the first to confess that I don't really understand how the
business process model correlates with the business documents to be
exchanged.   Referring to Line 498, section 6.9 (Role Context), I have
this vague impression that the business process mandates that I have
both a buyer and seller, which will result in party definitions for
each. So far so good - that kind of correlates with how I think of a
Purchase Order.

But I'm really thrown off with that business in Rule #3 about specifying
the preferred carrier - is this done when generating the schema to be
used, or when I generate the document instance?  Isn't this a decision I
might make on the fly, in the application, depending on all sorts of
scenarios: maybe I have a preferred carrier only if it's FOB origin, or
it's LTL and bigger than a bread box, or whatever strange gymnastics
attend.  I'm having a hard time differentiating when business rules
leave off and when and this strange thing called "context" takes over.

Help me out. Are we writing specs for an ERP system here?

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"