[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On RSS, Community, Extensibility, and more...
Howdy,
This seems an apropos spot to wander in with some thoughts I've been having
along these lines. These thoughts are my own, mind you, and should not be
construed as representing the opinions of any group/faction/flavour.
I've cc'd the [Syndication] list since these thoughts tie together
conversation[1] occuring on both lists. This is not a short note, but I do
ask that you bear with me as I believe it covers some important ground.
James Shaw wrote[2]:
> Here's a question that's undoubtedly controversial - and I'm only
> half serious in asking - presuming that aggregators ignore unknown
> elements, I *could* just add some new elements to a 0.92 file for use
> by my "closed loop" of publishers and directories. Losing the
> rdf:about's would be a big saving, and publishers would still get the
> added value of having a channel to submit to RSS aggregators.
Controversial, yes. Out of left field, certainly not!
This practice, in fact, was what first prodded me to dive into the extension
of RSS in the first place. I'd observed a couple of behaviours resulting
from RSS's lack of extensibility:
a) Overloading
Folks were (and still are) overloading RSS 0.91 elements to the point
where one is almost forced into the abominable situation of "screen-
scraping" their favourite RSS feeds to either get at this valuable
'extra' data or remove the clutter. A simple example is Moreover's
RSS 0.91 feed, throwing ource and Date into the <description>
element:
<item>
<title>Sequenom, Gemini Genomics in merger pact</title>
<link>http://c.moreover.com/click/here.pl?r19754647</link>
<description>
AP via New Jersey Online May 29 2001 12:29PM ET
</description>
</item>
And they get far worse than that
b) Ad Hoc Extension
While inherently a harmless activity given that the majority of
RSS readers, aggregators, and other tools ignore what they don't
understand (read: optional elements/attributes), this does doesn't
exactly do wonders for interop. One person might create an ad hoc
<source> element containing the URL of the original source of the
story. Another might use <source> for the proper name of the news
source and <source_url> for their URL. What's an RSS reader to do?
In the early days, Meerkat actually had filters for some of these
as I ran across them, mapping <keywords> in one feed and <topic>
in another to its own <subject> field. Ick!
Dave Cantrell wrote[6]:
> While I can't speak for the RSS-DEV group in any way, I personally
> don't see what the problem would be with using 0.9x and adding your
> own extensions via namespaces. I mean, isn't that what the namespaces
> thing is all about? Is there some deep dark magic I'm missing that
> would prevent this, or would otherwise break existing usage?
My initial strawman for the progression of RSS back in May/June, 2000[3]
proposed 3 simple requirements that might go quite some way to affording
RSS extensibility without more than replacing one already required text
attribute with a URL and allowing for optional extensions, ignoreable by
those who don't understand them.
* Extensibility without need of iterative modifications [and
centralized agreement thereon] to an RSS core specification.
* Backward compatibility with existing RSS (currently 0.91) easily
accomplished with the the simple requirement that core RSS parsers,
modules, and libraries ignore what they weren't built to understand.
* An effort toward interop with a set of community-built modules
providing the functionality required most of the time by folks.
Anything else can be done on an ad hoc basis.
I built a simple modularization demonstration[4] to aid visualization.
The gist is of it is simply changing:
<?xml version="1.0"?>
<rss version="0.92">
to:
<?xml version="1.0"?>
<rss xmlns="http://backend.userland.com/rss092/";>
That's it! While retaining the simplicity of RSS 0.9x, you've opened the
door for folks to extend it (whether working as a group or individually) to
meet their applications' needs. Current users happy with simply doing
headline syndication have only one tiny change to make (and there are ways
around even requiring that). Advanced users can modularly extend to their
hearts' content. And everyone else "in the middle" can start simple and
have their RSS evolve with them.
For example, borrowing a page from Slashcode:
<?xml version="1.0"?>
<rss xmlns="http://backend.userland.com/rss092/";
xmlns:dc="http://purl.org/dc/elements/1.1/";
xmlns:slash="http://slashcode.com/rss/0.92/modules/Slash/";
>
<item>
<title>Javascript Banner Code Error in Header Block</title>
<link>http://slashcode.com/article.pl?sid=01/05/26/1755254</link>
<description>a description</description>
<dc:creator>Krow</dc:creator>
<dc:subject>slash</dc:subject>
<dc:date>2001-05-27T12:06+00:00</dc:date>
<slash:section>askslashcode</slash:section>
<slash:comments>7</slash:comments>
<slash:hitparade>7,7,6,1,0,0,0</slash:hitparade>
</item>
...
(This example is borrowed from Slashcode's current RSS 1.0 module)
Slash have here borrowed some common elements from the Dublin Core (15
common ways to describe a thingy): creator, subject, date. And then they've
created their own slash module with home-grown elements: section, comments,
hitparade.
And all it took was a couple more declarations at the top, associating the
shorthand dc with Dublin Core and slash with the Slashcode module. So, what
slash:comments really says is "there are 7 comments (as defined by
Slashcode) on this item." And dc:subject says "the (dublin core defined)
subject of this item is 'slash'." No muss, no fuss. No complex syntax.
And no need of RDF.
And those tools not understanding the particular modules at hand or even
namespaces themselves simply sees:
<item>
<title>Javascript Banner Code Error in Header Block</title>
<link>http://slashcode.com/article.pl?sid=01/05/26/1755254</link>
<description>a description</description>
</item>
> I extended RSS with a custom namespace to allow us to embed extra
> information (such as time and location of the event, etc).
> This IMO "stretches" the original RSS intent a bit, but it works (a key
> argument from the standpoint of the 0.9x crowd).
RSS _is_ being stretched, whether by individual users or those coming
together for an updated version. Making provision for this is a good thing.
Ignoring it or attempting to pack the core of RSS with all the bits and bobs
everyone wants dooms us to a centrally governed, bloated core and gets in
the way of just getting our jobs done.
Now it seems you two and folks like you are caught in the middle here.
Extensibility is key to your using RSS in your application, but you'd rather
not have to buy into the whole kit, kaboodle, and RDF model of today's RSS
1.0. I understand that completely and very much want to find a middle
ground here on which to build. Contrary to what you might have heard
regarding my motives, "it just works" has always been key to me.
On the RDF front...
Yes, the syntax is a little less than georgous for the uninitiated. Yes,
the syntactic sugar added to 0.9 to make it fully RDF compliant can get in
the way of a good read. But the RDF model is powerful, sound, and, in
concert with RSS, can bear some intriguing recombinations and applications.
I'm more than thrilled RSS 1.0 took this path and look forward to its
contined evolution.
On to the [Syndication] bit... (I promise this note will end shortly, really
:-\)
Dave Winer wrote:
> 1. Having two RSSes is killing RSS.
We agree and disagree here. On the one hand, yes RSS's current split
personality can be confusing and offputting to beginners and seasoned
users alike. I also believe that perhaps another huge factor is that
neither format captures the needs and levels of understanding of the
majority of users, across the board.
On the other hand, RSS and reformulations thereof is cropping up
_everywhere_, from Ximian's Red Carpet to Slashcode to Take23.org's RSS 1.0
based portal, to desktop aggregators and desktop integration. It already
had great breadth, and for this I credit your evangelism completely; now it
is gaining some depth and finding itself novel uses.
And, if you'll permit the Tevia-ism, on the third hand, the single thing
that's wearing on RSS is the partisanship. Scarcely a proposal can be made
or element questioned without an eruption. Sure, compartmentalization of
discussion helps a bit, but do we really need the confusion of 3 (or more)
lists, the exclusion of particular folk from participating in discussion,
and constant lobbying on all sides... at the expense of understanding and
the uninitiated?
Overall, though, I think we agree.
> 2. None of the confusion from April of last year has abated, imho it's
> much more confusing today than it was back then.
Yes, it is much more confusing today, but a little less so than a few months
ago. On the subject of last April, I actually don't understand why you'd
call that time confusing. We were all talking on [Syndication] about
possible directions for RSS. I gave you a ring and we talked at length on
the subject. I followed your advice and formalised my thoughts, initially
with a strawman, followed by a visual demonstration and spec(ish). This all
culminated in the RSS 1.0 proposal.
Yes, there were some confusing bits, but I don't think we really want to get
into those here.
All in all, one thing has become remarkably clear. We need to find a middle
road. Not you and I, but we as a community of users. There's been so much
good work done on all sides. Instead of repeating efforts, we should find
those cross-links and build some bridges.
> 3. Since you and I are the two people who could do the most to abate the >
confusion, I suggest that you roll up your sleeves, as I am willing to
> do, and let's solve the problem.
I've always been willing to roll up my sleeves and work on resolution. As
for solving the problem, that will take much input from all sides.
> I made a proposal in a subsequent
> message. It would be helpful if you gave it some thought and responded
> publicly, preferably on this list.
Let's take a peek[7], shall we...
> 1. I will stand down as the defacto leader of the simple approach to RSS,
> I'll just be another user of RSS, making proposals, and looking for
> input or agreement with others.
I have to agree with Morbus here; I just don't see this happening. The only
way to assure this seems to be:
1. The establishment of some sort of governance as we've done on
RSS-DEV[8]. Please don't dismiss these out of hand because they
come from RSS-DEV; it's a decent system based upon good thoughts.
2. Equal access to discussion, dissent, and moderation. Throwing folks
out of Vogon cargo holds (off lists, that is) or preventing them
from speaking is a no-no in the world of working together.
3. Really attempting to work together, not in words alone.
Dave, you simply must be in any discussion of this type. To pretend it
weren't so would simply be silly.
> 2. I'll pass the baton to someone who isn't so convenient a target for
> your personal issues. I would recommend Jeff Barr, he's got longevity in
> RSS, a product, and a lot of experience. I don't know if he has the time.
Rather than naming an heir apparent, I think a simple process of nomination
and voting would be a fantastic way to start.
> 3. Along with this, you will also stand down, by renaming the RDF and
> namespaces format to something other than RSS,
A note on names. You have, in the past, in addition to requesting a name
change, nixed the letters RSS. I'm afraid I don't think that will fly very
far. Despite your claims that RSS 1.0 is not RSS, its users and proponents
certainly feel it is. I've already spoken with you of various alternatives,
including xRSS, eRSS, RSSx, and RDFSS. Please state your position once and
for all in public on this point.
As I've said at various points to you, Dave, this is not my decision to
make. I am a member and chair of a working group and do not consider that a
position from which to unilaterally make such decisions or coerce others
into changing their minds.
I do, however, invite you to pop on in to RSS-DEV and call for a poll or put
forth a proposal to consider a name-change (let's leave the exact name up in
the air for now) which I'll be more than willing to second. If you're
really serious about your proposal, take a leap of faith and simply ask the
folks who can answer.
--
Again, these are just some thoughts buzzing about in my brain -- have been
for a while. I'm not promoting one flavour in particular, suggesting a
backtrack, or proposing a merge. I am answering some questions, asking a
few more, and hoping for some honest-to-goodness constructive discussion and
possibly a few bridges built along the way.
Please follow up to more neutral ground, syndication@egroups.com, on the
non-RSS 1.0-specific bits.
Rael
[1] http://groups.yahoo.com/group/syndication/message/1658
[2] http://groups.yahoo.com/group/rss-dev/message/1966
[3] http://weblogs.oreillynet.com/rss/
[4] http://www.oreillynet.com/~rael/data/xml/rss/modular/demo/
[5] http://slashcode.org/slashcode.rss
[6] http://groups.yahoo.com/group/rss-dev/message/1967
[7] http://groups.yahoo.com/group/syndication/message/1651
[8]
http://groups.yahoo.com/group/rss-dev/files/RSS-DEV%20Policies%20and%20Proce
dures
Rael Dornfest
rael@oreilly.com
http://www.oreillynet.com/weblogs/rael/
"My greatest strength is... common sense.
I'm really a standard brand--like Campbell's
tomato soup or Baker's chocolate."
--Katharine Hepburn