Lists Home |
Date Index |
Elliotte Rusty Harold <firstname.lastname@example.org> wrote:
| At 9:40 AM -0700 9/21/02, Dare Obasanjo wrote:
|> Search for the string "InnerXml" in the text at
| Thanks. Does this code work? If so, it's worse than I thought it was.
| I had assumed InnerXML worked with well-formed XML. It apparently
| doesn't. For example,
| channel.InnerXml = channel.InnerXml + "\n<item>\n<title>" + diaryTitle +
| "</title>\n<link>" + diaryLink + "</link>\n<description>" +
| diaryDesc + "</description>\n";
| Where's the end-tag for the item element? There's another case of
| this a little further on:
| channel.InnerXml = channel.InnerXml + "\n" +
| "<rss:item xmlns:rdf=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#\" " +
| "xmlns:rss=\"http://purl.org/rss/1.0/\" rdf:about=\"" +
| diaryLink + "\" >\n" +
| "<rss:title>" + diaryTitle + "</rss:title>\n<rss:link>" +
| diaryLink + "</rss:link>\n" +
| "<rss:description>" + diaryDesc + "</rss:description>\n";
| This time it's the rss:item end-tag that's gone missing,
Did you really expect better? Really, Elliotte, you have a big heart. :-)
I think it's important to understand that hideousies like this - which
indeed people will "use all the time" - amazingly enough make sense in a
certain kind of environment: where the costs of getting things wrong are
borne entirely by the receiving end - in a vicious parody of the "be
liberal in what you accept" philosophy.
If the receiving end is prepared to accept catfood - because of systemic
expectations, all too often a legacy of wowser experience for webchimps -
then it is inevitably "cost effective" to produce catfood - and nothing
better - with string-concatenated garbage like this. It's all hit or
miss, and maybe you're so l33t that you Get It Right most of the time, and
maybe you can make time-and-a-half after 5 o'clock, but you really don't
have to care. (The secret of a Big Company's success is the ease with
which its products facilitate cost transfer onto others.)
The trouble starts when the receiving end is not so accommodating - make
that, cost accepting.
I - or more accurately, we, as in a team - had precisely this experience a
while back. The project was a serverside middleware tool in Java, where
the output of the system would be XML files for a remote system that would
interpret them. One of my colleagues has a background in VB, is a truly
prolific coder, and tends to be impatient - which is OK because he does
manage to Get It Right most of the time. So, within the first couple of
days he had written some proof-of-concept code, producing XML output just
like the pointy bracket horrors above. As the tests got more elaborate,
the tangle worsened, swaths of escaped double-quotes and all.
Then came the day when a 300-line "printf" masterpiece bombed on the other
end with nary a helpful diagnostic. The remote interpreter only sniffed,
"input is not well-formed." So you want to go through the catfood to find
the dogfood? There had to be a better way. In the planning stage, I had
predicted this - actually, I had ranted about this - and said that we need
to build libraries, to guarantee rock solid XML. "No way", he said, "we
don't have the time, and we don't want to wait (for you)".
As usual, the only way we learn is the hard way, and I got to make them
"wait" for the libraries. When we were into alpha, he remarked "You know,
the learning curve wasn't so bad after all, and now that we're doing it
this way, I really have no idea what I was thinking back then."
A classic Tortoise and Hare fable:-)
| The underlying problem seems to be that this approach mixes up the
| view of XML as a tree of nodes and XML as a sequence of text. Either
| view makes sense. .
Actually, XML as a sequence of text makes sense only for editing apps.
SGML has a useful distinction between "structure controlled" and "markup
sensitive" applications. For the former, tag syntax should not matter,
and indeed does not matter. document.write()-ing *tags* back into the
environment is about as clue-challenged as it could ever get.
| Both views are useful for processing (though only the text is normative).
| But using them both at the same time is ultimately confusing.
For the receiving end only, it seems.
The day Microsoft makes something that doesn't suck is probably
the day they start making vacuum cleaners. -- Ernst Jan Plugge