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

[Philip Goatly <philip.goatly@bolero.net>]

Folks,

1.I wonder if there is not a case for having a 'Total' view of say address -
including anything that is needed in virtually any context UK,US, Outer
Mongolia etc. and having a mechanism for a View of the 'Total' which
switches off what is not needed ?

2.You might like to consider the consequences for interoperability if  one
allows one business entity to decide in isolatino what he/she needs - are we
not reinventing the 'Tower of Babel' ?

Cheers, Phil
----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Thursday, March 15, 2001 5:43 AM
Subject: The role of context in the re-usability of Core Components and
Business Processes - OR Say What???


> 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"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>