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

Hi Jacek,

> 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.

So how to bring this one to a conclusion without unravelling too much?

I think that with respect to the most recent proposal to resolve this issue
[1]:

"The value of the href attribute is of type anyURI. If the semantics of
the encoded data requires that an href value if dereferenced and the
SOAP Node is incapable for whatever reason to dereference the URI, a
SOAP Fault MUST be generated with the faultcode enc:BadReference."

With subsequent discussion it seems that there are three variants to this
proposal, the original and with MAY or SHOULD substituted for MUST.

We presumably have to find out whether there is at least one variant
everyone could live with. Probably something for when this comes up on the
next telcon.

Regards

Stuart


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: 07 January 2002 17:17
> To: Williams, Stuart
> Cc: Henrik Frystyk Nielsen; noah_mendelsohn@us.ibm.com;
> xml-dist-app@w3.org
> Subject: 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 Tuesday, 8 January 2002 06:11:38 UTC