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 Friday, 18 January 2002 23:35:19 UTC