Re: Manifest Element - Where located? - 2

[christopher ferris <chris.ferris@east.sun.com>]

"Miller, Robert (GXS)" wrote:
> 
> Good people,
> 
> Rik says keep it simple.  I agree.  I say simple is this:
> 
> 1) Put ALL of the ebXML header stuff in the SOAP-ENV:Header (where it
> belongs).
>         Some here, some there is NOT simple

What makes it not simple?

> 
> 2) Put the ebXML conformant XML message in the SOAP-ENV:Body.  If no such
> body is present for the message, the SOAP-ENV-Body is empty (or perhaps
> someday, not present.
>         ebXML messages are always in the same place.

As Marc cited, we had good reason to choose to separate the business
content (payload) from the header content. Specifically:
	- that it enabled separation of processing. The MSH doesn't
	need to, and in many cases shouldn't, parse the business content

	- the ability to separately encrypt (or not) header and
	payload (possibly, using different keys)

I disagree that the busines payload should always be in the SOAP-ENV:Body.
My point was that as long as the eb:Manifest was the first child element
of the SOAP-ENV:Body element, that it would be possible to have
business content follow as siblings as long as they are referenced
in the eb:Manifest. I have agreed with Marc and others that for 
consistency, we should REQUIRE that business payload NOT be contained
within the SOAP-ENV:Body element. Of course, we cannot (I don't believe)
REQUIRE that it always be passed by value. There MAY be valid business
cases where the payload content (or some attachment) might be
available via the web and we should not preclude this possibility.

(e.g. a LARGE attachment might be made available for FTP or HTTP
download from a web-accessible URL)

> 
> 3) If there are attachments, the attachments are not ebXML messages, they
> are just attachments.

This comment I don't understand. Why can't an attachment BE an ebXML
message? If I recall, OTA actually passes by value a previous
message as context for subsequent messages to parties that would not
have access to the previous message. Is this not a valid business
use case?

> 
> Cheers,
>         Bob
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard