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?


A delivery failure combined with an acknowledgment?
I am assuming that you mean an intermediate ack, but this
begs the question again, what puspose deos the ack
serve if it is reporting a delivery failure?

Cheers,

Chris

"Burdett, David" wrote:
> 
> >>>If there is a fault, what purpose doe sthe ack serve? Indeed, it MAY have
> been the ack that caused the fault;-)<<<
> 
> True, but you can also get errors, for example a Delivery Failure that could
> be combined with an Acknowledgment.
> 
> I'm sure the sub-team will work out the best place for errors to go.
> 
> David
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Monday, February 26, 2001 11:11 AM
> To: Burdett, David
> Cc: 'david@drummondgroup.com'; ebxml-transport@lists.ebxml.org
> Subject: Re: Manifest Element - Where located?
> 
> If there is a fault, what purpose doe sthe ack serve? Indeed,
> it MAY have been the ack that caused the fault;-)
> 
> This goes to the argument that we've been having in the SOAP
> technical subteam that our error MAY be better served as an Header
> element rather than as a child element of SOAP:Fault.
> 
> Cheers,
> 
> Chris
> 
> "Burdett, David" wrote:
> >
> > >>>Is there any condition when the other header elements we have put in
> the
> > Body need to be present during a Fault?<<<
> >
> > Yes. You can put an acknowledgement element in the body if an
> "ackRequested"
> > was set to "true".
> >
> > David
> >
> > -----Original Message-----
> > From: David Fischer [mailto:david@drummondgroup.com]
> > Sent: Monday, February 26, 2001 8:59 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: RE: Manifest Element - Where located?
> >
> > Just a note...  MS has informed us that in a Fault condition, the ONLY
> > element permitted in the Body is SOAP-ENV:Fault.  Is there any condition
> > when the other header elements we have put in the Body need to be present
> > during a Fault?
> >
> > David Fischer
> > Drummond Group
> >
> > -----Original Message-----
> > From: Robert Fox [mailto:robertf@softshare.com]
> > Sent: Monday, February 26, 2001 10:40 AM
> > To: 'Miller, Robert (GXS)'; ebxml-transport@lists.ebxml.org
> > Subject: RE: Manifest Element - Where located?
> >
> > I disagree here... we had made the decision in Vancouver to put data in
> the
> > BODY, and routing type info in the header... it seemed like a nice logical
> > split that SOAP gives us that we didn't have before. The Manifest is a
> > logical representation of the payload, which is the "body" of the message.
> > So the manifest should go into the SOAP-ENV:BODY. Otherwise, we will
> ALWAYS
> > have an empty SOAP-ENV:BODY, (since it is required). The reworked
> placement
> > of the elements fell quite nicely into this updated structure.
> >
> > -----Original Message-----
> > From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
> > Sent: Monday, February 26, 2001 8:29 AM
> > To: ebxml-transport@lists.ebxml.org
> > Subject: Manifest Element - Where located?
> >
> > Hi All,
> >
> > I seem to recall that the Manifest element was to be placed in the
> > SOAP-ENV:Body.  IMO, it belongs in the SOAP-ENV:Header area.
> >
> > >From "SOAP Messages with Attachments"
> > http://msdn.microsoft.com/xml/general/soapattachspec.asp Introduction,
> last
> > two sentences of paragraph 2:
> >
> > "More rigorous semantics for message packages requires a new entity type.
> > Such a type can be built by extending the approach described here with a
> new
> > SOAP header entry which, for instance, may be used to provide a manifest
> of
> > the complete contents of the message package."
> >
> > Seems clear to me - put the Manifest in the SOAP-ENV:Header!
> >
> > Of course, within the ebXML payload, there may also be imbedded pointers
> to
> > message attachments.  The first example in "SOAP Messages with
> Attachments"
> > gives one such example for an auto claim form application.  Such
> > 'application' references are of course unrelated to the ebXML Manifest
> > references.
> >
> > FYI, I'm not convinced that any part of the pre=SOAP ebXML header should
> > migrate to the SOAP-ENV:Body.  IMO, all of the ebXML Header stuff should
> > resdie in the SOAP-ENV:Header.
> >
> > 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
> >
> > ------------------------------------------------------------------
> > 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
> 
> ------------------------------------------------------------------
> 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