Re: Rationale for Dropping the <soap:body use=...> Attribute

 Arhur,
 if you want an abstract schema at the wsdl:message level, that's OK
with me and it's understandable. On the other hand, if you want to
remove the use attribute by saying that "literal XML Schema" is the only
possible way in SOAP, I disagree because that either results in ugly
*and* ambiguous data structure schemata or in disallowing other data
models altogether (with SOAP Data Model among them).
 I think that especially because the parts of wsdl:message should be
described abstractly, we may need different data models right here,
otherwise we'll say that, abstractly, WSDL only describes services that
can transfer trees with very raw untyped references.
 So, either let's keep use="encoded" or let's allow different schema
languages (other than XML Schema), and I prefer the latter because it
agrees with the requirement "abstract description of wsdl:message
parts".
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


On Wed, 2002-09-18 at 15:59, ryman@ca.ibm.com wrote:
> 
> Jacek,
> 
> I agree that the original authors of the WSDL had a lot of generality in
> mind concerning multiple type systems. However, I prefer the viewpoint that
> messages should be described abstractly, so all you really need is one
> sufficiently expressive type system. XML Schema fills that role. While it
> is best for tree-like data, it can also be used for graphs via the ID and
> IDREF types.
> 
> All details about how the message is formatted should be in the binding.
> For the SOAP binding, we are proposing that the only binding we need is
> literal. Attempts to use a more flexible bindings, SOAP encoding, led to
> interop problems.
> 
> So, no, I'd say not to use a different kind of schema language. Leave the
> message definition independent of the binding. If more flexibility is
> really needed, then modify the SOAP binding rules, but specify the encoding
> algorithm more clearly to eliminate interop problems.
> 
> Arthur Ryman
>

Received on Wednesday, 18 September 2002 12:11:17 UTC