RE: issue 168 proposal: xsi:type of external references in Encoding (fwd)

 Henrik,
 I'm a strong believer in layering. I don't like mixing
semantically different layers. As for the representation of RDF
using the SOAP Encoding, as seen in [5], I'm not sure how RDF
views the href, so let me discuss it a bit. There are two
possibilities, with the difference being rather subtle:
 1) href is a first-class data whose meaning is to point
somewhere.
 2) href is a metadata whose meaning is "the data is not here,
it's at this URI".
 I view SOAP Encoding's usage of href as the latter, while it
seems to me that RDF's usage is the former. Let me explain why.
 Please see the following as my view on how it is or should be
and please do show me why it should not be as I see it.
 SOAP Encoding is meant as a mechanism of serializing tightly
linked data graphs (mainly) for RPC purposes. For sake of
simplicity (as in Simple Object Access Protocol 1.1, the
predecessor of SOAP 1.2) it is assumed that the deserialization
will be automatic (in the middleware, not in the application) at
the receiving node.
 In RDF, the graph is loosely linked, which means the application
gets a part of the graph and dereferences links when it's needed.
Therefore the href functionality should be on the application,
therefore the application should get the hrefs intact, therefore
the serialization in SOAP Encoding, as I see it, should be

  <rdf:Description>
    <rdf:about>http://www.w3.org/Home/Lassila</rdf:about>
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>

 (assuming that rdf:about is always an href, which I'm not sure
about.) In this case the tightly linked graph is

   Description --- "about" ---> "http://.../Lassila"
               \
                -- "Creator" -> "Ora Lassila"

 And the fact that this can be viewed as a part of a loosely
linked graph is in the realm of the application.
 I think my approach keeps SOAP Encoding simple, understandable
to the programmers and usable _without_changes_ in any
application. We end up with a few strictly separated layers:
 transport | SOAP processing model | data encoding | application
 I think you don't view data encoding as a separate layer, while
I do because Encoding is a separate chapter and therefore
implicitly independent of applications.
 Hope I'm clarifying the view-clash here,

                   Jacek Kopecky

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

[5] http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/soaprdf.html



On Mon, 10 Dec 2001, Henrik Frystyk Nielsen wrote:

 >
 > Not to further confuse the issue, but I think there are three questions
 > being somewhat mixed up in this thread:
 >
 > 1) What type of data is an href value referring to?
 > 2) What are the obligations for a recipient to dereference href values?
 > 3) What (if any) conventions do a feature introduce for describing
 > references?
 >
 > Regarding 1), which I believe is the core of issue #168, I don't think
 > the SOAP encoding inherently provides a mechanism for indicating neither
 > the type of the reference nor the type of the referenced data. It is
 > left to the semantics of the data using the encoding to indicate what
 > such information. The representation of RDF using the SOAP encoding [3]
 > illustrates one example of how one can add such attributes.
 >
 > Regarding issue 2), I believe we addressed the question of what to do if
 > a receiving SOAP node attempts to dereference an href value but the data
 > is not available (see [0], [1] and [2]). That is, we provide a general
 > fault mechanism that is used in case an href value fails to be
 > dereferenced for some reason if so attempted by the receiving SOAP node.
 >
 > On 3), the scope of the "cid:" URI scheme is defined to be "within the
 > MIME message" but this is only one of the linking mechanisms supported
 > by RFC2557. Use of the "cid" URI scheme provides no guarantee that the
 > link can be resolved, it only indicates what the scope is. In addition,
 > one can use the value of the Content-Location header field as an
 > identifier for referring to a MIME entity and this field may contain any
 > URI. There are several examples in section 3 [4] of SOAP with
 > Attachments that illustrate this.
 >
 > While I agree that features can indicate rules for how to (de)reference
 > parts defined by that feature, I am weary of associating any form of
 > reliability guarantees with such rules as that would seem to have to be
 > enforced at a higher level. In other words, SOAP with Attachments can
 > provide the conventions for how to refer to the various "attachments"
 > but can't guarantee that links provided by the application will work.
 >
 > In general I don't see why references are different from any other piece
 > of data in SOAP. We don't guarantee that data is within bounds or make
 > sense in any way so why should we do that for references? A feature may
 > provide services that involve references and of course they have to be
 > used properly in order to be useful to the receiving application but
 > isn't this the case for all other data too?
 >
 > Henrik Frystyk Nielsen
 > mailto:henrikn@microsoft.com
 >
 > [0] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0012.html
 > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0017.html
 > [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0047.html
 > [3] http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/
 > [4] http://www.w3.org/TR/SOAP-attachments#SOAPReferenceToAttachements
 >

Received on Tuesday, 11 December 2001 07:20:38 UTC