RE: [ebxml-cppa-negot] "Context"

[Dale Moberg <dmoberg@cyclonecommerce.com>]

I do hope that that some use cases
are provided for what Context is and does.

So far, it seems to be something like an
EDI implementation guide, possibly generalized
so that it transforms off-the-shelf data elements
(core components) into "localized" data elements,
where localization pertains to some identified
aspect of collaboration. But what are the range
of these customizations? Does it include:
natural language, currency, tariffs, taxation,
date formats, addressing variants, phone numbers
and so on. And how is it implemented? As an XSL transform
over pre-defined core components? If so, how do the
transforms compose/layer (any order dependencies), 
any constraints on replacements, etc, etc. 

Also, is there any real difference between
multiplying number of transforms applied versus
multiplying number of core components? You can
shift the complexity from one place to another,
but it is going to pop up somewhere or other (tm).

Finally, while I could see something like an DocumentPA
for handling the resulting agreements on how
the final business document is to be composed
from core components and applications of transforms,
should we even attempt to accomodate _that_ 
negotiation process within our scope?
I would imagine that the distinction
between minor adjustment of values versus
major structural change that we may try to
analyze would not be the same for negotiation
of business documents as for CPAs. And we
have not even succeeded for CPAs which is something
for which we do have a scope defined.

My personal preference would be 
to define a specific negotiation
process that can be seen to have "quick"
convergence characteristics (either to proposed
CPA, no CPA possible without modifying
exisiting software, or human intervention
required) and have it work for CPPs and 
CPA templates. If the result applies to some
other area, fine. If not, then the other area
will have to define their negot. process. 
In other words, I think a premature craving for
excessive generality in this area is
a potential pitfall to be avoided in our subgroup.


Dale Moberg


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Sunday, December 16, 2001 7:42 PM
To: ebxml-cppa-negot@lists.oasis-open.org
Subject: [ebxml-cppa-negot] "Context"


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>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>