[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [syndication] A message to the lurkers on the list
At 01:34 PM 10/17/00 -0400, you wrote:
Hey all:
I've been lurking on this list for quite some time, but not really able to
dedicate the time and effort to follow all of the debate threads that have
arisen in the past few months since RSS 1.0 was announced. I'd like to
contribute more, however, even if it means just giving an opinion here or
there or asking a question or two. Tristan's note just kind of gave me the
push to be more involved (kind of like the way NPR is guilting me into
becoming a member during this week's pledge drive ;-)
Yeah, at least my message was heard by one lurker :)
So, here are some of my thoughts on Tristan's note and syndication in
general:
I've been developing syndication feeds for my company using RSS (0.9, 0.91)
since I first caught wind of it on Scripting News. The thing that really got
me started with it was the fact that it was so easy to implement. As the
spec moved from just headlines (0.9) to headlines and descriptions (0.91), I
was thrilled because that was something that many of the aggregators we fed
were interested in, thus it became more useful in a business sense. However,
there were always elements missing from 0.91 that were very important to the
syndication that we do. Specifically, I needed a way to associate a list of
company ticker symbols with each <item> in a feed. Since there was no
standard way to do so, I created my own version of RSS0.91 that included the
<ticker> element, i.e. <ticker exchange="NASDAQ" symbol="MSFT" />.
Internally I called this format RSS0.91fn, 'fn' for 'financial'. We've been
using this format both internally and externally and it's been working well,
but I always felt a little guilty because it didn't conform to any spec, and
I've been a firm believer in the holy grail of a syndication standard that
would work well for both publishers and subscribers.
I'm trying to push for certain tags for exactly the same reason. Open
discussion of potential new tags is probably the best way to go on
something like this.
So, when I first got wind of the 1.0 spec and it's ability to incorporate
different modules for specialized needs, I was thrilled. I was (and still
am) interested in working with folks to develop a module that would include
elements that were important for syndicating financial news. However, as the
battle over the RSS name and the relative merits of namespaces and RDF
syntax began to flare, I decided to take a "wait and see" approach to see
what filtered out, especially since I saw the merits of both sides of most
arguments. I first used RSS because it was so easy to use and develop and
I'm convinced that that is the reason it's become as widespread as it is,
but I also see the benefits of namespaces and modularity as outlined in 1.0.
Finally, to make matters more interesting, I'm also interested in a standard
mechanism for syndicating entire articles, not just headlines, descriptions
and other meta data. For this reason, the proposed content module has piqued
my interest.
I think this is where the community seems to be split. Some people believe
that RSS should be very simple and easy to use and others want to turn it
into an industrial strength complete syndication system. I personally
believe that there is room for both. On the one hand, you could have a
light and simple version that would be for summaries only (which, I think,
might be renamed something along the lines of Really Light Syndication) and
for articles or much more complicated transactions, we would have an RSS
1.0 or beyond version.
RSS .91 is great but we can probably all agree that there are some extra
things we'd like to see in it (I've already listed mine) without adding
much complexity to it.
With that as background, I'll respond to some of Tristan's
questions/subjects:
>First, we need to come to term as to whether we want to move on to a
>spec that would be different from the RSS 1.0 one. There still seems
>to be some issues around that. According to the poll on that matter
>(http://www.egroups.com/surveys/syndication?id=320021) a vast
>majority want to move on to 1.0. However, that vast majority is 12
>people out of 16 votes. On 239 members, there wasn't even a tenth to
>make that decision!
I am very interested in the extensible nature of the RSS 1.0 spec for the
above cited reasons. However, I understand why some people would like to
keep using an easy to understand RSS0.91-esque format. I'm sure that some of
our partners would choose to use a 1.0-esque feed, and others would like
something a bit simpler. To date, I've only implemented one feed that used
any RDF syntax or namespaces, and I found that the developers on the other
end were less than enthused about the perceived complexity.
Having tried both, I've found that 1.0 adds complexity to the feed but I
couldn't figure what new features it added. As a result, I reverted to .91
on my feeds. I'm still trying to understand the advantages of going to RDF.
People tell me that it will be great in the future but what I want to know
is what are the advantages now. I know that in the future we'll have smart
agents surfing the sites, etc.. etc... but I'm more concerned about today
than the future right now.
>Second, if we do so, we then need to figure out whether we want to
>still call it RSS (which could create some confusion in the
>marketplace) or something else. The main reason behind this is to
>clear up the air so that if that spec were to evolve, we can all
>agree on it.
It seems to me that the 1.0 spec is enough of a different beast that it
should be called something else. From my perspective, it works differently
(namespaces, modular, RDF syntax), takes a bit more effort to implement
(from both sides, I'd think), but is more useful because of those things.
Plus, there doesn't seem to be a consensus as to what "RSS" means. Rich Site
Summary? RDF Site Summary? My vote would be to find a new name.
The question then is which one is being renamed?
>Third, we would need to define what goes in and what does not. That's
>a major piece of work. As part of this, we need to assess the
>membership's view on complexity. Where do we draw the line. Some of
>us are better versed at software development than others so the line
>has to be drawn somewhere but without your consideration
My take is that added functionality comes with the price of added
complexity. The trick is to keep that ratio (func/complex) as high as
possible, I guess.
Good point but how do we maintain that balance?
>Fourth, we might want to create an evangelism sub-group to convince
>the big players in software (the usual suspects: Microsoft, Netscape,
>Oracle, IBM, Sun, etc...) to integrate this in their software
>offering. That group should also be involved in evangelizing to the
>big boys of content (traditional media and large online content
>players) about the benefits of RSS (or whatever we call the new spec)
>and why they should support it.
I'd be very interested in working to evangelize a good spec for syndication.
The biggest hassle in syndication still, IMHO, is that none of "The Big
Boys" are using anything standard. While we offer RSS0.91 files, we have
many, many feeds and delivery mechanisms that we have to deal with to get
content and headlines out to various partners. Some use email for delivery,
some use tab-delimited files, some use their own internal XML formats, etc.
Depending on the partner, it either has to be done in their proprietary way
or it can't be done. I have been hearing more and more partners looking to
go towards XML for their feeds, but I fear that unless there is a robust XML
application everyone can implement, every house will come up with whatever
serves their needs and we'll be right back at the tower of Bable where we
started. The only difference will be that everything will be well-formed and
can be run through a parser ;-)
Definitely. After thinking about it for a few days though, I believe that
what we need are concrete examples of why do RSS (or others): Its
advantages and its ease of use. This will go a long way towards getting
people to approve it.
>Last but not least here: this is an open forum and we are trying to
>define a standard. There are a few times in your internet career
>where you get a chance to do so. Much like an election, some people
>will gripe after a standard has been defined. However, it is my view
>that your right to gripe is annuled if you do not get involved. In
>other words, it's easy for people to stand aside, not make any
>decision either way, and then complain about the results. While there
>are some disagreements between the people who are exchanging emails
>on this list and others (see the whole battle between the pro-RDF and
>anti-RDF groups as a prime example), those people are trying to push
>the standard in one way or another. If you don't get involved, then
>you might end up with something you really don't like.
A powerful point, and for me a great motivator. I'll do my best from here on
out to be a good citizen and contribute to the discussions. I agree to a
great extent with what Dave Winer said today, though: things in RSS-land are
very confusing right now. That confusion in part has kept me on the
sidelines. Part of my confusion can be reduced by me re-reading posts here
and on RSS-DEV, but I do think that one quick way to reduce confusion is to
pick a new name for RSS 1.0.
It sounds like a good point and it looks like this may be the general
direction in which things are going based on my cursory look at the most
recent threads on the list...
TNL
Delurked :-),
MK
--------------
Mark Kennedy
markk@fool.com
| Tristan Louis | Home: tristan@tnl.net | 140 e. 28th
st. |
| Chairman and CEO | http://www.tnl.net | Suite
8C |
| Moveable Media, Inc. | Boot up, Log In,Geek out | New York, NY 10016 |
To subscribe to the TNL.net newsletter, just send email to
TNLnet-subscribe@listbot.com