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

 Andrew,
 SOAP already gives you this: you can send plain XML messages
with no encoding semantics specified at all. XML is the ultimate
"syntax of messages on the wire", isn't it? 8-)
 Just in case you agree with the above, you don't need SOAP
Encoding at all and so we should gather the requirements from
those who feel they do indeed need a SOAP Encoding. 8-)
 If you don't agree with the first paragraph, which is likely,
then I think I'd like you to rephrase and maybe detail your last
sentence below, please.
 Anyway, for open graphs the web (the W3C, actually) already has
RDF so why create a different encoding and data model? On the
other hand the traditional RPC world, deeply rooted in history,
has need for the closed-graph-approach data model and encoding
exactly because of the roots - it helps the transition from old
RPC systems to the Web Services world. Gradually, people will
free themselves of the constraints of the closed-graph-approach
and the'll move to RDF, but in the meantime I think we can help
them a lot with the 1a-esque SOAP Encoding.
 Oh, btw, I think I need some of that help myself. 8-)

                   Jacek Kopecky

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



On Thu, 13 Dec 2001, 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.
 > 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.
 > >
 > >
 > >
 >
 >
 >
 >

Received on Thursday, 13 December 2001 14:36:51 UTC