Re: Toss section 5 (create SOAP-lite)

Hi Folks,

Thanks for all the excellent comments.  I have carefully reviewed them
and have some followup comments.  Rather than responding to each message
individually, I respond to all the messages here:

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. 

> Also, it provides a important common ground for
> interoperation of independently developed 
> applications

I have a hard time seeing how the fact that you and I are using, for
example, the same array component definition will promote
interoperability between us.  On the other hand, if we are using the
same schema then I can see how we can interoperate.

> Even if buried in an annex to the spec, a normative 
> encoding goes a long way to facilitating the adoption 
> of SOAP, especially for RPC applications.

Certainly an XML Schema type library will help build XML Schemas.  An
XML Schema type library will benefit the entire XML community, not only
SOAP users.  I find it unappealling to mandate that SOAP users "must
implement an array this way, must implement a linked list this way,
etc".  If it were placed in an annex, then I do not believe that it
should be normative.  (Again, I believe that it does not belong in the
SOAP spec at all.)

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.
2. I believe that creating an XML Schema type library is outside the
scope of SOAP.
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).

David Fallside wrote: 
> The WG Charter [1] motivates our work on such a 
> section, exactly for the type of reason voiced by in 
> [2]. If the length and complexity of Section 5 is an
> issue, what do you think of the suggestion in [3]?

Hi David,

See my comments above.

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.

> So yes, I'd say it's a naive comment.

No doubt, but thanks for listening anyway.  :)

"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.
 
> 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.  
 
> end up with many different interpretations and implementations.

Bottom line: The only interpretation that matters is the XML Schema and
semantics that the Receiver defines.  If a Client doesn't conform to the
Receiver's schema then there is no interoperability, regardless of what
SOAP-standardized types the Receiver may employ.

> One can like or not like the SOAP Arrays, but they are 
> clearly defined. 

If SOAP has a definition of arrays then give them to the XML Schema WG
to add to their type library.  But don't mandate SOAP users use it.

My 3 cents. /Roger

Received on Tuesday, 31 July 2001 09:40:45 UTC