W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2002

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

From: Jacek Kopecky <jacek@systinet.com>
Date: 20 Sep 2002 11:08:53 +0200
To: Arthur Ryman <ryman@ca.ibm.com>
Cc: WS Description WG <www-ws-desc@w3.org>
Message-Id: <1032512933.15852.26.camel@krava>

Arthur, please see inside.

                   Jacek Kopecky

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


On Thu, 2002-09-19 at 15:57, Arthur Ryman wrote:
> 
> Jacek,
> 
> 1. We disagree about XML Schema. You claim it is only good for tree-like data. I claim it is also good for graphs via ID,
> IDREF, <key>, and <keyref>. Although you may regard that as a kludge, wouldn't you agree that SOAP encoding is a bigger
> kludge?

SOAP Encoding is a means of serializing a graph into an other format
(XML) using its available functionality. XML is a means of serializing a
tree into an other format (UNICODE) using its available functionality. I
view SOAP Encoding as as much of a kludge as XML, i.e. very little.

The problem is that there is no SOAP Data Model Schema yet, but see
below.

> 2. I am not recommending that we completely drop support for SOAP Encoding. I am recommending that we require it to be
> described by an accurate schema, which I believe is possible although ugly in some cases. I am suggesting we allow the
> combination encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" and use="literal". I am also suggesting we allow
> encodingStyle="http://whatever-ws-i-org-calls-their-graph-encoding" and use="literal". In both cases the encoding style is
> just a hint for tools that generate a programming language data type from the schema. A tool shouldn't blindly apply code
> generation to the schema (since it could be ugly). The tool should take into account the encoding style used to generate
> the schema in order to generate a natural looking data type.

I have always seen (and talked about) two possible approaches: either
create a SOAP Data Model Schema language and use that instead of XML
Schema, or create a set of rules for translating an XML schema into a
SOAP Data Model schema (and back) so that there is little space for
disagreement between different WSDL toolkits.

The former approach does not require use="encoded".

The latter approach would be much easier if we have use="encoded"
because then we could just subset XML Schema and describe how it should
be understood with regards to SOAP Encoding. With use="literal" the XML
schemas will be considerably more complex.

In fact, I'm not yet convinced that translating an implied SOAP Data
Model schema into XML Schema is even possible. And there can be so many
data models out there. I am not ready to say that XML Schema is capable
of describing data in every one of them. I don't think it should,
either.

Jacek

> -- Arthur
Received on Friday, 20 September 2002 05:09:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT