[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: TRP Work Plan - Version 17 Aug 00
Could we loose the term API since it's such an overloaded term? Nick At 03:53 PM 8/18/2000 -0700, Gordon van Huizen wrote: >Ah. Trigger finger on my part. I'll blame it on a bad headache today. > >-gvh- > >David Burdett wrote: > > > > Gordon > > > > I'm just arguing that we put the service interface in a separate document. > > That's all. > > > > David > > > > -----Original Message----- > > From: Gordon van Huizen [mailto:gvanhuiz@progress.com] > > Sent: Friday, August 18, 2000 1:35 PM > > To: David Burdett > > Cc: 'Jim Hughes'; ebxml transport > > Subject: Re: TRP Work Plan - Version 17 Aug 00 > > > > A counter argument: > > > > We have done nothing, to date, to specify higher-level messaging system > > semantics (batching, application-level acknowledgements--distinct from > > replies, error handling, etc.). I don't see how we can possibly validate > > the specification without having drilled into this. I believe we need to > > have a concrete idea of what the service level semantics are as they > > relate to the application. This doesn't mean that we need to develop an > > "API", which is where I think most people get stuck. > > > > -gvh- > > > > David Burdett wrote: > > > > > > Jim > > > > > > I firmly beleive we *don't* put the Service API spec into the messaging > > spec > > > but should instead keep it as a separate document. The reasons are: > > > 1. The API's you use to interface with the ebXML Messaging Service is > > purely > > > an implementation decision. If, for example you wanted to put the service > > on > > > a PDA then compliance with the Service Interface could be too burdensome > > > 2. More importantly conformance to the API is not required for > > > interoperability between trading partners. All that is needed is > > compliance > > > with the wire protocol > > > 3. It will make it harder to maintain and revise the document as the > > editor > > > role will become a bottleneck > > > 4. There is a requirement in the Overview & Requirements document that > > says > > > ... > > > > > > "1) Servers/systems that support the exchange of documents shall > > be > > > treated as "black boxes" " > > > > > > We definitely do need the spec as it will make it easier for business > > > process (i.e. application) implementers to do plug-and-play with ebXML > > > services from different vendors. > > > > > > David > > > > > > -----Original Message----- > > > From: Jim Hughes [mailto:jfh@fs.fujitsu.com] > > > Sent: Thursday, August 17, 2000 2:27 PM > > > To: ebxml transport > > > Subject: TRP Work Plan - Version 17 Aug 00 > > > > > > Based on comments from the TRP meeting this morning and several email > > > messages, here is a new cut of the plan. > > > > > > Significant changes: > > > > > > - added Service API to the plan. I believe the first version must be > > folded > > > into the overall Messaging Services Spec within the month, and some > amount > > > of the Service API should be approved in Tokyo. > > > > > > - I have indicated where we should release the Messaging Spec, the > Service > > > API drafts and the Messaging Spec to the POC. > > > > > > Other notes: > > > > > > - as before, I've made some assumptions about the Security work, so I > need > > > confirmation of these dates... > > > > > > - I arbitrarily assigned major version numbers to the Messaging Services > > > Spec (based on approval at plenary meetings) and showed how the > > subordinate > > > specs are being folded into it. > > > > > > - I reduced the chart scope to just the Vancouver meeting so it prints > > > better. We don't know what we're doing between Vancouver and Vienna just > > > yet...! > > > > > > - 5 days is shown for Quality Team review, with two-week Member reviews > > > immediately following. We may need some time inserted to react to Quality > > > Team comments... > > > > > > And apologies to Rik/Chris, as they haven't yet approved/commented on the > > > work plan. I trust they will concur in our planning work during their > > > absence! > > > > > > Jim >begin:vcard >n:Van Huizen;Gordon >tel;work:510-848-1988 >x-mozilla-html:TRUE >url:http://www.sonicmq.com >org:Progress Software;XML and Internet Technology >adr:;;14 Oak Park;Bedford;MA;01730; >version:2.1 >email;internet:gvh@progress.com >title:Director, Product Management >fn:Gordon Van Huizen >end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC