RE: SOAP Proposal Documents

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

good discussion, but here is my take on this. marc if you do not agree call
me and we can discuss it on the phone since it seems to be just you and dick
discussing this... dick call me too if you wish after you see what i have to
say.

the entire discussion is based on making ebxml as compliant and
interoperable with soap processors as possible.

put ebxml errors in the envel-body of soap and not in the fault area. this
means that that we can garentee that the soap processors will not trash
ebxml errors but pass them up the stack to ebxml code. if we put them in the
fault area it means that is some cases soap processors will trash our
errors.... so i strongly suggest that we put the ebxml errors in the soap
body of the soap envelop.....

my number is 8178 239 1320.... if you disagree marc...... best regards, rik




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