RE: trp and soap

[Dick Brooks <dick@8760.com>]

Phil,

We assigned all the immediate child elements of the ebXMLheader (Header,
Manifest, etc.) to their "proper" place in the SOAP Envelope (Header, Body).
The ebXML <Manifest> has been placed in the <SOAP-ENV:Body>.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Phil Zimmerman [mailto:pzimmer@bea.com]
> Sent: Tuesday, February 20, 2001 11:11 AM
> To: Rik Drummond
> Cc: ebXML Transport (E-mail)
> Subject: Re: trp and soap
>
>
> Rik,
>
> Am I correct in assuming (carefully using this term ;)) that the
> ebXMLHeader will still
> contain the manifest which is missing in SOAP with attachments?
>
> -Phil
>
> Rik Drummond wrote:
>
> >  As you are aware, ebXML transport, routing and packaging was
> approached by
> > the workgroup in w3c who would become the xml protocol
> workgroup in may 2000
> > to discuss convergence between soap and ebXML transport.
> Soon afterwards
> > ebXML assigned dick brooks of 8760 to be the official trp
> representative on
> > the xp workgroup. Several intellectual property issues existed with soap
> > 1.0, 1.1 and soap with attachments that precluded trp from using soap.
> > Additionally while soap 1.0 was not usable for ebXML trp
> because it lacked
> > the ability to move any type of digital data soap 1.1 and soap with
> > attachment added capabilities very technically similar to ebXML
> trp message
> > structure in the subsequent versions. During our Vancouver
> meeting a highly
> > qualified team representing soap and trp evaluated the
> possibilities of trp
> > using soap. The investigation showed that to implement trp in soap would
> > require no logic changes or changes to the meaning or the
> existing trp data
> > elements in the header  except in one possible instance the
> handling of
> > error status.
> >
> > While this is somewhat of a dangerous course this late in the
> development of
> > the specification we felt the benefit far outweigh the dangers. Benefits
> > such as fewer standards to support by vendors, more investment
> by software
> > vendors in ebXML mhs because of the alignment of soap and mhs and less
> > market confusion and it will have a better change of becoming the vendor
> > neutral inter-exchange, SME and le transport of choice.
> >
> > We presented our conclusions to the ebXML steering group on
> Tuesday and said
> > we could technically include soap in the ebXML trp
> specification under the
> > following conditions:
> > -       we were given an additional 4 week to complete the spec
> until march 19
> > -       we were allocated key full time resources from our team
> to the project
> > until march 19
> > -       we were allocated key soap experts until march 19
> > -       all intellectual property issues were resolved by feb 16
> > -       we would be allowed to not address any outstanding
> technical comments
> >         made on the existing version .93 message handling
> services specification 
> > they
> >         would have to be resubmitted against the next version
> after soap was
> > included  if they still existed
> > -       Finally, even though this is a major cosmetic change to
> the spec, not a
> >         logic or header element change, we would only be
> required to go through one
> >         review cycle before plenary approval.
> > -       The trp team approved the effort
> >
> > As of feburary 16, 2001 all condition have been met.
> >
> > We are now diverting all resources to aligning soap and ebXML
> packaging for
> > final approval of this modified spec in Vienna
> >
> > With this in mind and to accomplish these aggressive goals I
> suggest a few
> > rules on how we manage the spec in our work group.
> > -       we will not address any not hitherto include
> functionality in this spec
> > -       we will not clutter the email list with topics which do
> not directly
> > pertain to accomplish this goal
> > -       Ian jones has been assigned by the trp group as proctor
> to curtail any
> > discussions not following the above two points
> >
> > The work effort will progress as follows:
> > -       three or four expert form trp and soap will convert the spec to
> > incorporate soap 1.1 and soap with attachments
> > -       once that has happened we will assign two readers to
> look for technical
> > issues or introduced errors
> > -       it will be given to our trp editing team for editing
> > -       it will be released to the list for review and comments
> > -       final edits will be incorporated from list discussion
> > -       the trp group will vote on whether or not to release it
> for ebXML wide
> > review
> > -       submitted to qr team on march 19 or earlier
> > -       release for ebXML wide review soon after
> > -       incorporate comments from review
> > -       plenary vote.
> >
> > To facilitate the specification passing qr team review I have
> asked the qr
> > formally assign a person to continuously trace progress over
> the weeks to
> > ensure that any issues that they have, and we can address, or addressed
> > before qr review.
> >
> > If you have questions please send me email via the trp list serv.
> >
> > Best regards, rik
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
>
>