RE: Issue with soap-rpc:result

 Tim, 
 I respectfully disagree with your message below.
 Let's imagine a double-linked list structure described below 
with a simple c-style code (this actually describes a more 
general structure which may be used to represent a double linked 
list):

struct node {
   int value;
   node *back;
   node *forth;
}

In XML Schema, we can go in two direction, either describe the 
data in the WSDL "encoded" style:

<complexType name="node">
  <sequence>
    <element name="value" type="int"/>
    <element name="back" nillable="true" type="tns:node"/>
    <element name="forth" nillable="true" type="tns:node"/>
  </sequence>
</complexType>

or we can try to describe every possible serialization of such a
structure using the SOAP Encoding rules (and I'm sure the schema
below is broken in many ways):

<complexType name="node">
  <choice>
    <sequence>
      <element name="value" type="tns:IntOrHref"/>
      <element name="back" minOccurs="0" nillable="true" 
                type="tns:node"/>	
      <element name="forth" minOccurs="0" nillable="true" 
                type="tns:node"/>
      <attribute name="id" type="ID" minOccurs="0"/>
    </sequence>
    <attribute name="ref" type="IDREF"/>
  </choice>
</complexType>

<complexType name="IntOrHref">
   ... something that allows an ID and an int value _or_ 
       (exclusive) a ref attribute ...
</complexType>

What I tried to encompass here was that a NULL can be omitted or 
represented as an xsi:nil="true" element (minOccurs and 
nillable), and that each element can be either a referencing 
accessor (only with the ref attribute) or a value, possibly with 
an ID. The problems with this schema (even if written correctly):
 1) I'm not even sure a schema can describe an exclusive or for 
the "ref _xor_ value and possibly ID",
 2) the schema is so complicated even for this simple scenario,
 3) references in this schema cannot be typed,
 3) I have a feeling that to reconstruct the SOAP Data Model
schema (here represented in a c-style language) one might need an
Artifically Intelligent program to parse the XML Schema schema.

 If we go with the first XML Schema example, the WSDL "encoded" 
one, we are already content with the result not complying to this 
schema, therefore we can indicate the RPC result parameter in 
many different ways, the problem would just be for everybody to 
pick the same way and stick with it.

 The underlying problem is that we just have to admit XML Schema 
was not built to be able to describe every possible data 
structure, especially if attributes and simple content are used. 
When serializing a graph structure into XML, it's better to 
describe the structure using a graph schema language rather than 
a tree schema language.

 Oh, and the suggested added attribute marking an RPC return
value is impossible because an RPC return structure is a struct
with members, there is no metadata (attribute) about the members
other than their types and names.

 Best regards,

                   Jacek Kopecky

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



On Thu, 7 Feb 2002, Tim Ewald wrote:

 > 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 Friday, 8 February 2002 10:21:06 UTC