Re: Issue 292: Analysis and proposal

I understand that this needs serious thought, but I think it's a mistake 
to do this "by cases", with one rule for bad args vs. ID faults, another 
rule for other pairs, etc.  We can easily get into a spec that grows in a 
combinatorial way.  Furthermore, it's trivial to create situations in 
which there are multiple MUST faults for a given message.  I think we need 
an encompassing rule, that covers the whole system, that says what to do 
when a given message would or could, per the spec, result in multiple 
faults.   I think the rule I've proposed is the sensible one.  Otherwise, 
in all your processing, you have to keep going even after you know you're 
going to fault.  You have to keep going through other headers and other 
application processing to verify that you don't later discover a fault 
that is somehow more important.  I think that's a really unfortunate 
constraint to put on processors.

Accordingly, I think the best rule is:  you can build your implementations 
with any structure and order of processing you want, as long as it does 
not violate the rules for correct processing of a correct message, or the 
chapter 2 rules for things like mU checking.  I'm not sure I'd even force 
an envelope well-formedness check.  What if you've build a streaming 
processor, so you deal with all the headers before you even read in the 
(potentially very large) body.  Even a well formed-ness check on the 
envelope requires checking the spelling of </Body> and </Envelope>.  I 
really, really think you want to allow the processor to just fault when it 
finds something wrong in the header, even if it's something as seemingly 
secondary as a duplicate id in an encoding.   It seems like a great 
burden, once you already know you're faulting, to run the whole rest of 
your processing logic against some prioritized list of faults. 
Furthermore, you need to be very careful if you do such additional 
processing that it has no side effects, as you probably will want to do 
nothing now that you know the message is in error.

So, I remain very skeptical that we either want to (a) have very many 
special-case rules about pairs of faults and their priority or (b) with 
the exception of things like mU faults, for which order of detection is 
truly fundamental to the processing model, I think we should allow great 
lattitude for processors to report any of the potentially several faults 
that might be found in a message.  In any case, messages can have more 
than one MUST fault, and if anyone is interpreting that as "must return 
all of them" I think we need a clarification to the contrary.  Having 
gotten that far, I think it's not disconcerting at all to say:  actually 
you can return any reason you like for rejecting a message, whether it 
rated a MUST or not.

Does this make sense?

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







Jacek Kopecky <jacek@systinet.com>
09/08/2002 08:12 AM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     XMLP Dist App <xml-dist-app@w3.org>
        Subject:        Re: Issue 292:  Analysis and proposal


 Noah,
 I'm a bit nervous about the part I've left of your message below.
Please see my comments.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


On Sat, 2002-09-07 at 01:29, noah_mendelsohn@us.ibm.com wrote:
> 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.

If the spec says that if something happens a particular fault MUST be
generated, the above text contradicts the MUST. I think a reader of the
spec will expect BadArguments even in MissingID cases if the RPC
convention is used.

I agree that what I proposed would have effect on the implementations,
but (having implemented SOAP myself) I honestly think this effect does
not outweigh the seriousness of the contradiction above.

Now I think what you want to achieve can be achieved nevertheless, only
not as simply as you're proposing. RPC always uses SOAP Data Model,
therefore it can say in the RPC Faults section that if SOAP Data Model
encoding deserialization results in a fault, that fault MAY be generated
instead of any of the RPC faults, e.g. when efficiency concerns are
present. Either this, or relax the MUST to a SHOULD and the issue goes
away.

Hope my point is clear,

Jacek

Received on Monday, 9 September 2002 11:09:56 UTC