Re: Proposal for an HTTP ERR method

Can I turn this round and ask the group how we can deal with the 
following problem?

The Atom group is writing a spec to be used for applications to be 
deployed by the general public. The general public is going to create 
Blog Feeds which are xml and place them on servers. These servers will 
very often have mime types set incorrectly, so that for example xml may 
be served as text/xml even though their encoding is not ascii. Even if 
the feed were served in ascii it seems that text/xml should only allow 
an application to read the data not to process it. Anyway there are a 
huge number of ways things can go wrong in subtle ways. Not only that 
but have found empirically that over 40% of current feeds in the real 
world are already broken.

The xml/http specs combined insist on the importance of refusing to 
parse xml content that is malformed. This I believe is a very important 
requirement. No one wants to go down the complex and tortuous road html 
went down. Indeed that is why xml makes such a strong case for not 
processing malformed content.

We have a specs that insist that one should not do certain things. Yet 
we know that the reality of the world will force feed readers to parse 
such broken xml.

	1- should we not use xml?
	2- should we specifically ignore some RFC as proposed in [1]	3- should 
we make specs that stick to the letter of other RFCs, but are 
impossible to follow?
	4- should we all work together to slightly alter the http and xml 
specs so that breaking the rules are allowed by clients if certain 
appropriate error reporting strategies are attempted?

	Sincerely,

		Henry Story

[1] http://intertwingly.net/wiki/pie/PaceShouldBeWellFormed

On 24 Jun 2004, at 17:04, Alex Rousskov wrote:
>
> On Thu, 2004-06-24 at 10:16, Henry Story wrote:
>
>> 1. There is consensus that automated error notification systems are
>> needed.
>
> On Thu, 24 Jun 2004, Scott Lawrence wrote:
>
>> I hear no such consensus.  I certainly am not a part of any such.
>
> Ditto. You may face fewer objections if you formulate #1 as
>
> 	"some automated error notification systems might be useful in
> 	some contexts".
>
> Alex.
>

Received on Thursday, 24 June 2004 14:50:33 UTC