RE: Issue with soap-rpc:result

While I agree that XSD cannot describe the SOAP data model directly, it
*can* describe an encoded version of the data model that is
representable as an XML infoset. The only limitation is the
soap-rpc:result element, which forces reliance on another source of
metadata to understand at development time what the return type of an
RPC really is.

I understand the need to make the result element in an RPC response
message easily identifiable. However, this could also be achieved by an
attribute from a well-known namespace that identifies a particular
element as being the result. That would achieve the same effect AND
allow one to define a message format entirely in XSD.

Defining an alternate encoding of the SOAP data model to SOAP message
can't solve this problem, because the use of soap-rpc:result is mandated
by the SOAP RPC model, not the data model. 

Alternatively, one could embrace SOAP 1.2 Part 1 and ignore SOAP 1.2
Part 2 (as SOAP 1.2 does with XSD Part 2, but not XSD Part 1) and invent
a different, though very similar, data model and RPC model. But this is
inelegant and unsatisfying. In the end, the messages we are sending with
SOAP are expressed in XML. It would be a sad state of affairs if we end
up with some SOAP-centric systems that embrace 1/2 of XSD and some
XSD-centric systems that embrace 1/2 of SOAP.

The differences between these technologies is not insurmountable. All we
need is:

- a set of XSD types that can adequately express the SOAP data model
when it is flattened to a tree
- a way to describe an element representing an RPC return value that is
both recognizable and whose type can be defined at development time
using XSD.

Thanks,
Tim-

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Jacek Kopecky
> Sent: Thursday, February 07, 2002 5:19 AM
> To: XMLDISTAPP
> Subject: RE: Issue with soap-rpc:result
> 
> 
>  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 12:40:04 UTC