RE: Issue #170: "Referencing Data missing from the message"

 Stuart,
 as always your message has been very insightful, let me add some 
remarks.

                   Jacek Kopecky

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



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

 > Hi Jacek,
 > 
 > >  Stuart,
 > >  you and others talk about the sender relying (or not) on getting
 > > a fault in case a reference in the graph is unreachable. I don't
 > > think that the sender cares at all because if it did it would
 > > assume it _can_produce_ an unreachable reference. Why should it
 > > do so?
 > 
 > Well... you seem very concerned that a fault always be
 > 'generated'. Presumably that strong requirement to generate
 > a fault arises from a need for that fault to have some
 > effect.
 > 
 > [snip]
 > 
 > However, you say... "I don't think that the sender cares at
 > all..." which leaves me wondering what entity you think
 > actually does care about the fate of any fault generated
 > due to references to missing data and why you feel so
 > strongly that this is a MUST fault rather than a MAY fault.

 What I meant by not caring is not that the sender upon receival 
of such a fault would just drop it and continue as if it got a 
successful response. I think that upon receival of such a fault 
(just like with other faults mentioned below) I think the sender 
should crash and burn violently so that the operator knows 
something's wrong. 8-)
 Of course in some circumstances, with the MustUnderstand and
VersionMismatch faults the sender may be trying different
approaches to a service and therefore these faults might be a
part of the normal life of that sender, but usually they signal
bugs somewhere.

 > >  In case we allow external references, the external reference may
 > > be unreachable at the time when (or from the node where) it's
 > > being dereferenced. But you yourself demonstrate that you can
 > > easily imagine us using IDREFs for references.
 > 
 > I also acknowledged that there are others that feel
 > strongly in favour of URIRefs and that I would like to
 > better understand why they feel so strongly on the matter.

I may be wrong, but I think that the proponents of URIRefs are 
attracted by the apparent simplicity of the syntax, forgetting 
the complexities of implementation and handling.

 > >  In case we use IDREFs, missing data either mean a problem in the
 > > sender (if it generates a broken IDREF) or it can be that an
 > > intermediary stripped out a part of the message.
 > >  In the latter case, as I wrote before, I think that the
 > > intermediary better understand the data and fill NULLs (instead
 > > of references) at the appropriate places so that no link remains
 > > broken.
 > 
 > If an intermediary is broken in this way... what behaviour would you expect
 > of it upon receipt of the proposed fault? Take itself out of service and
 > phone for an upgrade? ;-) [snip]

 If it's capable of doing so, it's exactly what I would expect.  
8-) No, seriously, I believe this fault, with IDREFs,
signifies serious breakage somewhere and primarily the operator
should note that, not the software receiving the fault.

 > >  In any case, I think a broken IDREF is a critical error
 > > condition, something that never occurs in correct applications.
 > > Therefore I suggest a MUST, just like MustUnderstand and
 > > DTDNotSupported and VersionMismatch faults.
 > 
 > Well... maybe there are some issues with MUST fault on some of these aswell!
 > 
 > "MUST fault" to me implies that we have a pretty clear idea of what effect
 > the fault is intented to have and at some system level we will be relying on
 > fault generation in such circumstances otherwise why MUST? MUST gives a
 > guarantee that someone/thing will come to rely on, if a MUST guarantees
 > nothing, it has no business being a MUST.

 I think I see where you're going and it seems reasonable. If we
lessen the MUSTs on the three faults above, it will make sense to
apply the same to the BrokenReference fault. I still like SHOULD
as opposed to MAY, though.

 > > This case
 > > suggests that if we mandate a fault in case of a broken reference
 > > we remove the possibility of such optimization.
 > 
 > >  On the other hand, is a fault mandated for a case where there
 > > are two env:Body elements in a message? If so, we disallow
 > > streaming as well because before we can start processing the
 > > Body, we must be sure that there is no other Body. Same case for
 > > non-well-formed SOAP messages, too.
 > >  So if we expect a fault for two-Bodied messages, we should as
 > > well expect a fault for broken references, IMHO. There is no
 > > wording about the former expectation in the spec, though, but I
 > > think that faulting (or other kind of failing) is implied when a
 > > SOAP node receives something that is not a SOAP message (like the
 > > two Bodies case or a non-well-formed document case).
 > 
 > Not sure a fault arises in all these cases. Some binding specific means to
 > report the failure (eg HTTP status codes - 400 Bad Request) may also be
 > used.

True, my reasoning was depending on the assumption that a SOAP 
fault is expected in such cases.

 > [snip]
 > 
 > I also think, that despite the increasing length of this thread, the thing
 > that closes this issue is the choice of MUST or MAY with respect to the
 > generation  of a fault when referenced data is missing from a message.

But we should be consistent with the rest of the spec, see below.

 > My preference remains MAY... and I am prepared to believe that we may have
 > been over zealous with MUSTs elsewhere in the (draft) spec.

My preference is 'the same as the other MUSTs on VersionMismatch,
MustUnderstand etc.'. I do see why we could want to reduce those
to SHOULDs, too.

Jacek

Received on Monday, 7 January 2002 12:17:05 UTC