RE: Manifest Element - Where located? - 2

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Replies imbedded in text.

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Tuesday, February 27, 2001 2:38 PM
To: Miller, Robert (GXS)
Cc: ebXML Transport Mailing List
Subject: Re: Manifest Element - Where located? - 2


"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? 

   MILR: I've addressed it in other submissions. Among the reasons I've
given, MIME outside SOAP becomes required in cases where it need not be
required.

> 
> 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)

   MILR: By putting ALL of the ebXML header information back in the header
(where we had it before SOAP came along), 
we continue to separate the business content (payload) from the header
content.  And the ebXML header information is in SOAP-ENV:Header (where SOAP
says it belongs).


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)

   MILR:  I STRONGLY favor allowing the business information to be whereever
the TPA instructs to put it, except of course in the SOAP-ENV:Header.
Therefore I VERY STRONGLY disfavor any attempt to require that the data be
placed in an attachment. Even to the extent that I would support requiring
compliant XML business data to be placed in the SOAP-ENV:Body over it being
placed in an attachment.  At least tehn I am not always saddled with a MIME
envelope when it is clearly not technically desirable to use a MIME
envelope.  SOAP 1.1 and many ebXML based applications can function quite
well with just a SOAP 1.1 envelope.



> 
> 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?

MILR: Per another reply, 'ebXML message' is meant to be an ebXML conformant
message rendered in XML syntax.  As I affirm above, I do support putting
ebXML messages in attachments if that's what the TP's wish to do.  But if
you try to force them there, I'll try to force them elsewhere in self
defense.

> 
> 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