Re: Toss section 5 (create SOAP-lite)

 Hi, please see my comments inside. 8-)
 I've removed the parts I'm not commenting on.
 There is a very important point in this message, so I've marked
it as ******Very important point******, so please don't skip it,
I know this message is long. 8-)

                            Jacek Kopecky


On Tue, 31 Jul 2001, Roger L. Costello wrote:

 > Bob Cunnings wrote:
 > > IMO a valuable purpose is served by specifying an
 > > encoding... It allows developers to escape having to
 > > develop their own!
 > Hi Bob,
 > Yes, I think that it is useful to have an "XML Schema type library",
 > comprised of commonly used components.  Then someone creating a SOAP
 > Receiver can take advantage of these XML Schema components in creating a
 > schema that defines the structure of a message (I shall refer to this as
 > the "message schema"). However, I seriously question that it is within
 > the scope of SOAP to be defining such a type library.

SOAP, and especially its application for RPC, needs such a
library, but it's not available yet and doesn't seem to be
available anytime soon, so that's why we probably shoud provide
the encoding chapter in SOAP.

 > [snip]
 > To summarize my points thus far:
 > 1. Call it for what it is - the section 5 encoding is just a fancy word
 > for defining an XML Schema type library.

This would probably be an "XML type library", not "XML Schema
type library", right?

 > 2. I believe that creating an XML Schema type library is outside the
 > scope of SOAP.

If it were renamed, it isn't necessarily out of scope for SOAP if
SOAP needs it.

 > 3. Mandating (making normative) a particular way of defining, for
 > example, an array is premature at best.  The marktplace will eventually
 > decide Best Practice for implementing arrys and such.  Certainly it is
 > reasonable for the SOAP spec to reference type libraries (such as the
 > type library that the XML Schema WG is building).

Making normative doesn't mean mandating, it can be normative and
optional. "If you want to use encode data, you MAY use the
following encoding, but if you choose to use it, you MUST follow
its rules."

 > Rich Salz wrote:
 > > By design, SOAP enables both structured-data and
 > > xml-document exchange. Just because you find the
 > > latter completely sufficient is no reason cut
 > > the bar in half. :)
 > Hi Rich,
 > I am not sure what you mean by "structured data".  Isn't data that's
 > organized using the XML syntax "structured data"?  I believe that what
 > you mean by structured data is an in-memory representation of
 > XML-organized data, such as a DOM tree.  When I speak of "XML documents"
 > I mean both physical XML documents and in-memory representations of
 > XML.  Regardless, in both cases the key issue is still: how do we define
 > the "contract" between the Client and the Receiver.  How, for example,
 > an array is represented in the contract (schema) is irrelevant at best,
 > and obfuscating at worst.

XML provides you with a tree of containers and strings. Most of
the programming languages have a notion of some other,
higher-level data structures. And references, too.

Before you say that we should free ourselves from programming
languages' concepts, I'd like to point out that RPC is completely
about programming. And even if you don't do RPC, your application
may already store its data in structs and arrays and it can
choose to communicate the data as such.

 > "Gaertner, Dr., Dietmar" wrote:
 > > Describing the encoding and usage of some of the
 > > datatypes for which the schema spec leaves too much
 > > room for interpretation is important, and, IMHO
 > > *belongs* in a spec like SOAP whose main goal is
 > > interoperability.
 > Hi Dietmar,
 > Why does it belong in the SOAP spec?  If there are useful type
 > definitions that the whole XML community can take advantage of then make
 > them public - put them in a public XML Schema type library.
 > I am mystified at how defining, for example, an array type definition
 > promotes interoperability.  A Client can interoperate with a Receiver
 > iff the Client sends an instance document to the Receiver which conforms
 > to the Receiver's message schema.  If the Receiver uses an array type in
 > his/her schema then the Client's instance document must conform to that
 > array definition.  It is irrelevant whether the Receiver uses an array
 > type defined by the XML Schema type library, or an array type defined by
 > Joe's Schema Emporium, or defined his/her own.  The bottom line is - the
 > Client's instance document must conform to the Receiver's message
 > schema.  That's how interoperability is achieved.  Interoperability is
 > not achieved by mandating the use of a particular array type definition.

 ******Very important point******
 The interoperability is not keeping the schemas, it's in mapping
the internal information in an application to the schema.
Speaking as somebody who has worked on SOAP and WSDL
implementations, I think that the main reasons for the various
implementations not being interoperable are as follows:
 1) The use of XML Schema for describing data structures - the
XML Schema language was written for validating XML document, not
for describing data structures. As a validating language, it puts
very few restrictions on the structure of the XML languages it
can validate. On the other hand the SOAP toolkits want to make
using SOAP simple and full XML Schema is not *simply* mapped into
the various programming languages.
 2) The section 5 doesn't show how its various structures are to
be described in an XML schema, so everybody describes the
structures as they will and building simple automatic WSDL tools
is very hard to do, resulting in such drastic measure as the
soapbuilders Interopathon - a face-to-face meeting where various
implementations were tweaked to interoperate with the others.

 So I think that we should either use a good-enough XML Schema
type library (which is unavailable unfortunately), or define an
encoding _and_ specify its mapping to and from XML Schema.

 > > Finally, precisely describing the encoding of
 > > structured data (which also map well on structures
 > > found in popular programming languages) ...
 > Ah that's the problem!  We need to abstract away from programming
 > languages.  SOAP is independent of programming languages.  SOAP should
 > be concerned with organizing data in ASCII text documents.  In my mind I
 > see SOAP as giving the world the opportunity to achieve messaging by
 > thinking in terms of data rather than programming.  I feel that it is
 > important that the Protocol WG resist the temptation to keep messaging
 > down at the coder's level.  Forget the 'how' of programming languages.
 > Think the 'what' of data.

Please see above. If you want to have messaging in terms of data,
your data still have some kind of structure. Certainly an SQL
table is different from an object graph. If you use SQL databases
as SOAP endpoints, you certainly don't want to do transformations
on the data, but if you use structure-oriented applications as
the endpoints, you might welcome a standard encoding. RPC, for
instance, comes from a structure-oriented environment and it's
proved to be a useful technology.

Received on Thursday, 2 August 2001 12:19:40 UTC