RE: Proposal for issue 170: referencing missing data

 Stuart,
 when thinking about faulting, I don't think in terms of "does 
not doing this break interop?" but in terms of "is this an error? 
Always? Really, positively always?"
 And if the answer to my version of the question is "yes, yes, 
really, positively yes", I'd make generating a fault mandatory.
 So since I think a broken link in SOAP Encoding graph indicates 
an error, like, always, therefore I propose MUST. 
 Let's please not loose again the context in which the MUST is 
used - the words "when deserialization encounters a broken link" 
which are meant to refrain from mandating checking when the data 
is not in fact needed.
 The spec is IMHO very deliberately talking about generating and 
not reporting faults because SOAP is one-way in the core and only 
MEPs can specify the reporting of generated faults. In some cases 
the generated faults, even under MUST conditions, can be silently 
dropped to a black hole by a conforming processor.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Mon, 21 Jan 2002, Williams, Stuart wrote:

 > Hi Jacek,
 > 
 > >  There has been the question of what a SOAP fault is meant to 
 > > induce. My experience is that although in some cases there may be 
 > > ways to gracefully handle the situation, usually faults like 
 > > MustUnderstand, DataEncodingUnknown etc. are just reported 
 > > somewhere and the client quits. I think the same handling should 
 > > be expected on a MissingID fault.
 > 
 > I guess I should respond to that since I at least and one who asks what
 > impact the generation of a Fault is intended to have.
 > 
 > The problem I have with MUST applied to the generation of faults (and this
 > is broader than just MissingID faults) MUST should be reserved for things
 > that give rise to interoperability problems. If someone goes against a MUST
 > bad things happen. At present our language is very much around the
 > generation of faults and we say little about the reporting of faults.
 > 
 > So my question is, if someone fails to generate a fault in a given
 > circumstance, does that give rise to an interoperability problem? 
 > 
 > If the answer is YES, then MUST is appropriate. 
 > 
 > Bear in mind that in the case of a MissingID the senders (or intermediaries)
 > conformance to the encoding style is already in doubt... what we're
 > considering is the MUST on the generation of a MissingID fault.
 > 
 > If we are going to insist on MUST *generate* a fault, I would like to
 > understand how interoperability would suffer if we were to relax MUST to
 > SHOULD or MAY.
 > 
 > I think that we can ask that question with respect to all cases of fault
 > generation that we specify.
 > 
 > I hope this response at least explains why I am reluctant about MUST... I'd
 > like to understand what the interoperability concern is if MUST were relaxed
 > to SHOULD or MAY.
 > 
 > Regards
 > 
 > Stuart

Received on Monday, 21 January 2002 09:03:16 UTC