axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Murphy <>
Subject Re: (soap encoding <-> XSD) mapping
Date Mon, 02 Aug 2004 23:03:39 GMT
Jonny Rylands wrote:

> Sorry for my newbie level of understanding (!) but am I right in saying that
> the XSD is the language to specify types (in WSDL) whereas SOAP encoding is
> the 'language' to specify values (in encoded SOAP messages)?

I definitely concur with the first part.  XSD is a typing language for 
XML.  We make the leap of mapping that XML typing to any given 
programming platform - like java, .NET, Perl or C++ - without blinking 
but probably shouldn't.  Thats a whole other kettle of stinky fish that 
should probably just be left to pickle.

SOAP encoding is a way to serialize SOAP messages on wire.  Its old and 
is falling our of fashion but thats where everything started.  SOAP 
encoding was design *before* XSD/WSX which is why it existed at all. 
That and the designers of SOAP were originally *WAY* more interested in 
marshaling an object graph in XML than they and everyone else is today. 
  Today its about trading XML documents wrapped in Envelopes that may 
contain Headers.  Its NOT about doing RMI over the Internet using XML.

What SOAP encoding is is a series of rules for laying down objects into 
XML with significant inspiration from the classic RPC stacks of yore. 
Things like sparse arrays, linked lists, circular lists and pointer 
aliasing were really important.  Imagine you have an array of 3 items 
that you want to send to a web service using SOAP encoding.  Is it 
important to maintain the fact that the array is actually of the same 3 
object instances?  SOAP encoding came up with a way to encode that. 
Today people don't care as much about "reproducing a stack frame" and 
are more interested with exchanging typed data - period.

> Hence for a toolkit to fully support XSD when using SOAP encoded services,
> you would need a full (Java/C++ etc) implementation XSD simple types and
> their facets, plus the complex types allowed in the SOAP encoding spec
> (arrays and sequences etc)? 

Services typically DON'T fully support XSD and arguably shouldn't.  In 
fact many don't support some really common parts.  The WS-I is forming a 
  Schema profiling working group to address this issue.  That should be 
fun to watch.

Arrays can be described using SOAP encoding using the techniques in 
section 5 and 7.  They can also be described in other ways in just plain 

<complexType name="ArrayOfString">
     <element name="item" type="xsd:string"
         minOccurs="0" maxOccurs="unbounded" />

See no soap encoding required.  What you are saying with this XSD is 
that there is an Element named ArrayOfString (could be anything) that 
contains zero-unbounded number of elements named item that have 
xsd:string content.

Compare that to the Array specification for SOAP:

<complexType name="ArrayOf_xsd_string">
     <restriction base="soapenc:Array">
       <attribute ref="soapenc:arrayType"

First off your program would have to have knowledge of what 
soapenc:Array is.  Typically thats not defined anywhere in the schema so 
already there is incomplete type information.  Also notice the arrayType 
attribute specification.  Notice also the fact that there is another 
attribute on there from another namespace - the wsdl:arrayType.  Your 
program also has to undersatnd that this attribute exists - and you must 
parse the value to understand that the array is an array of 5 strings.

So basically thats the difference between SOAP encoding and literal. 
With literal everything is specified in the WSDL with XSD.  With SOAP 
encoding some things are specified in the WSDL and some is "known" but 
usually not well known - if you know what I mean.

Jim Murphy
Mindreef, Inc.

View raw message