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

Hi Jacek,

Dare I ask whether there are two issues here?

 a) The way in which references are made (URIrefs, IDREFs...)
 b) What happens when such a reference cannot be resolved and/or
dereferenced at a given SOAP Node.

I think I have been thinking more generally about the
resolution/dereferencing of URIrefs carried by href attributes and have not
restricted my thinking solely to the context of the SOAP Encoding Style. 

Having looked more carefully at the current WDs (part 2 section 4.1 [1]) the
use of href and id attributes is more narrowly scoped than in earlier
versions. In earlier versions href and id were defined independent of
encoding style [2,3]. In our current WDs, the signifcance of unqualified
href and id attributes is undefined outside of their use in the SOAP
encoding style (I think).

I guess that in terms of the SOAP Data Model and Encoding style I find it
difficult to conceive of a situation where serialising a graph conforming to
the data model would give rise to a reference that was not simply a
reference to a fragment within the same envelope. I suppose that it is
possible that an graph could be serialised into multiple entities (eg an
SOAP Message and some accompanying XML fragments carried in an attachment or
dumped to some web accessible resource and referenced by a graph edge
carring a full URIref...) - maybe I need to get further out of the box :-). 

	Do folks actually want to do this (scatter a graph 
	across multiple messages/attachments/documents)? 

	Or is it a "should not preclude"? 

	Or is the case that in *all* practical cases of serialising
	a graph conforming to the SOAP data model using the SOAP 
	encoding style, any references generated can be made as URIRefs
	that contains just a fragment ID?

If the latter then it does seem that IDREFs would, as others have suggested,
serve the purpose - I would like to understand better the reasons why others
feel strongly that the use of IDREFS would be a mistake (in the narrow
context of the SOAP encoding style).

> And as for not knowing whether the server faulted because the
> server is only required to generate the fault and not to send it,
> this should be taken care of by the used message exchange
> pattern, like in request/response the fault is a response and a
> lack of response indicates some kind of failure.

The point I was trying to make here, perhaps not very clearly, was that the
point in time where a reference is actually used (and the brokeness of the
reference discovered) may be well separated in time from the message
exchange that communicated the reference. eg a void function that normally
returns no result and where the computation simply gets queued for later.
There may be no existing message exchange context with which to associate
the fault. That said, this thinking about the more general use of hrefs (or
URIRefs, however communciated) than their use in SOAP encoding.

However... regardless of the URIref/IDREF choice (which most of the above is
about)... what should be the correct behaviour when there is an (internal)
reference to a fragment (graph node) that has, for whatever reason gone
missing?

In the context of deserialisation of the SOAP Encoding this feels like a
deserialisation failure (predicated on the assumption that the completed
graph serialisation is contained within a single message) - so that does
feel like it warrants a fault! 

In the more general context of dereferencing a URIRef (either because it is
a value at a graph node, or in some context other than SOAP encoding)...
that seems more like application semantic and mandating a fault seems overly
prescriptive.

Regards

Stuart
[1] http://www.w3.org/TR/2001/WD-soap12-part2-20011217/#encrules
[2] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/#reltoxml
[3] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#reltoxml
[4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x170

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: 03 January 2002 16:59
> To: Henrik Frystyk Nielsen
> Cc: noah_mendelsohn@us.ibm.com; skw@hplb.hpl.hp.com; 
> xml-dist-app@w3.org
> Subject: RE: Issue #170: "Referencing Data missing from the message"
> 
> 
>  Hello all. 8-)
>  First, I'd like to thank Stuart for writing the summary, I think
> it was almost correct. 8-) See below.
>  Now, I'd like to clarify why I feel MUST is a must.
>  Henrik says that the semantics of href links are not controlled
> by us. I feel that the contrary is true - we have a data model
> that describes a closed directed graph of structs, arrays and
> primitive values. A link means that the value of an accessor is
> not "here", that it's somewhere else, possibly shared with an
> other accessor. An attempt to deserialize a node of a graph in a
> SOAP message IMO means that the data is necessary.
>  For example in RPC, the major user of the Encoding, and in a
> Java implementation, the call may be modeled as a Java method
> call with the appropriate parameters. In such case either each
> value is hidden behind some kind of dereferencable object and
> requires manual dereferencing, or the values are in usual
> structs and arrays of primitive types, in which case the code is
> much simpler. I think the latter is the usual approach of RPC
> systems. Neither Java nor C allow the SOAP implementation to hide
> the dereferencing from the application, as opposed to C++ with
> its operator overloading. RPC comes from the C world.
> 
>  Anyway, I think we should require faulting at least for local
> (as opposed to external) references because if some data could be
> stripped from the message, I think that the stripper better
> understand the logic of the data and therefore it can put nulls
> in the appropriate places from where the stripped data is
> referenced.
>  If you agree with this, then there is the obvious question of
> "how are internal and external references different?"
> 
>  My major position is that we should disallow external references
> altogether for they bring so much trouble and are inconsistent
> with the usual RPC approach to data.
>  The two major problems are
>  1) missing data and
>  2) typing of the external data.
>  The one major gain is SOAP w/Attachments. Attachments can be
> implemented in a different way very easily:
> 
>  <linkToAttachment xsi:type="att:AttachmentReference">
>    cid:...
>  </linkToAttachment>
> 
> And this would be quite the same as the way Maps etc. are being
> represented now. Who thinks attachments are more important and
> used more widely than maps?
>  If we get rid of external references, the missing data problem
> will stay, but then it would IMHO be apparent that such case is a
> fault.
> 
>  On another point, why should the client be able to tell whether
> the data was accessible or unneeded? And how does this
> non-distinction equalize MUST and MAY fault?
>  And as for not knowing whether the server faulted because the
> server is only required to generate the fault and not to send it,
> this should be taken care of by the used message exchange
> pattern, like in request/response the fault is a response and a
> lack of response indicates some kind of failure.
> 
>  It's a very interesting experience to argue against Henrik, Noah
> and Stuart, all of which I admire, and I do hope you show me a
> technical reason why external references and soft references
> should be core in SOAP Encoding. So far I've seen no such reason.
> Both can be implemented as extensions to SOAP (just as maps), the
> way I think SOAP is meant to be.
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
>

Received on Friday, 4 January 2002 10:56:52 UTC