RE: SOAP Proposal Documents

[Rik Drummond <rvd2@worldnet.att.net>]

we must follow the soap spec even if it is wrong to be soap compliant... so
that is that.... best regards, rik

-----Original Message-----
From: Marc Breissinger [mailto:marcb@webmethods.com]
Sent: Friday, February 23, 2001 1:10 PM
To: Miller, Robert (GXS); ebXML Transport (E-mail)
Subject: RE: SOAP Proposal Documents


All,

While I agree with Dick's comments on the use of HTTP 500 as a layering
violation, I disagree with the idea that we can choose not to follow the
SOAP specification in this instance b/c we don't agree with it.  If we are
adopting SOAP, we must adopt it, warts and all.  If we don't like it, we
should work through W3C XP to change the HTTP binding behavior in XP and
adopt that when it is ready.

marc

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Thursday, February 22, 2001 10:13 AM
To: ebXML Transport (E-mail)
Subject: RE: SOAP Proposal Documents


Good people,

I support Dick Brook's concern regarding 'layering violation'.  And I also
agree we must have a clear technical understanding of the process by which
SOAP returns error results to the invoking service interface.

Cheers,
         Bob

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Wednesday, February 21, 2001 9:17 PM
To: Marc Breissinger; david@drummondgroup.com; ebXML Transport (E-mail)
Subject: RE: SOAP Proposal Documents


Marc,

>As previously stated, a careful reading of the specification says that the
><detail> sub-element is intended for information related only to SOAP Body
>error.  However, the spec also explicitly allows for extensions at the
>SOAP-ENV:Fault sub-element level (i.e., a sibling of the <detail> element)
>without restriction on the content of the error information.  Therefore,
>we were able to add an ebXML namespace qualified element (the ErrorList)
>within the SOAP Fault element, satisfying both goals of keeping the ebXML
>errors together and placing them within the SOAP Fault element.

Clearly one can see how an <ErrorList> element can be inserted as an
immediate child node
of SOAP-ENV:Fault. However, it's not quite as clear how the ebXML errors
reported in
ErrorList relate to other elements of a SOAP-ENV:Fault. For example,
what values are assigned to the SOAP-ENV:Fault sub-elements of faultcode and
faultstring? Both MUST be present according to section 4.4 of the SOAP spec.

I see a few options:

1. Assign the highest error reported from the list of Errors in ErrorList to
faultcode
   and faultstring (using correlating elements).

2. Define a single value for faultcode and faultstring to identify all ebXML
related errors,
   (e.g. <faultcode>ebXML.Error</faultcode>, <faultstring>An ebXML error has
occurred</faultstring>

3. Use faultcodes found in the SOAP spec to report ebXML errors (e.g.
"Client", "Server").

There are variations of the above, which I won't bother to explore here.

My interpretation of the SOAP spec is that faultcode and faultstring are
"singletons". This is
what I was referring to when I said SOAP-ENV:Fault lacked support for an
"enumerated list of errors".
IMO, SOAP-ENV:Fault was designed to report on a single error.

I'm really not questioning ones ability to insert an ErrorList element as a
child to SOAP-ENV:Fault, that
appears elementary. However, the more interesting question, IMO, is "What do
SOAP processors do when a SOAP:Fault is received?"

Will a SOAP processor provide an API to access an ErrorList element located
in the SOAP-ENV:Fault sub-tree?
Does a SOAP processor "pass thru" the entire sub-tree of SOAP-Fault to a
higher level for processing? These
are some of the detailed questions we must have answers to before I'll feel
comfortable "embedding" ebXML errors
into what I believe is a "lower level" data structure.

>In other words, if the SOAP processor (in our case, the envelope processor)
>has an error, it must return in the HTTP response.  It should never get to
>the ebXML processor to have any other kind of error, so why do we care?  I
>would think we would just follow the SOAP HTTP binding in that case.

I should have been clearer in my previous e-mail. I'm raising the issue of
whether or not ebXML errors reported in a SOAP-Fault should also follow the
HTTP binding recommendations from the SOAP spec and report errors in a HTTP
500.
I personally believe application level errors should be reported in a HTTP
200
and leave HTTP 500 for true HTTP errors. A number of people on the SOAP list
expressed concern
over the use of HTTP error codes (500) for reporting SOAP errors.

I'm simply stating that ebXML specifications must be clear on the use of 500
or 200 to report ebXML
errors. I'm assuming you are comfortable using 500, in accordance with the
SOAP spec. I confess
I'm not comfortable with this, it seems like a "layering violation" to me.
Can I live with us using
HTTP 500, of course.

We also need to indicate that ebXML errors can arrive in a HTTP POST. This
concept doesn't exist
in SOAP, it appears SOAP-ENV:Fault are only delivered in a HTTP response.


It appears the issue with reporting header errors has been resolved.

Lastly, I don't have the latest spec with all the edits incorporating SOAP.
Could you please send
the latest copy to me, thanks.

Dick Brooks
http://www.8760.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