RE: The role of context in the re-usability of Core Components an dBusiness Processes - OR Say What???

[James Whittle <james.whittle@e-centre.org.uk>]

		-----Original Message-----
		From:	William J. Kammerer
[mailto:wkammerer@foresightcorp.com]
		Sent:	15 March 2001 05:44
		To:	ebXML Core
		Subject:	The role of context in the re-usability of
Core Components and Business Processes - OR Say What???

		Hello, I just couldn't resist making a response to this, see
below;


		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.

		Well context at the highest level, like geographical region,
or industry sector, is pretty straight forward. It does get more complex at
a lower level, but guess what it is a complex world out there, and context
just might be the best way to manage that complexity. If you want an example
of just how complex it can get take a look at UN/CEFACTs work on modelling
the international supply chain.

		The document you refer to gives an list of possible context
drivers, more should and will be discovered by domain business experts and
application developers.

		  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?

		If you believe that context isn't the factor which creates
differences between EDI implementations then you don't understand what
context is. The very fact of the matter with EDI was that different
businesses in different contexts assumed they knew what address information
or customs "junk" was required. The fact of the matter is that their
perspective was limited to their own specific context (business, sectoral
etc), hence the problems today with EDI becoming so bloated and difficult to
implement in an interoperable manner. As far as I am concerned I don't
presume to know business domain experts business domains better than they
do, and that is why we have business domain experts establishing the context
factors which are critical to them.  

		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"



	
------------------------------------------------------------------
		To unsubscribe from this elist send a message with the
single word
		"unsubscribe" in the body to:
ebxml-core-request@lists.ebxml.org