- From: Andrew Layman <andrewl@microsoft.com>
- Date: Thu, 13 Dec 2001 10:28:58 -0800
- To: <xml-dist-app@w3.org>
Regarding "BTW, I only just realized one way the current specification could be useful; the sender could refine Sec5 encoding to indicate that no strings are shared (e.g., pointer_default(unique) in DCE/COM, or "noalias" in an ANSI C draft). " That is the intention of the current rule allowing several encoding URIs to be listed. The logic is also similar to the recent decision to allow a list of fault codes, all indicating the same fault, but some more general while others more specific. Re "I still think it's too complicated to deal with, since you can get mostly (exactly?) the same effect by using the "official" encoding URI as a prefix (last half of penultimate paragraph of 4.1.1." That paragraph says "in addition, all URIs syntactically beginning with "http://schemas.xmlsoap.org/soap/encoding/" indicate conformance with the SOAP encoding rules defined in section 5 (though with potentially tighter rules added)." If we expect that there will be encodings conformant to section 5 but with additional rules added, then we face the following choices: 1. Forbid all encodings except section 5. 2. Provide no means to indicate to a reader that a new encoding is also decodable using a section 5 decoder. (If so, I expect that private, non-standard means will be invented.) 3. Use the rule of that penultimate paragraph of section 4.11. This works, but has the drawback that it assumes that the inventor of the new encoding is also the domain authority for http://schemas.xmlsoap.org/soap/encoding/. That is, it conflates subtyping with authority, a condition that we have avoided elsewhere. 4. Use the rule that the encodingStyle attribute may list several encodings, all of which are effective. Whether number three or four is harder to implement is debatable, but I lean towards thinking four is easier. Microsoft initially implemented number four. We removed number four from our message generation when we discovered that significant other SOAP implementations had trouble decoding such messages. I hope this analysis is helpful.
Received on Thursday, 13 December 2001 13:29:30 UTC