Re: TRP Work Plan - Version 17 Aug 00

[Jim Hughes <jfh@fs.fujitsu.com>]

No problem with me, I changed it in the work plan. That's easy. Now, who's 
doing a draft proposal for this service interface?

Jim

At 05:09 PM 8/18/00 -0700, Nicholas Kassem wrote:
>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