Re: Manifest Element - Where located? - 2

[Prasad Yendluri <pyendluri@webmethods.com>]

I  vote for the deterministic approach as well. I.e. no application payload in
SOAP-Env:Body but only in the MIME part(s) that follow(s) the SOAP envelope part.
Also should it be "MUST" instead of SHOULD below? :)

On the second issue that Marc brought up, I would vote for keeping it flat. That
is all payload parts appear as separate MIME parts visible at the top
(multipart/related) level. No need to embedded in another wrapper. Everything that
follows the first part is the payload(s).

Speaking of multiple payloads, we now have the option of returning multiple
responses (e.g. batch/sync case) together. As a general case, are we satisfied
that *one* instance of  eb:MessageHeader would serve to cover all these responses
(with Manifest in Body identifying the payload parts)?

Regards, Prasad

christopher ferris wrote:

> Marc,
>
> I don't mind picking one (I believe that we did select
> the serial MIME part packaging versus the two-part
> ebXML packaging model in Vancouver) and I don't mind
> saying that the SOAP-ENV:Body SHOULD be exclusively
> used for ebXML TR&P content, leaving the business
> payload content to separate MIME parts.
>
> It is a bit difficult to enforce, but so be it.
>
> Cheers,
>
> Chris
>
> Marc Breissinger wrote:
> >
> > I'm going to weigh in on Ian's side on this one.  I believe that we should
> > "keep it simple" by spcifying no application payload be allowed in the SOAP
> > Body.  That's a perfectly legal thing to do as Rich Salz noted.  If we
> > wanted header and payload in the same XML document, why was there no "body"
> > element in the original ebXML message structure?  Answer: we didn't want
> > them in the same XML document for good reasons.
> >
> > Chris, you wrote:
> >
> > > ... the "payload" is the perview of the designer of the
> > > business process (and the message content) ...
> >
> > and I wholeheartedly agree.  However, while the payload content is the
> > purview of the BP designer, the way in which that content is packaged into
> > the ebXML message is *not*.  That is our domain and we should strive to be
> > as explicit and as deterministic as possible.  Leaving packaging decisions
> > up to individual business domain experts can only lead to an increase in
> > complexity and a corresponding decrease in interoperability.
> >
> > This same issue arises with the handling of multiple payloads within a
> > single message.  Should we specify that there can be only one payload part
> > that can contain many fully qualified ebXML messages (as we used to) or do
> > we move to the flat model shown in SOAP w/Attachments examples?  Or do we
> > allow both?  Again, I believe we need to be explicit here and pick one and
> > force the business domain experts to follow a single packaging scheme.  In
> > this particular case, I don't care which we pick, but IMHO believe we should
> > only pick *one*.
> >
> > marc
> >
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Monday, February 26, 2001 2:07 PM
> > To: Burdett, David
> > Cc: ian.c.jones@bt.com; ebxml-transport@lists.ebxml.org
> > Subject: Re: Manifest Element - Where located? - 2
> >
> > This is already provided for as the Reference xlink:href is an URI
> > value which includes the xpath/xpointer subset of URI values.
> >
> > Cheers,
> >
> > Chris
> >
> > "Burdett, David" wrote:
> > >
> > > I agree with Chris. We can't stop people putting payload in the body. In
> > > fact, I think we should explicity allow it as then the TRP specs could be
> > > used more easily by the SOAP community who put payloads in the SOAP body.
> > >
> > > So, all we need to do is allow the manifest to reference an element in an
> > > XML document using XPATH and I think we would be OK.
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > Sent: Monday, February 26, 2001 10:22 AM
> > > To: ian.c.jones@bt.com
> > > Cc: ebxml-transport@lists.ebxml.org
> > > Subject: Re: Manifest Element - Where located? - 2
> > >
> > > Ian,
> > >
> > > Since the "payload" is the perview of the designer of the
> > > business process (and the message content), and since we are
> > > complying explicitly with the SOAP1.1 and SOAP with Attachments
> > > specifications, I don't see how we can preclude any payload
> > > content from the SOAP-ENV:Body element.
> > >
> > > IN any event, as long as the payload content is referenced
> > > in the Manifest (as it is intended) then the issue
> > > is moot (IMHO) because it makes no difference as to what and where
> > > the references resolve.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > ian.c.jones@bt.com wrote:
> > > >
> > > > All,
> > > >
> > > >         Here is the corrected version of the text I just e-mailed.  Hit
> > > send
> > > > before running the spell check sorry!
> > > >
> > > >         I am concerned about having "real" payload in the body as we
> > then
> > > > have inconsistent handling of payloads.  So, if you have one XML message
> > > you
> > > > COULD put it in the body provided you do not need any special characters
> > > > etc. BUT if you need special characters or more than one message what do
> > > you
> > > > do? Put them all in attachments, put the first in the body, etc.  IMHO
> > we
> > > > should Keep It Simple, all payloads in the attachments as they are not
> > for
> > > > the MSH it just needs to pass them on and leave all the MESH "stuff" in
> > > the
> > > > SOAP header and body as needed.
> > > >
> > > > Ian Jones
> > > >
> > > > Ian Jones
> > > > Email: ian.c.jones@bt.com
> > > >