Re: TRP Work Plan - Version 17 Aug 00

[Gordon van Huizen <gvanhuiz@progress.com>]

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