Re: [ebxml-cppa] Re: Context Issues

[Christopher Ferris <chris.ferris@sun.com>]

Marty,

Agreed. Maybe what can be done is to provide a place-holder
for some context fragment that is intended to come from
some foriegn namespace (e.g. one defined by BP or CC team)
that the CPP/A team includes in their schema. Once the BP/CC
team figures out what the schema for the Context element,
they can simply incorporate it into a CPP/A instance.

e.g.

<element name="ProcessSpecification">
   <complexType>
     <sequence>
      <element ref="ds:Reference" minOccurs="0"/>
<!-- added to provide for future "context" info -->
      <any namespace="##other"
	processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute ref="tns:version"/>
    <attribute name="name" use="required" type="tns:non-empty-string"/>
    <attributeGroup ref="tns:xlink.grp"/>
   </complexType>
</element>

Let them figure out what it is, but incorporate a useful
placeholder into which their context info can be placed.

Cheers,

Chris

Martin W Sachs wrote:

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