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

I am happy to see this issue is getting the attention it deserves.  I
would like to suggest that we discuss the soap encoding section at least
in some details.  This could happen right here on the mailing list.

Regarding the points that Noah made during the telecon.
Noah suggested that the soap encoding section is needed because RPC is
modeled as a struct, and the soap encoding section contains the
definition of a struct.  By contrast, the XML schema does not define a
struct.

My thoughts are: even though RPC is modeled as a struct, it's not
apparent to me where that comes into play when either providing an
implementation of RPC using soap or writing an application that uses
RPC.

What am I missing?

Marwan

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.
> >...
> >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.
> 
> Best regards,
> David Ezell
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0166.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0262.html
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0167.html

Received on Thursday, 29 March 2001 09:16:14 UTC