by Mike Levin SEO & Datamaster, 10/16/2005
The problem is not in preserving the data. The problem is in how finicky XML parsers are. And generally, you’re going through a client-side XML parser, like MSXML or its equivalent when you’re programming Ajax. This is fine for controlled data. But even with CData blocks that are intended for just this purpose, problems still occur. Now with FireFox, we as developers have at least two browsers to hit the XML Web Service with directly. It often times takes both to debug. MSIE will show you a line of the XML up to where the error occurred, but not enough to see it in context. FireFox will show you the whole XML structure, even though it reports that it doesn’t conform, but it doesn’t highlight the error.
Changing the encoding directive (the first line of the Web Service) around doesn’t help much either, because the problem is that random log files have mixed encoding. So, you have to start playing around with conversions and filters. In some cases, there is no clue on the URL that can help you preemptively filter, such as the Google ie parameter, which I’m sure is mistaken for Internet Explorer, but surely means something-encoding. But without such clues, it can become hit-or-miss. I’m looking for a way to just chop out everything that’s in the current encoding mode, but without having to check for every condition (ideas?). Happily, you can essentially see the results live as you experiment, if you have Ajax fetching from the data source on a frequent basis. Anyway, this was blogworthy, because while this particular experience may be common enough for developers of data monitoring systems, it’s a novel and welcome experience from a Web developer perspective.