Re: Manifest Element - Where located?

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

It also points out that a warning might be better reported
via some mechanism OTHER than a SOAP:Fault.

Cheers,

Chris

"Burdett, David" wrote:
> 
> >>> I am assuming that you mean an intermediate ack, <<<
> I am, in the the last version of reliable messaging discussed in Vancouver
> we changed "Intemediate Ack" to just "Ack" - this was your idea Chris.
> 
> >>>... but this begs the question again, what puspose deos the ack serve if
> it is reporting a delivery failure?<<<
> 
> The short answer is that it staisfying a request that the Acknowledgement
> element be returned.
> 
> Really though, I was merely reflecting what it has said in the spec for over
> two months now in the section that decribes "Combining Principal ebXML
> elements" which says, and I quote ...
> 
> "If the highestSeverity attribute on the ErrorList is set to Warning, then
> this [errorList] element MAY be present with any other element.
> 
> If the highestSeverity attribute on the ErrorList is set to Error, then this
> element MUST NOT be present with the following:
> .       a Manifest element
> .       an ApplicationHeaders element
> .       a StatusData element"
> 
> Obviously ApplicationHeaders element now has to go.
> 
> David
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Monday, February 26, 2001 2:40 PM
> To: Burdett, David
> Cc: 'david@drummondgroup.com'; ebxml-transport@lists.ebxml.org
> 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