related links ›
(Page 2)
Then they should have kept out the front line while the web evolved. Most inventions come along with negative side effects. In their case now, that means costs for 8 GB daily traffic. Theoretically avoidable packets. But Withstanding such risks shows if a organisation can handle with the consequences of their own on-the-edge technology. Developers all over the world trust for several thousands of iconic files and artefacts to be kept up and running.
Taking that resource offline because of financial issues? Sorry, you cannot deal with your heritage.
Persistence of URIs and their resolution is only half of the story. The real problem is that we screwed it up when we made only the System Identifier compulsory in XML Document Type Declarations. By failing to make FPIs an alternative, rather than an adjunct, and by failing to make catalog resolution an inherent feature of XML, we bound ourselves to URLs (sic) for the foreseeable future, with all the attendant disadvantages.
There were lots of compelling reasons at the time for doing it the way it was done, but few of them were based in reality.
There were other mistakes: the dereliction of the ISO 9070 RPO Registry by the GCA (now IdeAlliance), the poor implementation of catalog resolution by most browser/editor authors, my own failure to persist in the project to build an FPI resolver using a suitable distributed registry model like ISO 11179, and the neglect of RSS 2 which led to the version I posted in August 2003.
None of which is going to change any time soon, but hopefully this is enough of a warning shot to developers to learn a little more about the technology before putting our products which break the model.
I didn't know anyone would still be using that DTD. It's so outdated. That's bizarre.
Eric: the difference here is that this really is a URL, not a URI, as it might be used in a namespace. With the DTD declaration, the URL really needs to be dereferencable so that a validating XML parser can access the definition.
Sean: you might want to read up on the (tortured) history of the RSS specifications. 0.91, 1.0 and 2.0 are not on a direct migration path. They are each standalone specs, and each is still in use somewhere.
Netscape: hosting this file is the price you pay for being a thought leader. If you are not willing to live up to the implicit contract you created with the community when you published RSS, then how can the community take you seriously in the future?
Perhaps rather than removing the DTD entirely, Netscape should gradually *degrade* it.
e.g. here's one strategy: Add a rule so that the webserver will only return the DTD 50% of the time. The other half of the time, it will return a text file saying "This file will be removed soon" with a link to an explanation.
Here's what I think the net effect would be:
1. Users would start noticing their RSS reader failing a lot.
2. They would be able to get it to work after a few retries, but it would be enough to be annoying.
3. Eventually a bug report makes it to the application developer
4. The app developer checks it out, sees that half the time the DTD it gets is invalid, and knows what to do immediately once s/he reads the content of the file.
That seems like a much more reliable way of getting the information out to all the relevant application developers. Probably more effective than Slashdot, anyway. ;-)
Those user agents don't need to validate the feeds they consume, but it's also their prerogative. There are plenty of other reasons for maintaining a canonical URI for a document type, even if it by now is pretty much deprecated. A record of the definition should live somewhere (and not in the internet archive, I mean!) persistently, if only because there are persistent and archivable documents (feeds) referencing it.
Have you thought about approaching xmlns.com to host it and putting a (properly executed!) permanent redirect header (301) at the original location? That way, everyone can be happy … eventually.
There is no reason this file should have to be hosted there, this is hot linking of a file that doesn't even need to be loaded, it's a rapacious and silly waste of bandwidth and the final decision should be made by Netscape and Netscape alone as they are the ones that are paying for the bandwidth.
The DTD should not be removed, it should remain available in perpetuity so that it is available for anyone that wishes to use it at any time in the future. Although, thanks to the wayback machine, it will always be obtainable by those who need it.
However, feed readers should never, ever need to request the DTD to read a feed, since they have no reason to be using validating parsers for XML. Those that do are broken and do need to be fixed.
Compare this with the HTML 4.01 or XHTML 1.0 DTDs at the W3C. They will never ever be changed, but the W3C will keep them available perpetually. Imagine what would happen if every browser requested those DTDs every time they loaded a web page. Thankfully, they don't, and even the HTML validators uses their own local copies.
My point is that DTDs should only be used by DTD-based validators. Although they should also cache their copies, they need to be able to request it if they don't have it.
Finally, if you do decide to delete it, do it properly. These 2 options would be somewhat acceptable.
1. Find a host who's willing to host it and set up a 301 MOVED PERMANENTLY redirect to it.
2. Configure the server to send a 410 GONE response and put a link to the copy in the Internet Archive. I don't they would appreciate a 301 MOVED PERMANENTLY response directly to the archive in this case because that would just transfer the 4 million useless hits every day to a site that wouldn't be able to handle it all that well.
New internet services from MSN Yahoo! and Google are here
See our explain and compare about new service or feature from three
search providers ; Windows Live (MSN) ,Yahoo! ,and Google. Learn
more and get it today. At http://searchprovider.awardspace.com/
Thank you very much.
Well, to alleviate the burden on Netscape's servers, and given that the file is pretty much baked, they could send the proper HTTP Headers in the response.
Here's what I got when I hit the file directly
HTTP/1.1 200 OK
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Content-Length: 7840
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Date: Wed, 31 Jan 2007 20:42:22 GMT
Content-Type: text/html; charset=UTF-8
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.4
Set-Cookie:
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Which means they really don't want anyone caching it... I'm sure that sending the proper headers would dramatically recude the number of requests made against the file.
Of course software should want to get DTDs for things like RSS if they are specified in a document its trying to read, i mean isn't that what they are for? it shouldn't fail though if it cant get hold of it as thats just a poor user experience.
More importantly though, if a DTD is going to be made available in a public forum, it should be assumed someone somewhere is going to use and rely on it, and as a result it needs a proper place to live. If netscape put this DTD out there then it needs to maintain it somewhere stable. Its much better if organisations get these standards adopted by an official body who is happy to maintain the DTD or make sure they have somewhere to put it thats specifically for that purpose. Its going to have cost associated with maintaining it so much better if an official organisation is willing to take it on.
The perils and responsibilities of contributing to the development of the internet I guess!
4:52PMChristian Schmidt
4,000,000 hits/day x 8 KB/hit ~ 32 GB/day
Assuming that Netscape pays less than 1 $/GB, the bandwidth costs are hardly the reason for not wanting to host the DTD.