RE: TRP Work Plan - Version 17 Aug 00

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

My reasons for adding it to the Work Plan as I did was:

- simplicity
- there may be vendors which will create Messaging Services, and these 
Services need to be interoperable with respect to higher layer business 
processes

But I don't care about the packaging decision, as long as someone gets 
going on getting this interface decided for the POC and we look towards a 
final solution. Rik/Chris, how do you want to lead this resolution?

Jim

At 12:58 PM 8/18/00 -0700, 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