RE: Issue with soap-rpc:result

Jacek,

I understand that XSD is not the only type system in the world. However,
it is the standard type system of XML. As such, it is being integrated
directly into other standard XML technologies including XPath, XSLT, XML
Query, etc. I want to see it integrated into another standard XML
technology, i.e., SOAP.

In the majority of RPC technologies I have used, there was one type
system for things sent on the wire. Descriptions of these types were
written in IDL. It was the responsibility of the client and server
developers to map between their native programmatic data types to the
type system used on the wire. While it might have been preferrable to
use an alternate type system to describe what went on the wire, the RPC
engines didn't allow it. You had to use the RPC's type system and map
your native types to it. (The only exception to this was Java RMI -
because there was only one programming language, its type system *was*
the type system used on the wire.)

The same thing is true with SOAP. The messages being sent are written in
XML. The standard type system for XML is XSD. You, and everyone else,
has a native type system in their programming language of choice and we
should all map them to XSD.

The problem I have with SOAP is that it takes a halfway approach. It
relies on XSD simpleTypes, xsi:type and xsi:nil. And yet, a while back,
when you responded to Simon Fell's mail about representing a linked list
[1], you describe the structure of your message in terms of an XSD
complexType. And the description of the SOAP encoding rules in SOAP 1.2,
Part 2, Section 3 provides XSD examples that describe messages in terms
of complexTypes.

Given that XSD is used to describe encoded message formats in the
current draft of the specification and your own email illustrates the
common practice of using XSD to describe message formats, how can one
possibly argue that XSD either is not or should not be deeply integrated
with SOAP???

As to the issue you raised in your post, yes, it is the case that there
are some constructs that XSD doesn't support, such as co-occurance
constraints across elements and attributes. All I can say is, so what?
Java doesn't support enums, a feature most developers would like to
have, but people make do somehow. C# doesn't support overriding virtual
methods with covariant return types, but again people make do somehow.

For better or worse, XSD is the standard that W3C specs are written to
and XML stacks are implemented against. It isn't perfect, but neither is
anything else. SOAP already relies on XSD to describe messages, more so
than anyone admits. 

So, why introduce an alternate type system just for SOAP which is
loosely defined in prose and is incompatible with any other XML
technology UNLESS the mapping from that type system to XSD is CLEARLY
described. That's what the Part 2, Section 3 SOAP Encoding should do
(for instance, is it legal in the encoding to use xsi:type to describe
an element's content in terms of an XSD complexType?). That's what any
additional encodings should do too.

If that isn't the case, then the SOAP data model and the subsequent
encoding rules should be removed from the spec.

Thanks,
Tim-

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0129.html

> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com] 
> Sent: Friday, February 22, 2002 7:35 AM
> To: Tim Ewald
> Cc: 'XMLDISTAPP'
> Subject: 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 Saturday, 23 February 2002 13:58:37 UTC