Re: [ebxml-cppa] Re: Context Issues

[Martin W Sachs <mwsachs@us.ibm.com>]

Chris,

What you say makes sense. Duane Nickull has asked the negotiation subteam
to include context.  I have a problem.  Unless BPSS does something about
context, it's a bit hard to know what has to be in the CPA.  It's probably
a lot more than just locale and industry.

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
*************************************************************************************



Christopher Ferris <chris.ferris@sun.com> on 01/16/2002 09:42:19 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    ebxml-cppa@lists.oasis-open.org
Subject:    Re: [ebxml-cppa] Re: Context Issues



I agree. While the CPP/A currently just points to
a BPSS instance, I think that the idea that they have
is that a BPSS is a generic, which is interpreted in the
light of some context that may effect the processing of
the BP or at the very least, effect the assembly/choice of the
appropriate schema(s). It may therefor be required that a
CPP/A carry the context in addition to its reference to the
BPSS instance. e.g. (forgive the inaccuracies here, this is
meant only as an example of what I'm suggesting):

 <Process xlink:href="someuri" ...>
  <Context>
   <Locale>en-US</Locale>
   <Industry code="xxx"/>
   ...
  </Context>
  ...
 </Process>

The BSI/BPF would then use the context in a meaningful
way to ensure that the BP referenced is interpreted and
executed in consideration of the supplied context.

Cheers,

Chris
Martin W Sachs wrote:

> The following posting mentions CPP and CPA.  I don't fully understand
what
> he is talking about and he may not understand CPP and CPA and am
wondering
> if he is really talking about BPSS, but there may be food for thought
here.
>
> It is apparent that context (internationalization issues, for example) is
> becoming an important subject and there probably will need to be some
> CPP/CPA involvement eventually.
>
> 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
01/16/2002
> 09:29 AM ---------------------------
>
> "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>
>