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: Manifest Element - Where located? - 2


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
> > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> 
> ------------------------------------------------------------------
> 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;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard


[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