I just found out that Victor Wooten, one of my favorite bassists, has a bass and nature camp, and that he posts at least some of his lessons on the web. Cool!
Month: <span>September 2002</span>
The debate over the use of XML namespaces in RSS 2.0 continues — lots of links on today’s Scripting News. Here’s my personal take: RSS 2.0 must be backward-compatible with aggregators that support RSS 0.9x. On this, Ben Hammersley and I disagree. While I do understand the benefit of namespaces, I strongly believe that backward-compatibility should not be sacrificed.
Dave linked to the best solution I’ve seen so far from Don Park: “support namespaces but [don’t] require them to be declared unless they are needed and require only default namespace declaration to be used.” He speaks with the benefit of first-hand development experience with a partner whose software didn’t understand namespaces. He also quite rightly points out that “the primary value of RSS format is that it is being used widely and anything that breaks that voids the value of RSS.”
Simon Fell’s tests show that none of the popular aggregators fully support namespaces in RSS 2.0 and only NetNewsWire Lite supports namespaces in RSS 1.0.
I’m fairly certain that it would be pretty easy to make Radio’s aggregator properly not display items which are declared outside the RSS 2.0 namespace — I know this because Radio’s SOAP parser does this sort of thing. (Of course we would have to also make sure that if no namespace is declared, that the items are still picked up, otherwise we’d break compatibility with the 0.9x feeds.)
The thing is though, that the discussion of whether we’ll use namespaces at all may be academic, since non-namespace-aware parsers, if they don’t choke on the namespace declaration itself, wouldn’t be able to tell the difference between an rss:item and a licenseplate:item nor the difference between an rss:description and a ministryofsillywalks:description, so they’d break anyway. (At best they’d pick up items that weren’t intended for them, and at worst they simply wouldn’t work at all.)
I think it probably is worth the effort to add namespace awareness to Radio’s aggregator, since it helps to create a market for extensions, and all kinds of interesting things might be invented as a result. It’s also possible that extensions will appear but that lack of compatibility with non-namespace-aware parsers will bite their creators in the ass, limiting their adoption by content creators. For the sake of compatibility with non-namespace-aware parsers, extensions might simply avoid using any element names which overlap with elements defined by RSS, but then why do you need a namespace in the first place? (I know, I know — you can at least keep extensions from stepping on each other.)
In the long run, probably the only way to find out for sure is to add namespace support where we can, and see what happens next.
Update: Just to be clear — I don’t think Radio’s RSS generator should declare a namespace because we already know that this breaks some parsers, but rather Radio’s aggregator should be made to understand the namespace when it sees it. This is, I think, what Don Park is recommending.
Agree? Disagree? Click the comment link and let me know.
Comments closed
 |
Most Manila sites are dynamic sites — the pages are rendered from text, templates, and script code that resides on your Frontier server. When a web browser requests a page from the server, Frontier pulls all the pieces together, and churns out a page of HTML which is returned to the browser.
Pages in Manila sites can contain macros. Macros make it possible to include calculated elements in your web pages and templates, and many of Manila’s more powerful features build on macros.
Since Frontier’s deep scripting language has the ability to modify just about anything on your server, we provided a mechanism for specifying what macros are “safe”. Any non-safe macros are automatically “neutered” — their code won’t be executed when the page is rendered.
Frontier 9.0 introduces a new feature which allows server managers to add to the list of safe macros through the admin website. To make a macro safe just type its name and click a button. To remove a safe macro, check a box and click a button. Safe macros are available to all Manila sites, and indeed all dynamic sites, on your Frontier server.
Tomorrow’s screenshot: Server Monitor
Comments closed
Comments closed