[ebxml-cppa] Re: Context Issues

[Duane Nickull <duane@xmlglobal.com>]

Guys:

I have implemented this in a rudimentry, yet workable form.  I can
demonstrate this and also bring up an issues list again in Seattle.

Some time ago, I advocated a code list for lookups of context rules to
form the context rules message.  

There are two times when Context is applicable.  One is during the
initial configuration of what business information a trading partner
might want to associate with their particular business process,  the
second time is once a CPA has been negotiated.  

The second time presents the most problems and I believe that the CPA
negotiation process has not been addressed properly.  Only at a time
when two CPP's are bound to a BPS, can ALL the context drivers be
known.  At that time,  a mechnism must capture all that information, and
somehow form a context rules message.  The CRM must then be applied to
the Core COmponents and the final metadata (not instance data) for the
business payload can be derived.  This is all during the design phase of
ebXML.

THe ideal way to do it was suggested (at least syntactically) by the
core components teams that handled context by using an ID for the
context rules message.  The contexst rules message from ebXML v 1.0 is
not suitable for using and a much simpler format that is declarative
should be adopted.  I wrote the basis for such a format and heavily
suggested that we use it, since it actually can be implemented.

The missing link is the code list which you would associate a certain
set of context drivers (eg - BP = "Procurement"; geopolitical="European"
etc) with a specific CRM with its' own unique ID.   This is not a
technical issue but one for the business people to sovle (and the
magnitude should not be overlooked - it is BIG).

Here is a small bit of java code  (thanks to Matt MacKenzie for working
on this too) that uses the new CRM format along with the current CCR/I
Core Components message to generate final metadata for th epayload by
applying the context rules against the CCR/I format.  It works.  Read
the README.txt file to get it running.

I have a new one I am working on that can spit out W3C schema, XML DTD,
RELAX/NG or Biztalk Schema format (.XDR) as final metadata which should
be of great interest to Biztalk users. This also leads me to believe
that "Syntax" should be another context driver since it is likely to be
used by each trading partner internally to aide in the transformation
process.  The final metadata can be easily loaded into a tool like GoXML
Transform and mapping can be done to the new ebXML compliant language
format and sent via the MHS.

Duane Nickull

"Fred Blommestein, van" wrote:
> 
> Marty,
> 
> Sorry for the confusion. Martin Roberts already corrected me. The assembly document is not directly referred to by the CPA, but through the BPS.
> 
> The big issue though is whether BPS and ASDOC are generic documents that need context to define an instance of a process with its documents, or whether the process of negotiating CPP's is making BPS and ASDOC specific. Are context rules negotiated as well?
> 
> I would like to offer the possibility to state in the CPP already rather specifically the capabilities of the company and its system, without the open end of trading partner context.
> 
> Fred
> 
> <<< "Martin W Sachs" <mwsachs@us.ibm.com>  1/16  4:27p >>>
> 
> Fred,
> 
> Please explain what an assembly document is.  The CPPA specification makes
> no mention of an assembly document. That means that it is in neither the
> CPP nor the CPA.  Therefore I am not sure what you are referring to when
> you say the the CPA refers to an assembly document.
> 
> I agree that context is important.  However I don't see what the CPPA team
> can do about it until there is some function related to it in the BPSS that
> the CPA needs to support.
> 
> 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
> *************************************************************************************
> 
> "Fred Blommestein, van" <f.van.blommestein@berenschot.com> on 01/15/2002
> 06:31:42 PM
> 
> To:    ebtwg@lists.ebtwg.org
> cc:
> Subject:    Re: Context Issues
> 
> Martin, all,
> 
> Let me try to add something to the "context discussion".
> 
> So context, as far as I understood, is a mechanism to sub- and superset
> named process-steps and named messages and message-components (BIE's). This
> is used because in some industries e.g. in the ordering process no order
> confirmations need to be sent, or ASN's, while in other industries using
> those documents is a must. Or some types of products need special
> classification (like dangerous goods) and other don't. Context is defined
> by context drivers. Industry (per role in the process) and product
> classification are among those drivers.
> 
> In the specification the CPP only refers to the standard processes/messages
> and states the context of the party whose profile is defined. The CPA
> refers to an "Assembly document". I understand that that document is a
> separate document, being the resolution of the standard
> processsteps/messages, after application of the context rules. The format
> of the "Assembly document" is, as far as I know, not yet defined.
> 
> An organisation, preparing itself for ebXML based e-business should make a
> mapping between its internal workflow and its application system to the
> standard processes/messages as defined in the registry. Those
> processes/messages though are not defined until the trading partner (and
> his context) is known. So the mapping can only be based on a foreseen range
> of contexts of possible trading partners (supposing that the set of context
> rules is stable). This not only complicates defining the mapping. If a new
> trading partner has a slightly different context than foreseen, the context
> rules must be applied again to check if the mapping can handle it. This
> will probably be a manual process.
> 
> If however, the CPP would also refer to an "Assembly document" (either a
> resolution of the standards and the context rules of the company, or a
> manual adaptation of the standards based on the company's capabilities, or
> a combination of those), the confrontation of standards and capabilities,
> and the resulting mapping, can be done once: when the CPP is prepared. In
> the "CPP-assembly-document" per process step or BIE it should be indicated
> whether the organisation cannot, can or must handle such step or BIE. The
> CPP to CPA process can then be a straightforward parsing process that
> compares the capabilities of the trading partners until the level of the
> BIE (or even the codes used therein).
> 
> Such mechanism also gives organisations the freedom to deviate from the
> rest of its industry. Suppose my company is in the telecom industry, but
> the services I render are simple enough to code with an EAN/UPC number.
> Then I do not need to demand from my customers that they have an ordering
> system that can specify complicated telecom-services. Or if I am a
> third-tier automotive supplier and cannot handle ASN's, I can still do
> business with individual customers that not really demand ASN's (while it
> would be common practice in the industry as a whole).
> 
> To further simplify the CPP-to-CPA process I would propose to name adapted
> process-steps and BIE's differently from the standard steps and BIE's they
> are specialisations of. Those parent standard steps/BIE's can be defined as
> the "types" of the specialised ones. If in two CPP's the (higher level)
> names are equal, the parsing process can then skip to the next step or BIE.
> If the types match the parsing should go one level deeper. If the types
> don't match the necessity to send or receive (cannot/can/must) should be
> looked at.
> 
> This way we would use context as a mechanism to discuss (on a global scale)
> the applicability of processes and information entities to specific
> industries, product groups, etc., but leave individual companies the
> freedom how to organise their workflow and their information systems. And
> we would probably reach a higher level of interoperability, as we
> investigate at the time of (automatic) collaboration negotiation the
> specific capabilities to a detailed level, instead of assuming a context
> definition that can only be an industry average.
> 
> Possibly I have a completely wrong view on the proposed solutions. In that
> case please educate me (I am not alone). Otherwise, these are my two
> eurocents.
> 
> Fred van Blommestein
> Berenschot / EP-NL / OpenXchange
> 
> <<< <martin.me.roberts@bt.com> 1/15 11:32a >>>
> Folks,
> I have published a brief paper to get discussions flowing on the
> issue of what is in an assembly document and what rules can be applied. I
> believe strongly that this is a key weakness in the current architecture
> and
> document set.
> 
> I have titled the paper 'Context - a statement of the obvious'
> because I feel that context should be obvious and not opaque as it is at
> the
> moment.
> 
> I would like to discuss this with interested parties prior to
> Seattle. To do this I have set up a conference call, details are:
> 
> Reference: A 3982465
> Date: 17 January 2002
> Time: 18:00 (GMT) 13:00 (EST) 10:00 (PST)
> Duration: 1 Hour 10 Mins
> No of lines: 20
> Chairperson: Martin Roberts
> Telephone No from UK: 08706000825
> Telephone No from abroad: +44 (0) 2088133300
> Pin No: 332292#
> 
> Do join in the debate as I feel this will indeed close the loop in a number
> of peoples minds. <<Context.doc>>
> 
> Martin Roberts
> xml designer,
> BTexact Technologies
> e-mail: martin.me.roberts@bt.com
> tel: +44(0) 1473 609785 clickdial
> <http://clickdial.bt.co.uk/clickdial?001609785.cld>
> fax: +44(0) 1473 609834
> pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5 3RE,
> UK
> BTexact Technologies is a trademark of British Telecommunications
> plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no. 1800000
> This electronic message contains information from British
> Telecommunications plc which may be privileged or confidential. The
> information is intended to be for the use of the individual(s) or entity
> named above. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this
> information
> is prohibited. If you have received this electronic message in error,
> please
> notify us by telephone or email (to the numbers or address above)
> immediately.
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebtwg.org/ob/adm.pl>
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebtwg.org/ob/adm.pl>

-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/

GoXML-CCEngine.zip