OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC