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

Andrew Layman wrote:

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

 >
Could you explain why you think 1a leads to tighter binding than 1b or 
2. I think it simplifies implementations but I don't see that it ties 
applications any more tightly to those implementations.


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

I agree, but I don't see what bearing this has on the 1a vs 1b, 2 choice ?

Regards,
Marc.


> -----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 Monday, 17 December 2001 08:51:40 UTC