[ebxml-dev] re: CC Specification Review (long)

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

David,

You envisage the translation of CC's into BIE's as a dynamic process at runtime. If that is to be implemented, somewhere the rules must be stored according which the CC's are transformed (or narrowed), driven by context. Whether the storage format is a "language" or a database (BIE registry)  is less important in my view. 

I worry more about the mechanism how these rules are established. This can be done in closed user communities (like you suggest), but then the difference with the present EDI situation is not spectacular  (in fact absent). Interoperability between user communities will still not be possible. It can alternatively be done by a (worldwide) standardisation committe, like UN/Cefact. But will that be manageable and effective? I doubt that, and therefore I wish to add something else to the discussion.

In the ebXML architecture the exact collaboration between trading partners is defined by the CPA. The CPA points to a Business Process Specification, subject to context. The Business Process Specification points to Assembly Documents that consist of (or are dynamically assembled from) Business Information Entities. Business Information Entities are (either defined or dynamically) modified and structured Core Components. The modification and the structuring are context driven. I hope we agree on this.

The CPA is being formed by reconciling two CPP's. The CPP to CPA process is envisaged as an automatic negotiation process. Presently the CPA defines the collaboration control and security mechanisms and not the specific process choreography and document content. Process choreography and content are assumed to be defined by the context of the trade relation.

Context is a powerful mechanism. It should allow businesses to exactly define business processes and documents, without having to model the processes and documents themselves. The modelling has been done previously, has been stored in a repository and has been attached to the context of the business. Context should easily be determined by business people.

Context taxonomy and the context driven modification and structuring rules though must be standardised. That means that it will take time to arrive to a complete, internationally and cross-industry useable, set and that the result will be based on compromise. It also means that the result defines industry averages, as concluded by standardisers.

Individual companies though, in the free world, are free to deviate from their industry average. Some will be more advanced than others, in logistical concept and in IT support. So within the same context some companies will be able or willing to support complex processes and others only simple ones. Some are very advanced in IT support and will be able to send and receive complex electronic messages and others only short messages, based on previously (manually) exchanged basic information like contractual conditions and product definitions.

One of the goals of ebXML is to maximise interoperability between application systems while allowing sufficient variation. The context mechanism only allows variation between contexts, not between individual organisations within the same context. Moreover, as yet no mechanism is available for a company to state what *trading partner* contexts it can handle, or it must be implicit in the definition of business processes. Even then, no mechanism is offered for a company to state which contextual modifying rules it supports. 

Context is defined at the level of the trading relationship. So before the trading partner is known, context is not (fully) known. So organisations can only define their organisational and application interface after the trading partner is known. 

A company that wishes to prepare its organisation and application system for ebXML cannot get clear specifications from the repository. It may try to define how big the eight-dimensional context space is it wishes to serve, but to get documentation of the exact process steps and BIE's that belong to such space needs a mechanism that is not defined (yet, if ever). Moreover, it is to be expected that the rules that translate context into specs will change very rapidly as the repository is being built up and as the adoption of ebXML is widening. So organisations are faced with an unstable situation for a lengthy period of time. This may block such adoption. 

One of the claims of ebXML is (implicitly or explicitly) that the setting up of trading relationships is supported as an automatic process. This as opposed to traditional EDI, where with each new trading partner both the process and the data to be exchanged must be negotiated. 

If a mechanism would be defined that compares the capabilities of organisations not by comparing their contexts, but by directly comparing the real capabilities in terms of process and document variation, interoperability can be extended over context boundaries and variation can be individually defined.

Such mechanism should allow organisations to link to their CPP the definition of the actual processes  and BIE's it really supports. These definitions should have built-in tolerance, to allow reconciliation with different definitions of potential trading partners. 

The following sketches roughly a possible architecture for such mechanism.

On the process level it should be possible to label certain process steps in the profile as required, conditional, optional or not supported. So if, as an example, using ASN's is such a process step, a company may state that it either:
supports using ASN's and requires its trading partners to support ASN's as well (required), or
it supports ASN's, but does not require trading partners in certain contexts to support ASN's (conditional), or
it supports ASN's but does not require that of any trading partner (optional), or
it doesn't support ASN's (not supported).
This specification can be stored in a company specific "Profile BPSS", linked to the profile itself. 

On the data level the "Profile BPSS" can reference specific "Profile BIE's"  (up to the document level). "Profile BIE's" are normal BIE's taken from the repository, but they should have built in tolerance.  They and their children should be attributed with additional cardinality, that states whether the component is  available or not supported by a sending application, or required, conditionally required, or not supported by a receiving application. 

So for instance a company in food trade could state that its application supports receiving orders with a "Sell By Date" at product item level, or that it requires its trading partner to carry that date in order documents that are exchanged, or that it requires the "Sell By Date" only for partners that sell fresh products (conditional). 

When two trading partners wish to set up a trading relationship, an automatic process can compare the structures and semantics of the two profiles (including referenced specific BPSS's and BIE's), to either conclude the profiles are incompatible or to construct new specifications of the actual process and of the data that is being supported by both. These specifications can then be referenced to from the CPA. They are translated into syntax specific definitions, like schema, DTD's or MIG's.

Probably this mechanism is possible using the present specifications. What is probably needed extra is some tolerance built in in process schema, attached to profiles and a (sematical and structural) hierarchy between BIE's. Implicitly this is present in the specs, I would prefer it to be explicitised.

For two main reasons I think we should develop ebXML further along the lines sketched above:
- Companies need to define the interface to their organisation and their application at the time they prepare their profile. When they meet trading partners the interfaces should be in place
- Companies are free to behave or not to behave according to their ("official") context. Still interoperability needs to be maximised.

Do you agree?

Fred van Blommestein

<<< David RR Webber - XMLGlobal <Gnosis_@compuserve.com>  4/29 12:38a >>>
Devendra,

I already raised this thru the Registry review of CC and the 
work of the CCR group.

Essentially BIE can be viewed as the result of applying 
Context parameters from the CPP to an AssemblyDoc to
produce a BIE that then maps to the physical business
payload by loading in the application data as described
by the BIE into the relevant structure leaves by 
retrieving your own local data points.

Therefore - the BIE is a transient in-memory collection
of elements as a result of running the AssemblyDoc.

Viewed this way - the BIE does not disappear completely.
You could if you wanted to store the BIE - but there seems
little point - since they can be regenerated by applying the
Context parameters from the CPP to the AssemblyDoc again.

In fact this is probably preferred to ensure always 
accurate results at design time - rather than retrieving a
previously built BIE.

The CCR and Registry review suggested that the CC
Spec' be amended to reflect that BIEs are not stored 
into the registry - since this would potentially cause
thousands of BIEs to be stored to no apparent 
business purpose.

To retrieve such BIEs you would need to know the
Partner ID, the CPP parameter context values used, and the
AssemblyDoc UID.   If you know all that you may
as well retreive the AssemblyDoc, and simply re-run it.

Thanks, DW
==================================================
Message text written by Devendra Tripathi
> 
Hi,

I am submitting my comments separately, but since this one is major
suggestion, I would like to float on reflector. I am aware of that some of
us want to even do away with BIEs.

When I analyse the definition sections carefully, the way I find BIE
differentiated from CC is that BIE has business context (part of
definition)
and CC has business semnatics (figure 4-1). This differentiation is very
thin and prone to confusion. I am wondering if we should use "industry
context", instead of business context. Thus a finacial account (a cc)  used
for "personal banking" and same used in the context of say "Transport &
shipping" may define BIEs for these industries.

Any thoughts ?
<


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