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

Thanks. I'm not a big fan of 1a, despite its historical roots.  I think
it binds applications more tightly to a particular implementation and/or
language, and the limitations of specific languages, than 1b or 2 do.
In general, I think that we get more interoperability and more version
independence the more we agree only on the syntax of messages on the
wire and not on the implementation mechanisms at either end.

-----Original Message-----
From: Marc Hadley [mailto:marc.hadley@sun.com] 
Sent: Thursday, December 13, 2001 9:14 AM
To: Andrew Layman
Cc: xml-dist-app
Subject: Re: issue 168 proposal: xsi:type of external references in
Encoding

Nice analysis. During the last WG telcon we briefly discussed changing 
the encoding referencing mechanism from a general URI to an IDREF in 
order to enshrine the 1a viewpoint you describe. External links (inc 
those for attachments) would then be represented as data within the 
encoding whose processing is deferred to the application.

Bearing in mind that an alternative encoding can be used where 
appropriate (e.g. for serialising RDF), are there use cases for SOAP 
encoding that would be difficult to fulfil if this were to happen ?

Regards,
Marc.

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



-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Thursday, 13 December 2001 14:04:12 UTC