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.

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

>Andrew Layman asks:
>
>>>  Can we make such normative statements
>>> universally about URI reference processing
>>> or should processing depend on the
>>> semantics of the message? I think the latter.
>
>Roughly, I've proposed that the core SOAP architecture 
>anticipate SOAP + Attachements, DIME, etc. by including a 
>statement that transport binding specifications SHOULD 
>indicate which URLs (generally which schemes, but not
>necesarily) are used to reference data that is carried with a 
>message, as distinct from all the other data on the Web.  We 
>use URI's for both, but I think it's useful to have a strong 
>notion of "this data is a reference within the message, though 
>not necessarily within the SOAP envelope." Note that these 
>rules would apply to URI's anywhere in the message, not just 
>where SOAP can find them.  If the application finds a URI 
>pointing to an attachement, we should specify the general 
>characteristics of a dereference of that URI, I think.
>
>That's all I meant.   Once you've got that, you can start to 
>ask how you'd
>want the encodings to behave in the face of one or the other 
>reference. Perhaps the behavior would be the same for 
>attachments and other web references, perhaps not.

Received on Monday, 10 December 2001 19:14:49 UTC