Slashdot Mirror
Netscape Restores RSS DTD, Until July
Randall Bennett writes "RSS 0.91's DTD has been restored to it's rightful location on my.netscape.com, but it'll only stay there till July 1st, 2007. Then, Netscape will remove the DTD, which is loaded four million times each day. Devs, start your caching engines."
Developers who made the mistake to use that external resource in their code most likely don't have the brain resources to adapt until July.
(This is not a troll. Resignation and bitterness, maybe. But not a troll.)
Netscape Restores RSS DTD, Until July - from the that's-kinda-lame dept.
Two Stargate SG1 Films Announced - from the good-for-them dept.
Linux: x86 Linux Flash Player 9 is Final - from the i-still-hate-flash dept.
Looks like somebody is having a case of the mondays.
(On Wednesday.)
And any dev who codes his app to check a file like this every day instead of caching it client-side should be smacked oh-my-god-so-frickin-hard.
Great, the entire internet community can rely on one random person's server instead of on one really big corporation's server. That should fix things.
Don't blame me; I'm never given mod points.
Developers use off the shelf XML parsers, which generally take care of validation for you. Netscape created this problem themselves when they stated in the spec for RSS 0.91 that well-formedness was not enough, RSS 0.91 feeds should be validated against the DTD. They then specified that document authors must use a PUBLIC doctype specifier, so the option of using a SYSTEM one (where the DTD is looked up in a local catalog) is not an option.
One line blog. I hear that they're called Twitters now.
As I replied for the previous Netscape RSS DTD article http://slashdot.org/comments.pl?sid=216818&cid=176 03480, caching DTDs from the network is not the answer if there is the possibility they will not be there in the future:
/ resolver-article.html that helped me out. In addition, if you are using Eclipse with the web tools platform, you can customize the catalog so it resolves DTDs and entities locally. See http://wiki.eclipse.org/index.php/Using_the_XML_Ca talog.
The proper thing to do is for your application to use an XML catalog for resolving entities/URIs and bundle the DTD files with the application. There is a good article at http://xml.apache.org/commons/components/resolver
(I tried posting this as a reply to the blog posting, but I'm not getting the confirmation email, so I'll post it here)
From a purely technical standpoint, I agree with your assertion that, for well-baked files like RSS DTDs, clients should not be relying on a file hosted by an arbitrary service.
That being said, please understand that the emotional message you're sending is: "Don't rely on Netscape".
Why?
Back when RSS was first starting out, Netscape's documentation said to use Netscape URLs for the RSS DTDs. Witness this page, published by Netscape, from late 2000:
Now, a shade over six years later, Netscape is saying "Oh, yeah, what we told you to do? Never mind. We're not supporting it any more."
If Netscape/AOL was shutting its doors, that'd be one thing. If the service in question was obviously onerous, that too would be understandable. Or, if Netscape told people "For the love of all that is holy, don't use our URLs for your DTD needs!" from the get-go (based on that document, you didn't), any such reliance would be our own fault.
But, because AOL does not want to serve up two static files, each of which is smaller than the "Netscape Reports" graphic on the netscape.com home page, Netscape is abandoning a service they told people to use.
So what are we to think about Netscape's current services and their long-term usability?
The Busy Coder's Guide to Android Development
But you waited until (UID 633928) to register on Slashdot?
Newbie.
Reality has a liberal bias