[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Re: Context Issues
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC