Re: Summary of Issue 194 - encodingStyle

Henrik Frystyk Nielsen wrote:

>The fundamental question I am asking is why this should be part of the
>envelope when the envelope doesn't say anything about encoding? In
>addition, as we in general say nothing about the use of schema (or even
>which schema language), or however data may or may not be described then
>why should encoding be different?
>
We place the RPC declaration on the envelope because then descendants 
are not required to redeclare it.  It becomes the default without having 
to arbitrarily choose a default.  Declaring it there is like declaring 
the namespaces there so that they are in effect below.

I do not make your connection yet between being able to change in the 
middle of a graph and being able to specify it on the envelope.
           
The reason for having it is the same reason you may have xml:base or 
xmlns: declarations on elements which are not directly affected by the 
declaration.  It clearly does not affect the envelope, header, or body, 
but only the children, and then only in a way that could have been 
accomplished by explicitly specifying it elsewhere.

You can ask the same question about xml:base -- why should you be able 
to declare it on nodes where it may only affect the children.

>FWIW, I believe I said "Nobody seems to change encoding style in the
>middle of a graph" and not "nobody is able to change encodings in the
>middle of a graph".
>
Sorry, I really misrepresented what I responded to.  I was responding 
too fast.  At any rate, changing in the middle seems useful.

WRT B.  Our implementation clearly relies on the information and would 
be lost and unable to function without it.  It can be missing on the 
envelope only if and only if it is present on all blocks beneath the 
envelope so the decoder knows which encoding to employ to convert it to. 
 I realize that there may be others that are not so careful, but I think 
the care is not wasted.  The encodingStyle seems to be a critical clue 
about encoding and decoding issues unless you are going to hard-code to 
a single encoding or require other external measures, but it works well 
as-is.

When it comes to headers, we expect to even exchange messages which have 
some headers using the 1.1 default SOAP encoding and some using the 1.2 
default SOAP encoding in the same message, because the module in 
question was built on SOAP 1.1 or 1.2.

Ray Whitmer
rayw@netscape.com

Received on Monday, 22 April 2002 19:19:48 UTC