[
Lists Home |
Date Index |
Thread Index
]
On Jan 15, 2004, at 10:19 AM, James Robertson wrote:
>> In a world where Atom is stillborn, this whole discussion is moot.
>
> There's a practical problem with this idea - most aggregators already
> deal with RSS, and have started adding support for the early Atom
> formats. As an aggregator author, I can tell you that using a
> separate framework for dealing with Atom is not a likely scenario; I'm
> using the same code to deal with Atom that I use to deal with RSS. As
> such, it has leniency for things (like illegal characters) for both
> RSS and Atom. I suspect that other aggregator authors either are or
> will be in the same boat; asking people to maintain different sets of
> rules for the two formats will seem odd to end users, and require some
> level of extra work on the part of authors. This is a 'facts on the
> ground' problem - what do you suggest as a solution?
I thought that Atom was intended for a different audience, or at
least use case, than the various flavors of RSS -- those who needed the
security of a fairly formal and authoritative spec, those that wanted
to treat the data as XML rather than tag soup. If it is just RSS 2.5
with a different name for various reasons that we needn't go into, I
agree that there is not much point in asking people to treat it as
something conceptually different, requiring new code or new attitudes.
I'm sure I sound pretty schizophrenic -- Atom is XML and should be
treated as XML, but the real world is a hard cruel place and you can't
count on anybody getting all the corner cases right when producing XML
from weblogs, newsfeeds, etc. Part of that stems from moving in the
Day Job from the R&D group that deals with core XML technology to the
organization that markets XML integration solutions to customers. In
my old world, you could say "not XML, you're outtahere". In my new
world, you can't say "pee-yu, that stuff looks like XML but it isn't,
go fix before you bother me again" The whole POINT of using XML in
integration scenarios is to solve problems robustly, so you fix it with
adapters, filters, transformers, etc. before you pass it down to the
core technologies that play by strict XML rules.
In thinking about how this is reflected in the RSS/Atom world, I've
been trying to find a middle ground between the chaos of RSS and the
strictness of pure XML by saying that: a) Atom is XML and should be
treated that way; b) What people say is Atom isn't always Atom, so
there is a niche for those who provide the service of turning tag soup
into wellformed XML or valid Atom; c) they should identify that as a
service they offer rather than something that happens by magic; and d)
anything "fixed" by such a service should retain some memory of the
fixup so that downstream consumers who need to assume that the original
content producer knew exactly what they were doing can reject fixups.
So, while I acknowledge the facts on the ground, it doesn't seem to be
asking too much to have aggregators pass Atom directly to an XML
parser, and continue to perform all sorts of cleanup on the RSS before
passing it to an XML parser. (Maybe that's not how most aggregators
work, but it's what Dare and Joe English described as their basic
architecture). I guess there are two parts to my proposed solution:
Educate people that Atom is XML, and if you want to play the Atom game
you really really ought to play by XML rules; accept that this is
somewhat unrealistic, but make cleanups explicit, preferably on request
rather than by magic, and mark the result as fixed up in case anyone
downstream cares. I don't know if this is too much work for
aggregators,l but it *seems* like a matter of adding some options and
switches rather than rearchitecting.
|
