W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

Re: final decision on well-formedness checking

From: Mark Baker <distobj@acm.org>
Date: Thu, 8 May 2003 00:43:01 -0400
To: xml-dist-app@w3.org
Message-ID: <20030508004301.C2273@www.markbaker.ca>

On Wed, May 07, 2003 at 12:49:07PM +0600, Sanjiva Weerawarana wrote:
> What was the final verdict from the discussion on whether a SOAP
> impl needs to do well-formedness checking? 
> I would prefer if one could respond with a non well-formed 
> response for bad requests such as those rather than to force every
> implementation to walk thru the whole message before doing anything.
> Streaming is dammed in that case.
> It seems to me that non well-formed requests are VERY unlikely
> (especially on TCP style streaming/reliable transports) except
> in the case of major SOAP stack bugs. Forcing well-formedness
> checking would cut out a major perf improvement opportunity to
> cover a case that's way off the 80-20 or 90-10 or even 95-5 split.

There are certainly lots of good reasons to do it, but as written, I
believe the spec requires well formedness checking, since it normatively
refers to the XML Rec, and XML documents must be well formed.

RFC 3470 also seems relevant here;

  The IETF has a long-standing tradition of "be liberal in what you
  accept" that might seem to be at odds with this recommendation.
  Given that XML requires well-formedness, conforming XML parsers are
  intolerant of well-formedness errors.  When specifying the handing of
  erroneous XML protocol elements, a protocol design must never
  recommend attempting to partially interpret non-well-formed instances
  of an element which is required to be XML.  Reasonable behaviors in
  such a scenario could include attempting retransmission or aborting
  an in-progress session.
  -- http://www.ietf.org/rfc/rfc3470.txt

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Thursday, 8 May 2003 00:40:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:23 UTC