Forum Moderators: open
Syndicated feeds are wildly popular, but they're not a success for XML. XML on the Web has failed: miserably, utterly, and completely.[xml.com...]
I read this article with interest - basically, it says that XML on the web doesn't work because of character encoding issues with serving XML over HTTP, and that as most XML content currently available client-side (in particular, RSS feeds) are usually invalid, and the tools don't follow the XML specs in terms of error handling. Of course, it doesn't go into server-side use of XML subsequently transformed into another format (eg. HTML) for the end-user.
So do you agree with the sentiment, or is XML really a failure on the web?
Also, there are so many xml feeds out there that aren't validated against a DTD or Schema.
Now, xml/xsl client-side, well let's not get into that. That is utter faliure right there.
<added>
I do believe that XML has made great improvements to online systems such as travel. Especially in the realm of affiliate marketing, if you have a good xml feed, then things are great.
The beauty of it is, I can have an application that is built in Java, but then have another program interface with it.
XML is portable across systems. It's great!
</added>
application/xhtml+xml is helping to kill XML-style XHTML too. The latter is probably a blessing in disguise because of the same reasons XML/XSL is failing now - it's the wrong cure for a non-existent problem (draconian failure-handling is crazy client-side - one false move and your page is completely inaccessible). However, I found the total rejection of XML on the web in the article too generalistic - as you said, XML is great server-side and machine-to-machine as a cross-platform solution to data sharing and transfer.
(draconian failure-handling is crazy client-side - one false move and your page is completely inaccessible)
I disagree, strongly. Life would be so much simpler if people expected pages which have illegal syntax (i.e. things not properly closed or closed in the wrong order) to not render. I attribute the need to deal with buggy code as being one of the major contributing factors to browsers getting bloated, more resource intensive, and downright buggy. There should be no need to deal with ambiguity.
Change the old saying from "be strict in what you send and relaxed in what you receive" to "be strict in what you send and strict in what you receive"
Ian
We now automatically normalize all incoming feeds and to strip out the garbage and then we re normalize on our feeds just in case our systems miss something.
[edited by: tedster at 9:03 pm (utc) on Aug. 10, 2004]
There should be no need to deal with ambiguity.
I recall an interview with an IE developer that covered this issue. From the browser developers point of view; you have to deal with ambiguity if you want your browser to either gain or maintain significant market share.
Your "average joe" knows absolutely nothing about what goes on behind the scenes when they type in a website address. If a web page does not display correctly they blame the browser in exactly the same way that they blame their television set when they can't get a picture.
You are using XML, but not treating it as such - a true case of ideals versus the real world. In a technical sense, you are wrong to parse invalid feeds (because it is against the specification), but in reality, you are working around the errors and displaying the results anyway (you've got a business to run, after all).
This joins dmorison's comment from the IE developer: XML was supposed to force well-formedness everywhere because HTML was seen as encouraging invalid markup - but in reality, "tag soup" XML is thriving.
The IE developer is right - if XML client-side were to take off, a browser which broke the specification and displayed malformed XML anyway would take the lions share of the market, because in the real world coding errors can happen even when you are trying to keep things valid, and users just want the information. Those who consider that 100% validation all the time is possible don't tend to have any experience of running a site with third-party markup (from banner ads, for example), user comments (causing charachter encoding errors) or any kind of interactivity.
Now, I do know of a site (before it was bought out...) that was great. It actually used xsl for the whole site, client side. I don't know how they accomplished it, but it sure worked.
However, I found the total rejection of XML on the web in the article too generalistic - as you said, XML is great server-side and machine-to-machine as a cross-platform solution to data sharing and transfer.
I heartily agree with this statement. Machine-to-machine communications can and should be expected to follow standards and validate properly. XML is an excellent format for this type of communication. I don't see it being dropped for another format anytime soon.