Re: [ebxml-cppa] Re: Context Issues

[Duane Nickull <duane@xmlglobal.com>]

Dale:

If you can make it,  I will schedule a meeting with the BPS and CC team
liaisons and we can go through all of this.  I really think this will be
a break through in getting all the specs to interoperate.

Marty - too bad you can't make it there.  We would value your input.

Best Wishes

Duane

Martin W Sachs wrote:
> 
> The CPPA team is not meeting in Seattle and I definitely won't be there.
> 
> I suggest you discuss possibilities of getting together at some other time
> with Dale Moberg.
> 
> 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
> *************************************************************************************
> 
> Duane Nickull <duane@xmlglobal.com> on 01/16/2002 02:06:12 PM
> 
> To:    Martin W Sachs/Watson/IBM@IBMUS
> cc:    "Fred Blommestein, van" <f.van.blommestein@berenschot.com>,
>        ebxml-cppa@lists.oasis-open.org, ebtwg@lists.ebtwg.org
> Subject:    Re: [ebxml-cppa] Re: Context Issues
> 
> Marty:
> 
> The context is not something that the CPA does,  it is a set of
> parameters that are created when a CPA is formed.  They are simple
> name="value" pairs which are called "Context Drivers".  Examples are
> things like:
> 
> geopolitical="Europe"
> Industry="SHOE Manufacturers"
> Business Process = "Procurement"
> 
> etc.
> 
> We need to finalize a way to express those so they can be coordinated
> with a list of context rules messages (CRM's).
> 
> The CRM is a way to declare all the contexts that a final design of a
> business collaboration WILL use.  It is done during the design phase.
> 
> The CRM is used, along with the COre Components, to create the final
> business payload metadata.  The final payload metadata can then be
> polulated with instance data and sent as part of the business
> collaboration.
> 
> The reason I am so vocal about the CPP/A team looking at this is that
> some of the context drivers have to be taken from CPP's and CPA's.  If I
> am creating a CRM,  I need to be able to grab the geographical context
> of each party (Hence my non-stop nagging that we have an XML declaration
> of someone's address), the business process classification (can be
> grabbed from the associated RIM), etc etc.
> 
> Can you arrange to meet with us in Seattle and I can do a demonstration
> of all the mechanisms that interact?  I think it would be helpful is
> everyone interested in this thread could arrange to meet at one place.
> 
> Duane
> 
> Martin W Sachs wrote:
> >
> > 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.oasis-open.org/ob/adm.pl>
> 
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/

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