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 Thursday, 3 January 2002 11:58:39 UTC