Re: Summary of Issue 194 - encodingStyle

 Ray, 
 I'm sure Henrik will reply, too, but I have a few things to say.

 1) We cannot compare the namespace declarations (or xml:base) 
with encodingStyle attribute because both namespace declarations 
and xml:base are only used where requested (by a prefix or by a 
relative URI), whereas this "where requested" is not at all clear 
on encoded data; it's clear where you need to know the binding of 
a namespace prefix, but how do you know from some data that it's 
supposed to be encoded or not?

 2) Changing encoding in the middle of a graph does indeed seem 
useful, but I have yet to see a clear case where it's necessary 
_and_ it cannot be done without the encodingStyle attribute. This 
is related to the following.

 3) Any implementation has to know what encoding is used if it 
wants to help the application by not handing it the raw XML data, 
that's true. But the usual case is that the application knows 
what kind of encoding (well, data model in fact, but I don't 
expect multiple similar encodings for a single data model) the 
data should be in in the various places where data is expected. I 
don't know of any application that does care about encodings 
_and_ does not know what kind of data it's going to get.
 So instead of the encodingStyle information coming from the 
message, it can come from the application. Moreover, in the 
strongly typed languages you cannot deserialize any kind of 
object into any kind of holder, like when switching to a "raw 
xml" encoding from SOAP Encoding, you'd deserialize into a DOM 
tree but it wouldn't fit into the holder for a HashMap, for 
example. In this approach, errors in data (encodings) are 
discovered when deserializing, not long after that or even never.

 Oh, and I believe that by "being part of the envelope" Henrik 
meant that the attribute is defined in the SOAP Envelope 
namespace, not that the encodingStyle attribute is placed on the 
Envelope element II.

 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Mon, 22 Apr 2002, Ray Whitmer wrote:

 > 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 20:21:49 UTC