|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Postel's law, exceptions
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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








