- From: Tim Ewald <tjewald@develop.com>
- Date: Fri, 8 Feb 2002 16:44:43 -0500
- To: "'XMLDISTAPP'" <xml-dist-app@w3.org>
> I respectfully disagree with your message below. Likewise. :-) I understand that the schema for the tree that represented a complicated SOAP data model graph could be quite complex. However, I would argue that it is preferrable to saying, as the WSDL "encoded" style does, "Here's a schema that sort of describes what the message will look like, but then a bunch of rules are applied." This is how SOAP systems are being built today and it leads to all sorts of problems because different implementations interpret the rules differently. In the end, if you are defining a set of rules for mapping a graph to an XML-based tree, you are implicilty defining a schema. The current working draft of SOAP 1.2 Part 2 recognizes this: it includes sample XSD fragments that describe the XML constructed by applying the SOAP Encoding rules. In other words, the current definition of the SOAP encoding rules explains how to map constructs from the SOAP data model to XML and then defines sample schemas. Why not simply switch things around so that the spec explains how to map constructs from the SOAP data model to XSD and then provides a sample of the equivalent XML? That would make the section easier to understand for people implementing the SOAP nodes and it would resolve this issue. (Yes, I understand that there are some aspects of the encoding that cannot be entirely expressed in schema, i.e., mutual exclusion of the href/idref attribute and element children, but that is an issue with the XSD samples in the spec today - so we'd be no worse off then we are now.) Thanks, Tim- > 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 16:45:55 UTC