OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: TRP Work Plan - Version 17 Aug 00


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC