Re: [ebxml-dev] ebXML specifications interdendancies

["Fred Blommestein, van" <f.van.blommestein@berenschot.com>]

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