Yves Lafon writes:
>> Well, the intermediary will have first to understand
>> a message coming from a binding requiring knowledge
>> of XML 1.1 (or more) in order to recostruct
>> the infoset properly.
Agreed. I guess the reason I see this differently is that failure of two
nodes to agree on a binding is already an established failure mode in
SOAP. Similarly, failure of two nodes to agree on use of one of the
optional media types or encodings with the HTTP binding is an established
failure mode. In the case of the HTTP binding, you can >always< work
around this by using application/soap+xml and either UTF-8 or UTF-16.
Having a node that couldn't even store or manipulate the message,
regardless of the binding you might try to use, seems like a new failure
mode in SOAP, and that's why it feels architecturally deeper to me. There
is no binding in the world that I could write or acquire that would allow
me to successfully process an XML 1.1 envelope if my internal node, a
perfectly conforming SOAP 1.2 implementation, had a DOM, SAX, database or
other infrastructure that couldn't handle XML 1.1. Furthermore, and at
least as troubling, there is no fallback mode for already-deployed
instances of the SOAP HTTP binding that would reliably transmit the new
content, since the only form that (I believe) is mandatory today is XML
1.0. So, those are the reasons that I believe that the XML 1.1 change is
architeturally deeper than the lattitude we today allow in on-the-wire
formats for the SOAP HTTP binding. We can discuss on the call in a few
minutes. I hope I haven't missed something important in your argument.
Thank you!
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.