Subject: Re: The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???
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" <firstname.lastname@example.org> To: "ebXML Core" <email@example.com> 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: firstname.lastname@example.org >
Powered by eList eXpress LLC