RE: Proposal for issue 170: referencing missing data

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

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: 19 January 2002 04:29
> To: xml-dist-app@w3.org
> Subject: Proposal for issue 170: referencing missing data
> 
> 
>  Hello all. 8-)
>  This is the updated proposal for issue 170.
>  At the last WG telcon we decided to switch to IDREFs for 
> referencing inside SOAP Encoding data. This implies a more closed 
> graph point of view.
>  The issue 170 is about what is to happen when a deserializer 
> hits a broken link.
>  We don't expect to carry open-ended graphs now (as far as SOAP
> Encoding referencing is concerned, since any links can be carried
> inside the data) therefore to encounter one is a clear indication 
> of an error.
>  We discussed the distinction between MUST/SHOULD/MAY fault. The
> discussion was taken out of the context in which the MUST
> originally appeared, and I'll try to reintroduce the context here
> because it might well satisfy the strongness of MUST.
>  The proposed text:
> 
>  "When SOAP Encoding data is being dereferenced and a reference 
> to a missing ID is found, the application MUST generate a fault 
> with faultcode env:Sender and subcode enc:MissingID."
> 
>  I think that the first part of the sentence above is enough to 
> soften the MUST so that applications are not required to check 
> beforehand that every part of the data is actually complete.
>  Also I think that this sort of frames the ordering of faulting.
> 
>  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.
>  Actually, I can see sometimes handling MU and EncodingUnknown 
> faults as part of some kind of handshake (let's try what the 
> server can do), but I cannot imagine using a MissingID fault 
> for legitimate purposes because I don't think intermediaries 
> should be allowed to strip some data without the knowledge of the 
> data.
>  Why would a server choose to _not_ report this fault? (In other
> words, why could SHOULD or even MAY be more appropriate?) Let's 
> remember, this happens in case the server actually deserializes 
> the data so we can assume the data is necessary for continued 
> operation.
>  Best regards,
> 
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
> 
> 
>

Received on Monday, 21 January 2002 08:46:12 UTC