OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Postel's law, exceptions

[ 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.





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS