Re: Summary of Issue 194 - encodingStyle

It is not true that "nobody is able to change encodings in the middle of 
a graph".  The Mozilla implementation of SOAP 1.1 clearly supports this 
-- I couldn't say it is well tested, but that goes for most features of 
that implementation.  It is architected for that, and it was easy to see 
how that type of encoding or decoding works.

In terms of architecture, our implementation both permits and honors 
encoding style changes in the middle of a graph.  Furthermore, it seems 
like it is important for modularity.  It seems likely that there are 
things a particular encoding will not be able to deal with, that might 
be borrowed from a different encoding, such as well-known parts, mime 
 edges, or edges that reference into other encodings.

I do not see the advantage in leaving it out, and while there area 
number of things I might be inclined to toss, that was never one.

Ray Whitmer
rayw@netscape.com

Henrik Frystyk Nielsen wrote:

>Following up on Gudge's proposal [2] and on at least one previous thread
>[3] I am wondering whether an alternative solution is to entirely drop
>the encodingStyle attribute. The reason why this may not be such a
>strange thought is that:
>
>A) Nobody seems to change encoding style in the middle of a graph
>
>B) Given the confusion of where to put it in SOAP/1.1, nobody seem to
>rely on the information but seem to get along fine without it
>
>It also seems somewhat strange that the attribute is defined as part of
>the envelope given that we don't say anything about encodings in part 1.
>
>Any reason for keeping it? Comments? Flames?
>
>Henrik Frystyk Nielsen
>mailto:henrikn@microsoft.com
>
>>At the last telcon I took an action item to summarize the two 
>>perspectives
>>on issue 194[1].
>>
>
>[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x194
>[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0150.html
>[3]
>http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/thread.html#171
>