RE: Issue with soap-rpc:result

 Tim,
 you seem to assume that XML Schema is _the_ language for
describing the structure of XML documents. In my opinion (and I
hope that in the opinion of XML Schema authors, too) it is _a_
language for describing a set of possible structures of XML 
documents.
 You admit that XML Schema may sometimes describe SOAP Data Model
data structures in a grotesque way. I claim that XML Schema
cannot describe properly any (but the trivial) SOAP Data Model
structures. For example (and the schema may be wrong but the 
idea should be clear):
   <complexType name="point">
     <element name="x" type="int"/>
     <element name="y" type="int"/>
     <attribute name="id" type="ID"/>
     <attribute name="ref" type="IDREF"/>
   </complexType>
 This can be understood as a schema for a struct with two
members, both integers, and possibly an ID, or a reference.  
 AFAIK XML Schema is not able to convey that
 1) _either_ the value (x, y) and possibly an ID _or_ a reference 
must be present,
 2) if it is a reference, the element with the matching ID must 
be of the same complex type.
 All of this would be _soooo_ easy in a different schema 
language, e.g.
   <struct name="point">
     <member name="x" type="xsd:int"/>
     <member name="y" type="xsd:int"/>
   </struct>
 The point is - XML Schema does have its own data model different 
from the SOAP Data model, and while it is able to represent data 
in one model using the other model, the representation may not 
always be describable strictly enough by the schema language for 
the other model.
 You say you want one SOAP with messages describable using XML
Schema, but XML Schema is not the ultimate and only schema
language (and should not aim to be). It's good for some stuff, 
worse for other. If your data is describable using XML Schema, 
you don't need to use the Encoding and Data model provided by the 
SOAP spec because you are already satisfied by the Data model 
of XML Schema and the Encoding thereof.
 I'm as certain as can be that we don't want to forbid using 
schema languages (and other data models) other than XML Schema 
when representing data using XML.
 Best regards,

                   Jacek Kopecky

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



On Wed, 20 Feb 2002, Tim Ewald wrote:

 > > [Noah]
 > > Overall: I have always had doubts about the wisdom of the
 > > graph model in
 > > SOAP, but it's also very late in the process to be 
 > > questioning it.   Count
 > > me as more or less neutral on the technial merits, but very 
 > > concerned that whatever we adopt be modeled and explained 
 > > very carefully and precisely.
 > 
 > I share your doubts, and wish I had raised the issue sooner. If it is
 > too late to change things, so be it. However, I *completely* agree that
 > whatever model is adopted must be explained very carefully and
 > precisely, including which bits are optional and which are not.
 > 
 > The problem I see in all of this is that right now there are basically
 > two SOAPs. People implementing toolkits handle encoded messages
 > differently from unencoded messages (which isn't supposed to be the
 > case, as per the thread on encoding style, but most SOAP toolkits I've
 > played with work this way).
 > 
 > I want there to be one SOAP based on sending messages described using
 > XSD. All messages that comply with SOAP's RPC model and encoding
 > mechanism can be described in XSD - albeit perhaps somewhat grotesquely.
 > All messages that can be described in XSD cannot be defined in terms of
 > SOAP's RPC model or encoding model. That tells me that XSD is the basic
 > atom for describing messages. I do not understand why the RPC and
 > encoding models cannot be written in terms of mapping the SOAP data
 > model to schema instead of directly to XML. (The notion that a contract
 > might be specified at the SOAP data model level can be addressed at a
 > higher level, e.g., in WSDL, at the SOAP level all we need to care about
 > is how the encoding rules map to a specific message format.) If those
 > parts of the spec are in fact optional adjuncts, layering them on XML
 > messages described by XSD seems like the only elegant solution to me.
 > 
 > In any case, in the absence of some sort of reconciliation between these
 > two sides of the SOAP world, I fear the current trend will continue. Web
 > Service toolkits will simply process messages using two different code
 > paths, one for RPC/encoded messages and one for non-encoded messages
 > described solely using XSD. Developers, meanwhile, will continue to be
 > very confused.
 > 
 > Thanks,
 > Tim-
 > 
 >

Received on Friday, 22 February 2002 07:34:56 UTC