- From: Ray Whitmer <rayw@netscape.com>
- Date: Mon, 22 Apr 2002 16:19:54 -0700
- To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- CC: Martin Gudgin <martin.gudgin@btconnect.com>, xml-dist-app@w3.org
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