[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: Context Issues
See Chris' posting about simply referencing a namespace that has whatever information is eventually defined for it. 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/16/2002 11:07:22 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: <ebtwg@lists.ebtwg.org>, <ebxml-cppa@lists.oasis-open.org> Subject: Re: Context Issues 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC