[ebxml-cppa-negot] "Context"

[Martin W Sachs <mwsachs@us.ibm.com>]

There has been a fair amount of "context" on ebxml-dev since I posted Duane
Nickull's request that the negotiation process include a context message.
Here is a sample.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 12/16/2001
09:40 PM ---------------------------

"Fred Blommestein, van" <f.van.blommestein@berenschot.com> on 12/16/2001
05:22:36 PM

To:    ebxml-dev@lists.ebxml.org
cc:
Subject:    Re: [ebxml-dev] ebXML specifications interdendancies



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>