W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

RE: [SOAP Encoding Issue] Most to least specific encodingStyles,HOW?

From: Andrew Layman <andrewl@microsoft.com>
Date: Thu, 13 Dec 2001 10:28:58 -0800
Message-ID: <C3729BBB6099B344834634EC67DE4AE102623C41@red-msg-01.redmond.corp.microsoft.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC