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

 Andrew,
 I think you hit the point exactly with your analysis.
 My opinion, in terms of your analysis, can be summarized as the
following:
 I believe in 1a. I'm willing to bend a bit by actually allowing
external references (like to attachments etc), the graph still
being closed and deserialized in its wholeness.
 Because I'd allow external references, I see the typing
information for the referred data as being provided by the
resolving process in an implementation-specific or
third-party-specified way (for example a .net impl could guess
depending on the filename extension, and SwA could specify typing
according to MIME types of the attachments).
 Unfortunately, this 1a or 1b/2 view of SOAP Data Model and
Encoding is a majority vote thing, I guess, not likely to end
with consensus.
 Best regards,

                   Jacek Kopecky

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



On Wed, 12 Dec 2001, Andrew Layman wrote:

 > 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 Thursday, 13 December 2001 08:06:38 UTC