Subject: Re: The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???
William > > 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? Context rules are used to create schemas/DTDs that can be used to validate messages designed to meet the needs of specific processes within specific industries in specific regions, etc. >Is this being used to build message schemas > (as opposed to document instances) on the fly? Not on-the-fly but on-demand. When a new process or context for a particular process is identified then a schema/DTD for validating messages in that context has to be prepared. > Do these rules determine > what's included as XML elements at execution time when the message > instance is built? The context rules do not determine the contents of the message instance, but the schema should be able to. > 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? The problem is that while humans know these things computers don't. The resultant schema is a record of these rules that a computer can use to validate the message. > 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. Its a boo-boo. The writer didn't understand that there is no mechanism in ebXML (at present) for using the contents of a message component to control the structure of the message. (See my earlier message re Show Stopper 2.) > 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. Agreed - but this requires a higher level message to determine, as part of the CPA, what set of rules are to be applied to a particular message in a particular context. Given an agreement that the set of rules that are to be applied to a particular process then these rules are used to carry out a set of modifications to the core component definitions assembled to meet the needs of the identified business process. > > 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. Remember we are B2B not B2C. Therefore the customer says this when setting up the TPA, not at the time of sending a message. >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. We are not trying to take on B2C requirements of on-off trading agreements. > > 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? If the TPA says that carrier X is required, then the schema can predefined the value of the relevant element, and maybe prohibit users from changing this. > 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. In such scenarios the schema/DTD cannot be used to validate the message contents/structure, so we don't need this as a formally stated rule. > > Help me out. Are we writing specs for an ERP system here? Unfortunately it seems that this is exactly what is being done. Not what my goal for XML/EDI was, but this seems to be the way things have gone. Martin Bryan
Powered by eList eXpress LLC