W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Issue with soap-rpc:result

From: Jacek Kopecky <jacek@systinet.com>
Date: Thu, 7 Feb 2002 11:19:09 +0100 (CET)
To: XMLDISTAPP <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0202071027180.6270-100000@mail.idoox.com>
 Hi all,
 this is a long reply to all issues in the thread I have seen.
 This thread has touched a number of issues, some of which the WG 
has already touched and tried to close.
 I'll try to reconstruct how the current situation was achieved:
 (You may probably skip the following big block of text to my
summary of the WG's choices and of the problems.)

 In SOAP Encoding, there either is or is not one underlying data 
model. We decided there is one and we specified it as being one 
that supports graphs of compound (struct, array) or simple nodes. 
This is the SOAP Data Model section.
 In this data model, we need to type the simple nodes, we chose
to use XML Schema Datatypes to do that. Note that we don't
explicitly use XML Schema Structures (maybe except for using
XSI:nil), but many people do not seem to understand the
difference and therefore they take it as thought the SOAP Data 
Model uses and supports the whole XML Schema.
 The SOAP Encoding is one possible set of rules for serializing
data in our data model. There can be other encodings of the same
data model and there can be other encodings of other data models.  
So called "unencoded" data are just data in the XML tree data
model.
 XML Schema describes the possible instances of the XML tree data
model.
 When working on the RPC section, we had two options:
 1) make RPC requests and responses modeled with XML Schema and
just elements, without any connection to any encodings (except
for the "unencoded" that is), and allow the parameters to be 
encoded in any encodingStyle,
 2) or make RPC based on our Data Model or on our Encoding.
 We decided on making RPC based on the Data Model (I advocated 
choosing the option no. 1, btw.) and therefore the RPC requests 
and responses can either be simple types, structs or arrays.
 Historically, SOAP RPC names the parameters, therefore a struct
rather than an array of parameters is appropriate for the
request. For the response, there is the unnamed thingie that is
the return value. SOAP 1.1 said that it's the first return
parameter whatever its name, which goes against the notion of
structs with named, not numbered, members. We decided to pick a
name. The choices were "result", "SOAP-RPC-Result", or
"soap-rpc:result", the latter being namespace qualified. We chose
the latter because namespaces are exactly what allows us to avoid
name conflicts.
 Now on to WSDL, XML Schema and our own schema: In languages like
WSDL it is necessary to describe data structures. For simply XML
data this task is easy - just use XML Schema. But let's remember
that XML Schema is based on the XML tree data model and can 
describe some (not all, AFAIK) possible document classes.
 Data in the SOAP Data Model, encoded using the SOAP Encoding
rules, can take various XML forms, mostly because of the use of
references. All the different forms are equivalent from the point
of view of our data model, they are quite distinct from the point
of view of the XML tree data model. Expressing all the possible
XML serializations of some SOAP data structure using XML Schema
is difficult, if not impossible.
 To describe the data in our data model, the natural option is to
use SOAP Schema Language (so far implied). People are wary, 
though, of creating yet another schema language, and that's 
understandable. Therefore the WSDL folks invented so called 
"encoded" use of XML Schema - describing data structures using an 
XML Schema schema, then implicitly translating this description 
to the SOAP Schema Language (IMHO that's what most SOAP toolkits 
do when working with "encoded" use of schemas in WSDL) and 
following that translated description during serialization or 
deserialization. This means (and WSDL spec says this clearly) 
that the resulting XML need not comply to the XML Schema schema 
provided.
 This approach has proved viable, and it will be interoperable,
too, once toolkits agree on the (again implicit) rules for
translating XML Schema schemata to SOAP Data Model schemata.  
That's (one of the reasons) why WSDL Interop event is just now
being arranged.

 To summarize the choices the WG made:
 1) the SOAP Encoding is based on a single, concrete data model,
 2) the SOAP Encoding is not the only possible encoding of data 
in that data model,
 3) SOAP RPC is based on the same data model,
 4) SOAP RPC represents requests and responses using structs,
 5) RPC return value is named enc:result to avoid conflicts.

 The open problems in this thread are the following:
 a) XML Schema cannot be used easily (or maybe at all) to
describe the RPC structs, yet we want to do just that because
 b) we don't want yet another schema language.

 Both these problems, as far as I can see, can be viewed as 
problems of WSDL, given the choices above. Granted, changing some 
of the choices might practically lessen the problems. But this 
group wants to make a good XML messaging protocol, and provide 
good rules for serialization of a given graph data model into 
XML.
 We do want to support XML Schema whereever appropriate, but I
don't think we need to support XML Schema even where it is 
inappropriate - like for describing SOAP Data Model data. That 
would be overloading (if not abuse) of XML Schema. Everybody can 
choose not to use SOAP Encoding but use XML tree data model 
instead, describing messages with XML Schema, and that's exactly 
what WSDL's so called "literal" use of schemas does.

 It's not a bug that our data model is not suited for every
application, that's why it's optional.

 It's not a bug that SOAP Encoding data cannot be easily
described by XML Schema - they have different data models and 
that's good.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/
Received on Thursday, 7 February 2002 05:19:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT