Doug,
I
guess I read this differently. It doesn't make any sense to me since if it is
not clearly defined in the spec. It seems like if the intension is for the
other MSH to understand the returned error then it must be a ebxml message.
Attaching an error list to a SOAPFault without defining it in a "extended"
schema or at least recommend it in the spec seems like it will never be used.
ErrorList messages are defined and I feel they should be used. And I have to ask
again, if you can parse the message...why not send a ErrorList verse a
SOAPFault?
Cliff
-----Original Message-----
From:
Doug Bunting [mailto:]
Sent: Monday, November 19,
2001 2:15 PM
To:
Subject: Re:
[ebxml-msg] First editorial issues on 1.09
Cliff,
Sure. It's not required by this quote but it is
allowed (starting at line 1231):
It is
possible for the ebXML MSH software to cause a SOAP fault to be generated
and returned to the sender of a SOAP
Message. In this event, the
returned message MUST conform to the [SOAP] specification processing
guidelines for SOAP Faults.
An ebXML SOAP Message that reports an error
that has a highestSeverity of Warning SHALL NOT be reported or
returned as a SOAP Fault.
thanx,
doug
----- Original Message -----
From: Cliff Collins
To: Doug Bunting
Sent: Monday, 19 November 2001 14:13
Subject: RE: [ebxml-msg] First editorial issues on
1.09
Could you clip the section of text in 4.2 that you
think says send a error list with a soap fault?
-----Original Message-----
From: Doug Bunting
[mailto:]
Sent: Monday, November 19, 2001 1:59
PM
To: ebXML Msg
Subject: Re: [ebxml-msg] First
editorial issues on 1.09
Cliff,
I'd agree except that the current document describes
sending an ErrorList with highestSeverity="Error" together with a SOAP Fault
already (see section 4.2). The wording suggested below doesn't change
the contents of a SOAP Fault element or when it might be generated, just
recommends additional information (other SOAP extensions) in the overall
SOAP message.
I wasn't aware SOAP errors must be returned the
synchronous channel in the HTTP binding. If that's the case, this will
be less of an issue. Not sure it does any harm...
thanx,
doug
----- Original Message -----
From: Cliff
Collins
To: ebXML Msg
Sent: Monday, 19 November 2001 13:47
Subject: RE: [ebxml-msg] First editorial issues on
1.09
I
don't think there should be any changes to what a SOAPFault contains. If the
received message was parsed so that the receiving MSH can get the
MessageHeader, then it should use "ErrorList" to send back an error.
SOAPFault should be used for messages that can't be understood at all from a
MSH. IMO this means a async message can get a SOAPFault returned in the same
connection. If the sending MSH is not listening for returned Faults
than it gets no error message.
Cliff
-----Original Message-----
From: David Fischer
[mailto:]
Sent: Monday, November 19, 2001
1:28 PM
To: Doug Bunting; ebXML Msg
Subject: RE:
[ebxml-msg] First editorial issues on 1.09
<<comments
in-line>>
-----Original Message-----
From: Doug Bunting
[mailto:]
Sent: Monday, November 19, 2001
2:56 PM
To: ebXML Msg
Subject: [ebxml-msg] First
editorial issues on 1.09
David,
In a quick read of 1.09, I've noticed a few things we
could get started on resolving. Some are rather picky
(sorry).
The text in section 1.3 has not moved into Part
1. This is not introductory material but the first plank in the
standard we're defining. During the meeting last week, we
agreed (after little discussion) to move this material later in the
document. This should primarily be a renumbering of the section
to a new section 2 just after the Part 1. title.
<< Yes, you and I
discussed this and I agreed with you. I didn't remember
discussing this with the group. Anyone have any objections to
moving 1.3 to 2.1? >>
The new text does not resolve issues Arvola raised in
the week prior to our meeting with regards to the SOAP Fault element
and revolving which message was in error. I suggested (in http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00211.html)
"Note: A SOAP Fault element on its own may not
provide the requesting MSH with the context necessary to identify
the message in error. An MSH returning a SOAP Fault should
include ebXML MessageHeader and ErrorList SOAP extensions in the
same SOAP message. This would be especially useful when the
error is returned asynchronously."
but don't see it in the document.
<< I thought we decided against this since
the SOAP Fault may be a situation where the MessageHeader itself is
corrupt or unreadable or undefined or violates the schema
etc.?? >>
Please search the document for the word "that".
Almost all instances (especially in the phrase "that is" which can be
globally deleted with allowance for commas) can be removed.
<<Yes, grammatically,
you are correct. I have not been willing to make
such global changes without direction. Anyone object?
>>
Most references to top level sections should refer to
a specific sub-section. For example, references to section 4
occur when the issue is security, errors, some specific element, et
cetera.
<<Please be
specific.>>
It's up to you whether the document uses a comma
prior to "and" and "or" but the current document is not consistent in
this respect. It doesn't appear commas are added for "more
complex" sentences for example.
<<Again, you are
correct.>>
A bit more on errors should be primarily
editorial: The current text is inconsistent with respect to what error
should occur under different situations. For example, a conflict
with the CPA is handled using an Inconsistent Error but the
description of Inconsistent doesn't cover anything except elements and
attributes in the document at hand. Specific inconsistencies
(such as duplicateElimination in 7.4.1) are sometimes handled using a
NotSupported error.
<<This is not editorial but I will go ahead
and change 7.4.1. This is a problem any time we add a new
flag/feature. It is appropriate to use NotSupported until CPA adds
it to their spec at which time we have to change to Inconsistent.
This causes a continuous cascading problem. I like your solution to
allow either error. Where/how shall we say
this?>>
Perhaps this last point isn't an editorial
issue? We're requiring a specific and inconsistent processing
order at the receiving MSH. Most issues around features supported
by the MSH are captured in the CPA. Whenever we see "NotSupported"
meaning a feature was requested the recipient couldn't handle, an
"Inconsistent" error would be just as appropriate. At the moment,
the order is 1) check support for duplicateElimination and a few other
things 2) check CPA 3) recheck CPA against requested features (even if
they're entirely unsupported).
It's up to an enterprise how free they want to be with
their supported feature list. A worried company with a public
ebXML service might report everything as inconsistent (with a default
CPA they've published to the world). We shouldn't preclude that
mode of operation. I'd recommend allowing either error in all
situations. The easiest way to do that would be to use
"Inconsistent" throughout the document but include explanatory material
in 4.2 stating that many inconsistencies with a CPA ("as described
elsewhere in this document") may also result in a NotSupported
error.
thanx,
doug
