in reply to Fixing ill-formed XML

If I was feeling pedantic I'd point out that there's no such thing as "ill-formed XML". It's either XML (in which case it's well-formed) or it isn't XML.

But seriously, your best bet is to got back to the source and fix that. If it's a program that is in your control then fix the bugs in it. If it's an external data source then go bakc to the suppliers and point out that they aren't sending you XML as they said they would.

Whoever decided that browsers would "do their best" with invalid HTML was responsible for the nightmare of non-validating web pages that we have at the moment. XML is supposed to (partly) be a reaction to that. You can't be lenient with non-XML that claims to be XML. That way lies madness.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re: Re: Fixing ill-formed XML
by hossman (Prior) on Dec 19, 2002 at 23:31 UTC

    Whoever decided that browsers would "do their best" with invalid HTML was responsible for the nightmare of non-validating web pages that we have at the moment.

    It may seem anoying sometimes, but regardless of how forgiving browsers may be, people (and machines) will allways be faliable, and will allways make mistakes. Would you prefer it if browsers just refused to show any page with the slightest HTML glitch?

    Ultimately, the choice to "do their best with invalid HTML" can be traced back to the defacto mantra of the IETF... 

    Be liberal in what you accept, and
conservative in what you send.

    For more background, consult RFC791, RFC1122, and RFC1958,

[reply]
      Would you prefer it if browsers just refused to show any page with the slightest HTML glitch?

      Absolutely! If browsers didn't need to parse broken HTML, emulate stupid behaviours of old browsers and all that stuff then they would be smaller, faster, more stable and much easier to develop for.

[reply]

In Section Seekers of Perl Wisdom