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

My comments inline

> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Henrik Frystyk Nielsen
> Sent: Monday, December 10, 2001 4:14 PM
> To: Noah Mendelsohn; Andrew Layman
> Cc: jacek; xml-dist-app
> Subject: RE: issue 168 proposal: xsi:type of external references in
> Encoding
>
>
>
> 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.

Yes, you have it exactly.  The general solution (xlink, rdf, your note on
soap/rdf, others) is to create some kind of container element that wraps the
href, then have other elements/attributes provide further information.  The
fundamental problem is that there is a limitation of XML that one cannot
annotate attributes (like href) using other attributes.  Thus elements are
born - such as simple/extended from xlink.

>
> 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.

Further, there are other issues around obligations for a recipient to
dereference.  Of particular interest to XLink are the show and actuate axis,
which respectively are the "what to do with the dereferenced thing" and
"when to do the dereferencing".  Xlink chose replace/new/embed and
onLoad/onRequest respectively.

It is easy to imagine other wonderfully useful information on references
between senders and receivers, or even a framework for expressing and
extending them, but we have neither the time nor the mandate.

>
> 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?
>

The issue is that references are often a special data type that applications
would often like resolved/dereferenced for their application.  An
application developer does not want the hassle of the "stitching together"
or retrieval process exposed to them.  The problem - and you address this -
is that doing a general purpose reference typing/encoding/de-referencing
does not appear to be possible.  I understand people's motivations - I had
them myself at one point - but IMHO there is no easy/reasonable/useful thing
to do given our schedule.

Cheers,
Dave

Received on Monday, 10 December 2001 20:51:17 UTC