W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Issue 192 & R803

From: Mark Baker <distobj@acm.org>
Date: Fri, 29 Mar 2002 13:57:35 -0500 (EST)
Message-Id: <200203291857.NAA06464@markbaker.ca>
To: noah_mendelsohn@us.ibm.com
Cc: chris.ferris@sun.com, rayw@netscape.com (Ray Whitmer), xml-dist-app@w3.org
> > I just re-read section 2, and didn't notice anything like that.
> My mistake, you're right.  Since we changed the interpretation of bodies, 
> there seems to be no requirement that a node do anything with a Fault 
> that's an immediate child of the body (since we give complete latitude on 
> interpretation of the body.)  I wonder whether we're comfortable with 
> that, but you are right based on the current text.  I still think it 
> wouldn't be an R803 problem if we did mandate interpretation as a fault. 
> Thanks.


Ok, so where does that leave us? 8-) Section 2 is fine.  The resolution
to issue 12 is fine.  That's good.  In fact, I'd say that there's
nothing in the spec, including the HTTP binding, that goes against the
chameleon view.  IMO, it's just what's *not* there that is my concern.

I raised issue 192 because I believe that the lack of any wording about
the priority of presence-of-a-fault vs. presence-of-an-application-error
will lead to interoperability issues, both between SOAP processors,
and also with underlying intermediaries (though I'm more concerned about
the latter).

So, as for issue 192, if we can't agree to get more specific text in
there to resolve this, how about some warning text about potential
interoperability issues, including the potential for the default binding
to not work well with HTTP intermediaries?  Or, as I mentioned before,
what about a separate HTTP binding?  I'd prefer the former, as it's less
work, but either would be ok with me.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Friday, 29 March 2002 13:52:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC