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

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:20:52 UTC