[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: The role of context in the re-usability of Core Components an dBusiness Processes - OR Say What???
-----Original Message----- From: William J. Kammerer [mailto:email@example.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: firstname.lastname@example.org
Powered by eList eXpress LLC