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

[Martin Bryan <mtbryan@sgml.u-net.com>]

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