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

I've just read all of this thread again.

There are several issues raised in it.  

One is the question of whether one can somehow, by mere inspection of
the URI value of an href attribute, determine the type or other
characteristics of the resource that might be obtained by resolving the
URI.  As Henrik described, the answer to this is "no."  One might
determine the type, etc., if one had additional information, say
provided by a schema somehow or by a yet-to-be invented attribute, but
no such mechanism is now part of either the URI or the SOAP encoding by
itself.

I think that a larger issue is the apparent clash between two different
assumptions about what is in a SOAP message within an element containing
content labeled with a soap-enc:encodingStyle attribute:

1.	It is an abstract graph of data, and it must be reconstituted by
a reader as exactly that graph of data.
	1a.	The graph is closed.  Hrefs are only a serialization
mechanism for encoding internal links.  External links are data as far
as the serialization algorithm is concerned, and hence never appear as
href values (or, if they do, this is peculiar and should be specially
distinguished from the internal links).
	1b.	The graph is open and infinite, and any serialization is
only a fragment of the cosmic, infinite graph.

2.	It is an XML structure, which the writer advises may be turned
into a graph by a defined process.  The graph is open, and the
deserialization process will result in some links being immediately
resolvable to nodes in the graph while others may not be immediately
resolvable.

I believe that those who think mainly in terms of RPC hold 1a, that RDF
holds 1b and that those who think mainly in terms of XML documents would
hold number 2.

1a leads naturally to the idea that external and internal links should
be syntactically distinguished, that internal links MUST be resolved by
any reader (in fact, that actual deserialization MUST be performed by
any reader) and the failures to successfully resolve an internal link
indicate a gross error somewhere.

I think that 1b and 2 amount to very similar if not the same processing
in practice, namely that if the reader finds that deserialization is a
convenient way to process data, he may deserialize the XML into a graph
by a defined process, and will end up with some references that are
immediately resolvable and others for which attempts to resolve are
deferred.  What actions a reader takes respecting these depends on the
semantics of the data and the purposes of the reader.

I hope this analysis is helpful.

Received on Wednesday, 12 December 2001 14:36:28 UTC