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

I think that this email comes close to describing
my view as well, that the (automated) serialization of a tightly
linked graph is what SOAP encoding is about.

However, I don't see RDF serialization as having anything
to do with SOAP encoding. RDF expression as XML is effectively
its own encoding.

I suggested at the F2F that SOAP encoding be restricted
to ID/IDREF and that all of the referenced data be contained
within the envelope (and preferably within either the
SOAP Header or SOAP Body element in which the reference
exists).

If there is need to reference data externally (e.g. SwA
or on the web, etc.) then this is strictly application
data and semantics that has nothing to do with SOAP encoding
and everything to do with the application semantics. The
SOAP encoding href is NOT to be used to express this application
semantic. It is just data to be serialized.

This allows for us to say that if the IDREF doesn't resolve
to a node in the SOAP envelope document, that the deserialization
mechanism can assert that there is a problem and return a
Fault.

I don't believe that we need to provide a mechanism that
allows for willy-nilly serialization where the serializer
will think to itself "hmmm... this referenced data in the
graph needs to be sent separately as an attachment..."
It is just a stupid peice of code that walks a graph and
remembers what it has already serialized and can provide a
reference back to that data when it is encountered subsequently
in the traversal of the graph of data.

Cheers,

Chris

Jacek Kopecky wrote:

>  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 Monday, 17 December 2001 09:40:39 UTC