[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: well-formedness error
On Sat, 19 Jun 2004 11:16:26 +0200, Asbjørn Ulsberg
<asbjorn@xxxxxxxxxxxxxx> wrote:
> On Wed, 16 Jun 2004 00:07:42 +0200, Bjoern Hoehrmann <derhoermi@xxxxxxx>
> wrote:
> > Or is this about whether implementations are required to reject
> > them as opposed to process the document up to the first well-
> > formedness error or attempt to process the entire document in
> > some implementation-defined way?
>
> It's about parsing and displaying the whole mess without issuing as much
> as a warning. This is supposed to be best for the user, I've heard.
That's odd. I haven't heard that, and I'm pretty sure I've read
everything that's been written on this subject in the past few months.
Where exactly did you hear that? Was it here:
http://diveintomark.org/archives/2002/08/20/how_liberal_is_too_liberal
"""If you want to evangelize within your program, I recommend doing
something like iCab does. When it encounters a page authored in valid
HTML, it puts a little green smily icon next to the address bar. News
aggregators could do something similar: try to parse the feed with a
real RDF or XML parser (and indicate success with a smily), and only
fall back to a more liberal parser if the strict parser failed (and
indicate this with a frown)."""
Hmm, I guess not.
I'm curious where you have read people advocating silently tolerating
well-formedness errors (other than on this mailing list, where a
surprisingly large number of alleged "draconians" have recently
advocated ignoring the very HTTP headers that parsers are required to
consider when determining the character encoding of a feed).
> I think it's much better to implement some sort of (mandatory) error
> reporting mechanism in the feed (or in an HTTP header) that the tool
> (automatically) can report parse errors to, but I'm pretty sure there's no
> consensus on that either.
http://boingboing.net/2003/02/20/why_i_hate_curlyquot.html
Apparently, some people already get enough manual hate mail from
draconians without your help automating the process.
> What's clear, though, is that we need to reach some sort of consensus on
> these matters, as the current situation is just a mess. No one knows what
> to say or do, and whether we conclude that Atom «MAY be well-formed XML»
> or «MUST be well-formed XML» is less important than that we reach
> consensus and conclude with something.
If the community reaches consensus that "Atom MUST be well-formed
XML", then I will acknowledge that consensus. But I will object
loudly if the community continues to try to redefine "well-formed", or
define some pseudo-standard of "almost-well-formed" so they can ignore
specifications they find inconvenient. Well-formedness includes RFC
3023; there is no middle ground.
--
Cheers,
-Mark