Interoperability, "Strong" Typing, and Schemas

[Jim Gloor <jg...@OpenRatings.com>]

I'm relatively new to SOAP (< 2 months) and it's issues.  From the soap-dev
archives, I get the feeling this is an old thread, but I have to ask...
 
Has anything been done since v2.0 to address the interoperability issue,
especially with regards to Apache SOAP's total reliance on type attributes
for deserialization?  My company has been struggling with this, since we
would like our server to be accessible from MS-SOAP.  I've been assigned to
straighten this out for us.  :(  I can get past the problem with custom
deserializers for the method call parameters, but I can't see any way of
getting to these deserializers without at least having a type attribute on
the parameters themselves.
 
On a side note:  what exactly does the SOAP 1.1 spec say about this?  From
Section 7.1...
 
*	Each [in] or [in/out] parameter is viewed as an accessor, with a
name corresponding to the name of the parameter and type corresponding to
the type of the parameter. These appear in the same order as in the method
signature.
 
Aside from the issue of where, exactly, the method signature is meant to be
specified, this seems to to be saying that the parameters SHOULD always be
carrying a type attribute.  The examples in the Appendix, however, uniformly
do NOT have such type information.  I'm confused!
 
On a related note:  has there been any discussion about having something
like a "SchemaSerializer", which gets its type information from an XML
Schema?  I'm not talking about a WSDL-like toolkit that generates code from
a schema, but a serializer that queries the schema during runtime and uses
introspection, like the BeanSerializer, to serialize/deserialize the body of
the message.
 
Jim Gloor