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


I agree. We should see if we can't get the RNIF mapping
out of the POC team. Prasad and others basically performed
this function for purposes of the SJ demo. It would be 
a useful, (non?-)normative appendix IMHO.

Chris

David Burdett wrote:
> 
> Jim
> 
> ... in an earlier email I suggested we added a comparison with existing
> protocols (RosettaNet, IOTP, AS1/AS2) ... as a separate work activity. I'm
> not sure we resolved this. I think we need to add it as a separate activity
> since:
> 1. We need to do this work to meet our requirements
> 2. It is a significant piece of work, so I don't want us to forget it
> 
> David
> 
> -----Original Message-----
> From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
> Sent: Monday, August 21, 2000 10:11 AM
> To: ebxml transport
> Subject: RE: TRP Work Plan - Version 17 Aug 00
> 
> 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

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903


[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