Re: [i48]: encoding style { was [i47]: XML Protocol WG Issues list d iscussion }

David Ezell wrote:

> On Wed, 28 Mar 2001 17:05:44 -0500 (EST) Frank DeRose wrote [2]:
> 
>> ... I agree
>> completely with the statement Noah made in today's conference call: the
>> degree of interoperability XML protocol implementations achieve will be
>> inversely proportional to the number of encodingStyles that sprout up. 
>> ...
> 
Is this similar to the statement:

"The degree of interoperability XML processors achieve will be inversely 
proportional to the number of DTDs/Schemas that sprout up.

I disagree with both.  It seems to me that any particular service will 
require support for the particular encodingStyle relied upon by the 
service.  One would hope that for many cases, XML encoding is the 
choice.  It has served quite well in the past.  We do not expect a 
single implementation of an XML processor to full process all documents 
or even even those describable in a meta language.  I think it is also 
not realistic to expect a single SOAP implementation to handle all 
messages or for a single encoding style to handle all use cases.  What 
you get then is like legacy HTML with everything that anyone wants 
dumped in.  XHTML, on the other hand, is significantly modularizing 
things.  SOAP encodings should be seen as modularization for SOAP (yet 
another use of the term module).

While the RPC style of messages are favored for some circumstances, they 
clearly have significant drawbacks.  Making WSDL effectively the schema 
language might seem to ignore the reasons that markup languages have 
thrived on the web.  For enduring generic specifications the message 
needs to be the standard, not a specific object model that is hard-wired 
to the wire protocol in a way as unforgiving and potentially as 
proprietary as the binary exchange formats that came before.

>> The only question is how this happens. Should the XMLP WG define a default
>> encodingStyle? Should it simply adopt the one from the SOAP spec? Should
>> this problem be turned over to some other W3C WG, like the XML Schema WG? Or
>> should the W3C not get involved at all and let the marketplace sort out the
>> winner(s)?
>> 
>> Frank DeRose
> 
> 
> So, this is exactly the issue in i48 [3] and, depending upon your reading, 
> i47 [1].
> 
> To be clear, I do believe we should endorse encoding rules somehow.  I think
> we need to explore "how".  
> 
> If we can find a way to define how to identify the coding style (using
> the "encodingStyle" attribute sounds fine), and then suggest that the
> rules defined in SOAP/1.1 be used, we'll save what I think will be a lot
> of time and energy to redefine something (the SOAP encoding style) that:
> 
> 1) is already being used (and for those using it will possibly be non-trivial 
>    to change)
> 2) is already adequately defined elsewhere (in a W3C Note)
> 3) does not bear directly on the other parts of the specification which
>    arguably will require our full attention to bring to rec in the time
>    we have, and
> 4) is evidently controversial, so that what actually ends up in our
>    document (by the time we're done chewing it up) may well be different 
>    from what's already being used (i.e. SOAP/1.1), and thereby bring to the
>    fore the difficulties mentioned in #1
> 
> My hope is that we can avoid what looks to me like a rathole and still
> provide the desired interoperability.  I think the most contentious point 
> is:  what does "adequately defined" (#2) mean?  Can we simply point to the 
> W3C Note?  Or, do we need something more durable, like an appendix?
> 
> Clearly, creating widely usable encoding styles will be an ongoing and
> important activity within the XML Protocol Activity. 

I agree.  But it is also an activity for other organizations which have 
been expending quite an effort defining the business objects for 
inter-corporate ecommerce.  Does W3C want to become keeper of all these 
objects?  W3C already has a metalanguage for describing XML messages, 
which should be used.

The SOAP encoding style, using something like WSDL for interface 
descriptions, effectively seems to be an RPC encoding style with the 
potential to be one significant encoding style of many, perhaps part of 
the RPC module.  IMO, parts of that style which are seen as 
significantly broader than RPC, if they are not already borrowed by SOAP 
from Schema, should be seen as XML Schema requirements, not as SOAP 
encoding.

I think it makes sense to supply the SOAP encoding, but not to enshrine 
it in any way.  If it is to become part of the core XML Protocol proper, 
the spec must be insulated from it properly. 

Making it part of an RPC module seems like an appropriate way to 
structure it for me.  That way, users who consider the RPC style of 
messages that SOAP evolved from to be the one and only true way of using 
it can mandate the RPC module for their use cases, and those who see it 
as a necessary pollution of XML to bring along those who don't 
understand the role of generic markup languages on the Web to shield 
message exchanges from concrete objects can ignore it and produce 
message schemas.  If XMLP is going to be the stage for the final 
showdown between the extremes I have caricatured here, expect there to 
be winners and disenfranchised losers who will oppose the specification 
with very good arguments.

Ray Whitmer
rayw@netscape.com