badly formed

Comment on badly formed by Michael Lucas-Smith

When it's company dealing with company, you can expect well formed XML. When it's some public offering made by joe blogs.. well.. good luck :)

Trackback from 42

Smalltalk Tidbits, Industry Rants: badly formed

Between Smalltalk Tidbits, Industry Rants: badly formed and The real value of XML is wellformedness | 2004-06-20 | BitWorking we seem to have a faily fundemental disagreement. Yet to me it is not so simple (seems I am in a...

actually, i like the well-formedness.

it gives me either the (more-or-less) expected result, or the parser barfs.

admittedly, i never even tried to handle third-party xml off the wild wild web. what i use it for is to store stuff in databases or to post-process xhtml fragments coming in from said databases (or from somewhere else). i find having all data well formed at all times makes things much easier. it gives you an error when the data enters the system, not months after the fact when you have to make sense of some free-form ad-hoc encoding scheme. also, i am trying very hard not to mention html or sgml here ... but the ease of parsing and lack of ambiguity (is this a word? not my native language) makes xml very attractive to me.

and while i am on a rant, let me mention that i hate xsl(t). dsssssssl (i just can't stop spelling it) was better than that. half an hour's effort in perl (and i hate perl) could give you something better than xsl. but then i guess the concept is flawed. they try to give you the flexibility of an actual programming language without giving you an actual programming language. "but it's xml parseable". so what?

everybody think of clowns and glowfish now. go on, there is nothing to see here

the following is my poorly formed xml, please resolve it:

ebh9hjÅBN M´32QERAG

Obviously there is a level in which no malformed xml can be reformed, the problem is that in reforming you are also running a risk of reforming wrong (the chance of a document being well-formed but still well-formed incorrectly strikes me as being less than the chance of a document being malformed and when you reform it you reform it incorrectly), depending on your application, and on how mission-critical data is, reforming can be highly problematic. I don't see a problem with a feed processor going ahead and logging errors and proceeding, but the way you have phrased your argument seems to suppose that what works reasonably well for your domain is the way that should be used for all domains using xml, which is at the moment causing me to have a very bad reaction to this bad coffee I'm drinking.

If you actually read the post, it becomes apparent that the problem arose due to software from a developer with a track record of encouraging malformed XML and an inability to deal properly with character encoding issues. If this developer had used a real XML parser in the first place, rather than hacking together some poor code based on string manipulations, the problem would have been caught early and fixed. Checking for and requiring well-formedness is a critical part of making sure broken systems fail as early and as fast as possible, where it's easiest and cheapest to fix them.

If RSS parsers, editors, viewers, and other tools all required well-formedness, there would be a lot less malformed RSS in the world, and what little did escape into the wild qould quickly be detected and fixed. As it is the problem feeds on itself in a vicious cycle.The more malformed XML is accepted, the more malformed XML is generated, and the more malformed XML must be accepted. This only increases costs and trouble for everyone to nobody's benefit. This is exactly the sort of problem draconian well-formedness checking was designed to prevent; and it is the sort of problem only draconian well-formednes checking can fix.

Comment on badly formed by James Robertson

Elliotte,
   You say:

"The more malformed XML is accepted, the more malformed XML is generated, and the more malformed XML must be accepted. This only increases costs and trouble for everyone to nobody's benefit. This is exactly the sort of problem draconian well-formedness checking was designed to prevent; and it is the sort of problem only draconian well-formednes checking can fix. "

In the feed arena, we are talking non-critical, consumer oriented data. Which means that tools will naturally tend towards compensating for bad data. In the B2B space, I rather expect that things would tilt the other way - reject any malformation, because it's not appropriate to "guess". In the consumer space, with content meant for reading, it's entirely appropriate to guess and do whatever you can to present information to the end user.

I guess it can be considered an improvement.

XML, like other formats, can fail due to garbled or badly entered data. But with other formats, each format will fail in its own special way.

At least with XML, the errors are more predictable, and error handling can be more easily standardized, with some of it done by libraries you didn't have to write.