[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RSS-DEV] Re: [syndication] Time for XHTML-RSS?



Bill Kearney wrote:

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.

I think that will be a matter of experience.  I am seeing a lot more
well-formed html these days.


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.

Not too technical for you (or me).

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.

I think RDF is super, and for situations where someone with the
slightest scripting skill  is available to generate RSS, RSS 1.0 is the
preffered format.  Its not too complicated to generate programmatically
even if one doesn't understand the RDF data model or why the same URI
shows up 3 times in RSS feeds.  Its just cookie cutter.  But RSS 1.0 is
hard to create manually, because the same URI shows up three times in
most feeds (see
http://web.resource.org/rss/1.0/spec#4.1 for an example).  How is anyone
going to generate RSS 1.0 if they cannot program?


The fact is, RDF is a graph that is easy to understand when presented as
a graph.  Trying to represent a graph in linear fashion as RDF or any
other serialization is going to be hard for people to grasp. Only
programmers, computer scientists, etc. should have to deal with a
serialized graph. A visual presentation of a graph is suitable for the
layperson, because RDF is simple.  Written linear text (i.e. english)
have the same problem as RDF, which is the motivation for concept maps.



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.

A large amount of the user community at large live behind proxy caches.
Right now, its mainly really keen web folks (I hate to use the word
"geeks") who use RSS, and we live right on the internet.  RSS
aggregators will move into the mainstream, and people will use them from
work, where their employer provides aproxy cache. The tools will evolve
to make more efficient use of resources over time, and customers demand
them.

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.

The leap only seems small to you and I because we understand markup and
software and scripting and so-on.  I presented on RSS to content
developers trying to express how easy it was to syndicate content.

I think being able to progress in leaps is important.  People start with
HTML, get feel, then learn CSS, unlearn table layout, learn xml.  Maybe
someday they will learn RDF.


-Bill Kearney


To unsubscribe from this group, send an email to:
rss-dev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



--
Doug Ransom
Hate spam & pop ups?  Try Mozilla for web/ëmail.  Its free.