Subject:
|
Re: Attention all RSS geeks!
|
Newsgroups:
|
lugnet.publish
|
Date:
|
Mon, 23 Aug 2004 15:35:02 GMT
|
Viewed:
|
3690 times
|
| |
|
|
On Mon, Aug 23, 2004 at 03:41:44PM +0000, Kelly McKiernan wrote:
> I've just looked over some of the Atom docs, but it seems very similar
> to RSS to me, only much newer. Is Atom supported by many current blog
> or web publishing software?
AFAIK, yes - most CMSs, and almost all aggregators do support atom.
> My thoughts were that straight RSS feeds would work within the LENNI
> framework, and enhanced feeds would be better for LENNI-aware parsers,
> so there's some graceful degredation. It may be that I'm not as
> familiar with Atom, but I get the impression that starting with Atom
> would be starting more from scratch, without an existing user base
> like there is with RSS.
I don't think there's much of a difference between emitting Atom or
RSS/LENNI, but I don't have that strong a preference. If everyone else
is dead against Atom, I'll go with the flow :)
> Specifically, the docs I've reviewed are here:
> http://www.ietf.org/html.charters/atompub-charter.html
> http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-01.txt
>
> > > * Does RSS need to be extended at all to meet these needs? Is
> > > there another way of using standard RSS to solve these
> > > objectives?
> >
> > Probably not - which is why Atom might be a better solution. Note, I
> > do say "might" because I'm not as well versed in Atom yet.
>
> I'd like to see more info about where an unmodified Atom would be a
> better solution for LENNI than RSS. If it could work "out of the box"
> then it could be a better solution, but only if it's something that
> could be read by existing aggregators. If there's a better spec but
> nobody uses it, that's kind of a problem.
The spec is supported by any aggregator I've heard of/used. As for
important features out-of-the-box, here's some:
- Well defined spec
- Language tag is required: This will be important for international
feeds, like from 1000stein.
- Better support for Author meta-data, like website, email, name, etc.
Support for multiple credits (contributors).
None of which we can't live without.
> > > * Assuming the answers on 1-3 are "yes", is RSS 2.0 the best
> > > version to work with? (I think it is, since it's relatively
> > > simple like .91, but can use namespaces without having to include
> > > a ton of RDF crud like in v1.0.)
> >
> > The problem with RSS 2.0 is that it's a really really vague
> > standard. That means the different clients might render the exact
> > same posts in different ways, making the publishing a lot more
> > complex.
>
> Actually, I kind of like that the RSS 2.0 spec is fuzzy... it forces
> developers to support core functionality and maintain backwards
> compatibility. Anything that the parsers don't understand should be
> thrown away - so LENNI-specific content (like AFOL) wouldn't be
> displayed at all in an off-the-shelf RSS aggregator display. Hard-n-
> fast specs tend to make developers sloppy, so there isn't as much
> attention to error-correction as in looser specs. RSS is, to put it
> truthfully, a gloppy conglomeration of a bunch of different
> specifications in use (seven, I think) and parsers need to be bright
> enough to wind through them all.
But that's exactly the problem that led to all the browser
incompatibility problems. If there's no clear spec, each aggregator (or
browser) tries to do it's best... The problem is that each one comes
with a different interpetation of what is best, and so the results are
slightly different. Then, later, when the technology advances, suddenly
these differences are very important.
Even if we do go with RSS, I'd hope that LENNY will have a very well
defined spec, so that we can avoid these kind of issues.
> > > <bricks:fanage>AFOL</bricks:fanage>
> >
> > Shouldn't this be a numerical age? Otherwise we need to define
> > what's AFOL...
>
> Good question, that's a valid discussion point. I'd initially thought
> filtering by age interest would be "Kids" or "Adults" or "all" but if
> it makes sense to make that more granular, that's certainly possible.
Either that, or define in the spec what the cutoff is between Kids and
Adult.
> > > <bricks:theme>Trains</bricks:theme>
> >
> > > How do we support multiple themes? Comma separated list? Make
> > > parsing/filtering a bit more complex. Multiple entries maybe?
> > > * Should or can Themes be multiple choice?
> >
> > You should be able to have multiple themes, but not from a set list.
> > New themes get added all the time, we shouldn't have to update the
> > spec each time just to say "Fantasy Mice" is now a valid theme :)
>
> Exactly. I'm not sure of the best method for this - the themes list
> should have some sort of standardized entry so multiple parsers can
> filter appropriately. We wouldn't want to have something like "Train"
> and "Trains" and "choochoo" be the same theme... there should be
> something set so that it's "Trains".
>
> Question for the RSS gurus: can there be multiple item-level elements with the
> same name? e.g.:
> <bricks:theme>Trains</bricks:theme>
> <bricks:theme>Town</bricks:theme>
Here lies the problem of a lack of a good spec :) Though, I think
that's a question to the namespace spec... Which does allow us to say
that tags can be repeated, from what I understand.
> > > * What type of "approval" process should be put in place for either
> > > news or calendar events, if any? What's to prevent a malicious
> > > person from entering XXX type of content on a KFOL feed?
> >
> > Nothing at all. And I can't imagine how you can force an approval
> > process? The only thing users can do is be aware where the item came
> > from, and apply judgment as to what's their level of trust to that
> > source. Since the feeds will be published from each individual
> > sites, and not from a central server, it's up to the sites to make
> > sure their feeds are "clean".
>
> Maybe it's a matter of providing simple ways within aggregators to
> remove feeds from your list, if the content is objectionable. Having
> dealt with a web site targeted at kids, my first instinct is to
> provide easy mechanisms to deal with the inevitable troublemakers.
Right - this is a job for the aggregator, to allow managing of which
feeds are collected. You can't stop a bad feed from being published,
but you can't stop reading it.
Dan
--
Dan Boger
dan@peeron.com
|
|
Message has 1 Reply:
 | | Re: Attention all RSS geeks!
|
| (...) I think you're right, at least in theory, that Atom is the better standard, simply because it's being designed from day one to be what it is meant to be. (Whereas the RSS format has sorta bounced around from concept to concept, then was (...) (20 years ago, 23-Aug-04, to lugnet.publish)
|
Message is in Reply To:
| | Re: Attention all RSS geeks!
|
| (...) I've just looked over some of the Atom docs, but it seems very similar to RSS to me, only much newer. Is Atom supported by many current blog or web publishing software? My thoughts were that straight RSS feeds would work within the LENNI (...) (20 years ago, 23-Aug-04, to lugnet.publish)
|
31 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
