Issue 292: Analysis and proposal

This is in fulfillment of an action item that I took at the recent f2f [1]
(sorry, the minutes have yet to be officially reviewed, so that's a members
only link) relating to issue 292 [2]:

"ACTION: Noah: Issue 292 -- propose a resolution that the processor may
elect to report any fault it
chooses (when multiple faults exist)

Before [3] and after the f2f [4, 5] there has been some discussion of the
issue on distApp, though the post f2f notes don't specifically mention the
f2f discussion.
In brief summary, issue 292 raises the question of what to do if two
particular errors relating to encoding occur at the same time.  These are
the errors that result in enc:MissingID ( a SHOULD fault) and
rpc:BadArguments  (a MUST fault).

I think it's fair to say that the opinion expressed by Martin Gudgin in [3]
advocates giving precedence to BadArguments, while Jacek Kopecky in [4]
suggests

"if other subcodes are available (e.g. MissingID if SOAP Encoding is used),
they SHOULD be subcodes to the BadArguments subcode".
Gudge replies in [5] essentially: 'yes, ok if you like, prefer my original,
but anything that avoids spelling out all combinations is OK'.

A Proposal in Fulfillment of my F2F Action
------------------------------------------

As noted above, none of these is consistent with my position as expressed
at the F2F, and which is mentioned in the Action item.  My feeling is that,
with the specific exception of mustUnderstand faults that are special in
the order of the processing model:  >>imposing any order on the detection
of multiple faults can seriously constrain ones ability to optimize the
processing of correct messages, or else results in lots of extra code which
has as its only purpose to go looking for additional errors once one has
been detected.<<

Let me try to be a bit clearer:  there is no question what to do with a
correct message.  We're dealing with a situation where a message is in
error for more than one reason.  I believe that I need the opportunity to
do the processing on correct messages in any order and using any techniques
I please, as long as I meet the rules of part 1 section 2.6 [6].  How I do
decoding, when I detect id reference problems, etc., should be completely
up to me.  So, I might build a deserializer that builds the decoded graph
before I even discover this is an rpc.    I should be able to send the
missing ID fault as soon as I encounter it.  To go on to a possibly
different layer of my software, figure out that we've got rpc, note the
BadArgument could be a real mess for me.  Your implementation might not
even try to deserialize the graph except on demand during processing of the
rpc.  Early in this rpc processing you detect the BadArgument.  Should you
really be required to do the rest of the deserialization just so you can
throw a fault consistent with mine?   I say "no".

Accordingly, I propose the following general rule:  >> if the processing of
SOAP headers and/or body blocks would result in more then one fault, the
processor has complete discretion as to which of those faults is in fact
return.<<  We call these possible faults the "potential faults".  The
following table gives the rules that determine whether faulting is
mandatory, and which of the several potential faults must be returned.  As
a key to the table, we compute a value called "Highest Requirement to
Fault" which is defined the most restrictive of MUST fault, SHOULD fault,
or MAY fault for any of the faults in question.

==============================================================================
Highest
Requirement        Must a Fault             If a fault is generated,
to Fault           Be Generated?            which one?
==============================================================================
MAY                NO                       Any one of the potential
faults.
SHOULD             NO (but encouraged)      Any one of the potential
faults.
MUST               YES                      Any one of the potential
faults.
==============================================================================

I know this seems a bit tricky, but it's really quite natural to implement,
and it does what one wants I think.  Specifically:  there's no way that one
of the faults was labeled MUST, but you didn't get any fault at all.  If
any fault was labeled "MUST", then you'll definitely get some fault.   For
the reason cited in the discussion above, the fault you get may or may not
be one of the MUST faults, as your implementation may hit a SHOULD or MAY
fault before it even notices that there would have been a MUST, but sooner
or later it will definitely fault.


Next Steps
----------

If this proposal meets with general agreement from the WG, I'll try and
draft specific text for review.  I don't think the above is quite clean
enough for the spec.  Thank you.

Noah

[1] http://www.w3.org/2000/xp/Group/2/08/f2f-minutes-day3.html
[2] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x292
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Aug/0065.html
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0003.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0020.html
[6] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 6 September 2002 19:21:43 UTC