[
Lists Home |
Date Index |
Thread Index
]
> With RSS 0.91/2.0 & RSS 1.0, a feed consumer could write fairly
> straightforward code to parse either format with just a few if...else
> blocks to deal with the minor differences
>(e.g. in RSS 1.0 the <item> elements are not a child of <channel>).
Sure they are, the rdf:Seq tells you which ones. Not directly hierarchical
but certainly marked up as being children of the channel. But the core of
your point is valid.
> Now with adding Atom 0.3 and
> then Atom 1.0 to the mix, it is more likely that a syndication consumer
> would just want some API that hides the syntactical variaations of all
> the various XML syndication formats instead of dealing with each one
> individually using an XML API.
<sigh/> The level of disinformation about what Atom intends to accomplish
continues. On one level it's certainly about an API the upload/download of
"things commonly thought of like RSS items are" but on other levels it's
much more. The FUD about feed usage is rather a shame.
> If authors would stick to either of the schema's that would be a valid
> statement Dare. By the time I got up to about 10 feeds, the XSLT is
> becoming really horrible, and needs to be namespace agnostic.
Well, consider the tyranny of bad tools problem. If it's so complicated
maybe the tools you're using aren't the right ones. Or being approached the
'wrong way'.
> The number of variations on a theme made reasonable processing with xslt
> just about impossible. Hence I was hopeful of a schema for Atom.
I'm not sure I buy into the argument that things should be warped to fit
what only certain tools can provide. Don't get me wrong, I'm a fan of using
XSLT but if it can't cut it then perhaps it's the wrong tool?
-Bill Kearney
Syndic8.com
|
