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

 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?
 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.
 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.
 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.
 As for lazy parsing, it is not common (in an explicit form) in
any RPC-like system that I know of. In a hidden form it is an
optimization which should not change the semantics. 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).
 If this does not prevent streaming, I think a MUST for faulting
in case of a broken reference does not prevent lazy parsing.
 Best regards,

                   Jacek Kopecky

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



On Fri, 4 Jan 2002, Williams, Stuart wrote:

 > Hi Jacek,
 >
 > > -----Original Message-----
 > > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > > Sent: 04 January 2002 16:35
 > > 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,
 > >  I was always thinking about the SOAP Encoding (as opposed to
 > > general linking mechanisms and dereferencing).
 > >  Your two issues are the right split of what was discussed here.
 > > The issue #170 is your b). The resolution to a) may affect our
 > > view of how b) should be resolved, though, I think.
 >
 > Yes...
 >
 > >  Anyway, since we are in the limited scope of defining the SOAP
 > > Encoding, you seem to tend to agree with the MUST fault, right?
 >
 > Well... I refrained from actually being explicit about that ;-).
 >
 > What caused me to pause was the piece of the discussion between you an Noah
 > on 'lazy' evaluation/deserialisation. In some circumstances, a lazy approach
 > may not attempt to 'visit' the missing part of the graph, in which case the
 > 'broken' reference may not be uncovered. Mandating a fault seems to force
 > that (early) checking be done regardless of the need to visit a given part
 > of the graph. OTOH, part of the graph is missing, it seems that the graph
 > then is ill-formed, so is it reasonable to even attempt to process any of
 > it?
 >
 > Given (from [1]) "A SOAP message MUST NOT impose any XML schema processing
 > (assessment and validation) requirement on the part of any receiving SOAP
 > node." its not clear to me that even if one were to chose IDREFs
 > representing graph edges one could rely on some level of XML validation to
 > pick up the missing links.
 >
 > So I find myself back on the fence. The "MUST fault" position suggests to me
 > the need for some 'graph validation' step either explicit or implicit (ie.
 > leveraged from XML IDREF validation). The "MAY fault" position suggests a
 > degree of tolerance of malformation in those cases where the malformation is
 > some sense (at the applications discretion) unimportant.
 >
 > MAY fault does give latitude to choose to always fault if that is what you
 > believe is the right thing to do, but does not allow a sender to rely on the
 > generation of a fault.
 >
 > >  As for scenarios for external references in serializations, we
 > > can imagine the graph contained an array of bytes where a JPEG
 > > image is stored. It might be useful to send this array as a
 > > reference to an external file. However, I don't think putting
 > > this functionality above core SOAP Encoding would really hurt
 > > anybody (except for some recoding, of course).
 >
 > In this circumstance (with an external file) I don't think that the image is
 > part of the graph at all. The reference is made from a graph node rather
 > than by a graph edge.
 >
 > ie.
 > 	<env:Body>
 > 		<app:myStruct>
 > 			...
 > 		      <app:picture xsi:type="anyURI">
 > 				http://www.example.org/aprettypicture.jpeg
 > 			</app:picture>
 > 			...
 > 		</app:myStruct>
 > 	</env:body>
 >
 > not
 > 	<env:Body>
 > 		<app:struct>
 > 			...
 > 		      <app:picture
 > href="http://www.example.org/aprettypicture.jpeg"/>
 > 			...
 > 		</app:struct>
 > 	</env:body>
 >
 >
 > >  In Systinet, we ourselves use attachments which in their current
 > > version depend on external hrefs, so I know what I'm talking
 > > about when I'm saying that removing external linking capabilities
 > > from SOAP Encoding would not really hurt because it can be done
 > > in a different, more layered and therefore cleaner way.
 > >  Btw, implementation of SOAP Encoding would be much simpler.
 > >  Best regards,
 > >
 > >                    Jacek Kopecky
 > >
 > >                    Senior Architect, Systinet (formerly Idoox)
 > >                    http://www.systinet.com/
 >
 >
 > Best regards
 >
 > Stuart
 >
 >
 >
 >
 > [1] http://www.w3.org/TR/soap12-part1/#reltoxml
 >

Received on Friday, 4 January 2002 12:57:01 UTC