[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RSS-DEV] Re: [syndication] Time for XHTML-RSS?
> The specific use case is providing a stepping stone for content
> developers to begin syndicating content. RSS 2.0 is too big a leap for
> many of them.
But ceasing creation/use of ill-formed HTML will be easier? You've GOT to be
kidding!
> I don't agree. Its minor work on the part of aggregator developers.
> Rather than processing the first element of an XML document as an RSS
> channel, they need to process the first channel element (or RDF
> equivelent) in the document. They don't have to check for valid html or
> do anything with the elements that are not RSS that they don't already
> do.
Bzzzt! The first problem will be the data not being well-formed XML. This is
NOT the trivial departure you're suggesting.
> The aggregators are all in flux now anyway, a good number of them
> are still in beta. Now is the time to adding a namespace to RSS 2 or
> embedd RSS in HTML .
They already support all this by supporting RSS-1.0.
> Whatever goes in RSS, goes in HTML+RSS. RSS aggregators simply find and
> RSS channel in an XML document and process it, just like they do now.
But you're assuming the tools they use to process the well-formed XML will be
able to process the undoubtledly malformed HTML that's going to be produced.
It's my estimation that assuming this will work is a SIGNIFICANT miscalculation.
> People building metadata rich applications should be using RSS 1.0.
> That is too big a step. People will cut their teeth on HTS (as I am
> currently calling it), progress to using RSS 2, then if their
> application warrants it, RSS 1.0. And I hope they will. But RSS 1.0 is
> out of reach of most content developers "too technical".
Wrong, wrong, WRONG. An RSS-1.0 feed is NOT too technical. It's just XML.
Where it differs from a 0.9x feed is merely in the use of a Seq container and
some attributes. Why people insist on perpetuating the myth of complexity is a
mystery.
> HTML+RSS is, in my opinion, how XHTML was intended to be modularized.
(rummages around for Pilgrim's 'why XHTML sucks' series...)
> Bandwidth increases will be marginal for most applications. For big
> documents, syndicators are going to realize their bandwidth costs are
> too high or their users are alienated, and drop in a script on the web
> server which returns RSS 2 or 1 when the user-agents indicates it can
> accept such, and HTML otherwise.
>
> Bandwidth may even go down. By having a single source, the users
> proxy-cache (most people with jobs are behind one) will likely have the
> document in cache when the user decides to navigate from their
> aggregator to the actual web page.
The number of aggregators that share the same caching tools as the browser is
NOT high enough to justify that defense. Most, like Radio, do NOTHING to share
the resources provided by the browser let alone the underlying OS. Some tools
(like .Net-based ones) can take advantage of this with no effort. Unless, of
course, the browser (like Mozilla) likewise ignores the OS level caching.
I'm saying readers don't use OS level caching. I'm saying browsers not provided
by the OS also ignore OS level caching. I'm saying RSS readers that ignore the
OS level caching also ignore any browser caching. Unless the user configures
all of them to use the same /external/ cache there's no benefit to be had. They
/should/ do this but most /do not/.
I happen to run Squid on my laptop and it does handle much of what you suggest.
I don't see it as terribly likely that the user community at large is going to
undertake the labors to install and manage their own proxy cache. They should
but getting them to do this is pretty far down the list of good ideas to beat
into their heads.
> Most agents request content only when its changed. So polling every
> hour isn't going to return a document every hour anyway. Many sites
> change every few weeks or only once a day.
> The leap from no syndication to the semantic web is too big for most
> people to get started. Even the leap to RSS 2 is too big for many
> people. I think HTS will be an acceptable stepping stone.
The leap only looks big when they're being misled by people.
-Bill Kearney