Re: [ebxml-dev] ebXML specifications interdendancies

[Mike Rawlins <mike@rawlinsecconsulting.com>]

My view of it has always been that context is an analysis aid, a kind of short cut to help you quickly get to things which are defined differently in different business processes or industries.  In the date example you cite, we have two different contexts because there are two different business processes.  The difference really comes in at the level of the aggregate in which the dates are used.  At a very general level, J has carries similar kinds of information in contexts A and B.  However, in context A J might be composed of R, S, and X.  In
context B it might be composed of R, Y, and Z.  In neither case is context *needed*, it is just an aid.  Without context, you could say that if in A, J = R + S + X, and in B, J = R + Y + Z, then, then we really not talking about two Js but a J and a K.

Other than that, all that I can suggest that you do is go back to the ebXML1.0 specifications and study the sections on context.  The next article in my ebXML series will deal with core components and contexts.  I'm going to try to explain the concepts in a way that I haven't seen other people do yet, so you may want to watch this list when it is posted.  I doubt, however, that I'll complete it until after the holidays.

Hope this helps.

Duane, if you want to try to answer Fred's questions, be my guest.

"Fred Blommestein, van" wrote:

> Duane, Mike,
>
> Excuse me for breaking into your discussion, but I still am very confused about this Context concept.
>
> Duane stated:
> > Core Components are too abstract to be readily usable. For Core
> > Components to be used on a global basis, we need the context
> > mechanism. Otherwise, ebXML users will likely convert their existing
> > business messages into their own core components. This will lead to a
> > proliferation of core components, hence interoperability will suffer.
>
> Mike answered:
> >Agreed. Core components are defined as being context independent. Any real business data
> >has context associated with it. In ebXML terms, a Business Information Entity is a CC with
> >context applied (at least according to my understanding of the latest CC draft).
>
> Can someone give me one valid business example of the use of context? The only example I ever saw was the one that let context define to include the "State" in the address of a party located in the US. That is a non-valid example as it is not the geopolitical context of the party that triggers the inclusion of the "State", but the Country code in the address itself (and the postal service used).
>
> If Core Components are not limited to Core Component Types, context is always more or less implicitly or explicitly defined. E.g. a "Date" is a Core Component Type. A "Delivery Date" puts this type already in a certain context ("Delivery"). We can further refine to "Expected Delivery Date" or "Delivery date of consignment 12345". The former can in my opinion be defined as a Core Component itself, the latter context is implicit in the Aggregate, message and/or process where the Date is used in. So we would not need an extra context mechanism.
>
> It may be the case that e.g. the Automotive industry wishes to add the time of the day to the expected delivery date, while the Chemical industry does not. Probably then, the Automotive industry uses a different business process, and differently named messages, where the delivery date is included in. In the "Automotive" messages a "Delivery Date-Time" would be used then, and in the Chemical Industry a "Delivery Date". Again a separate context mechanism is not needed.
>
> Please show I am wrong by giving some examples where the context mechanism, with the pre-defined context drivers, is needed.
>
> Fred van Blommestein
> Berenschot / EP-NL / OpenXchange
> The Netherlands
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com