[
Lists Home |
Date Index |
Thread Index
]
>Some responses to your recent XML-DEV post on evolvable formats.
>I'm not on XML-DEV, but you may forward this to the list if you
>wish. Or not.
I'll forward it. Although I doubt there is any
>Re: "except of course for all the others". Yes, I am saying that
>RSS 2.0, as the evolutionary successor to RSS 0.91/0.92/0.93/0.94,
>is superior to any other RSS-named or non-RSS-named syndication
>formats. This includes RSS 1.0 (from the RSS-DEV group, 2000),
>RSS 3.0 (from Aaron Swartz, 2002), ESF (from Nicholas Avenell, 2002),
>XSS (from Timothy Appnel, 2002), and so on.
Totally unfamiliar with ESF, I remember looking at XSS at one point but
thinking "why would you need that when you have RSS" not sure if it
isn't time to take another look. Despite my dislike for RSS 1.0 I am not
certain if it would not be preferable to RSS 2.0; mainly cause the way
the great idea of namespaces are being thrown around causes me worry,
and of course the escaped html.
My worry about namespaces comes down to a line Sam Ruby wrote in an
off-hand comment to Jon Udell, something like "Hey Jon, get your own
namespace" this no doubt meant in jest off-the-cuff bit of jollity
called forth to my mind the horror of perhaps Mr. Udells feed coming
with the Namespace xmlns:jon="http://www.namespacesRus.org/udell";
And his Rss feed having content like this
<jon:description><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif
size=2>I've implemented Mark Pilgrim's final version of the
</FONT><A href="http://diveintomark.org/archives/2002/06/02.html";><FONT
face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>RSS auto-discovery
technique</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif
size=2>, inspired by </FONT><A
href="http://matt.griffith.com/weblog/2002/05/29.html#a57";><FONT
face=Verdana,Geneva,Arial,Helvetica,Sans-Serif
size=2>Matt Griffith's proposal</FONT></A><FONT
face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>. A small
change in Mark's </FONT><A
href="http://diveintomark.org/projects/autorss/radio.html";><FONT
face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Radio
bookmarklet</FONT></A><FONT
face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> seemed to
be needed, from indexOf(application/rss+xml') to
indexOf('application/rss+xml'), in order to be able to subscribe in
Radio to sites using this technique.</FONT> <b>...</b></jon:description>
if I were setting up a consumer that rendered RSS via xslt I would have
to do something like the following:
<xsl:template match="*[local-name() ='description']">
</xsl:template>
the same would apply if I were processing xml using xpath as my
selection language and I wanted to get description.
This obviously becomes more irritating if I want to do processing
dependant on, is description in a namespace or is it not in a namespace?
Do I want to have processing dependant on Radio Userland's namespace
because I want to be able to say I support Radio? Note I am referring to
the blogChannel namespace here.
Okay I realize the above will probably never happen, but the idea that
it could sent chills up and down my spine.
This is of course a problem that occurs for anyone having to deal with
namespaces in xml, but generally one knows there are well defined areas
of what will fall in a namespace and what will not, I worry that these
areas are not so well defined with RSS 2.0; undoubtedly I worry without
cause but I worry anyway. Either that or it's just this coffee screwing
with my digestive system.
>Re: addition of namespaces. You're right that the addition of
>namespaces has no historical significance, since it has no history
>(having just been added to the format last month). As such, I did
not mention it in the list of deficiencies-becoming-necessities,
where I only concentrated on the deficiencies that did have
historical significance. "
>From the list of deficiencies- last in line:
"After adopting namespaces, it would fail to deprecate any existing
elements semantically identical to namespace elements already in wide
use. It would also fail to provide precedence rules in cases where a
document attempted to say the same thing in two different ways, thus
ensuring mass confusion among producers and inconsistent behavior across
consumers"
obviously one could take it to imply that you did not give it any
historical significance, what with the 'after adopting namespaces' but
it seemed to me that there was some significance accorded it on an
over-arcing level.
>However, I do believe that the haphazard
>addition of namespaces to what was originally called RSS 0.94 and
>is now called RSS 2.0 will be the death blow to the competing
>RSS 1.0, which, by all rights, should have won the race a long
>time ago.
I don't much care for RSS 1.0 (although I wrote an RSS consumer recently
for it which consumed only RSS 1.0) basically cause it seemed
over-architected.
That is to say the small content producers/consumers - of which more
will be said later - could not very well be expected to take advantage
of most of it's features.
> RSS 2.0 basically swooped in and said "hey, namespaces,
>good idea, I want some of that" and took them, wholesale, with no
>regard to how they would fit in a non-RDF-based format. Lots of
>people complained about this at the time, and my point is that,
>lo and behold, we seem to be muddling through and figuring out how
>they fit into a non-RDF-based format, after the fact. Namespaces
>in RSS 2.0 are flourishing, despite being hacked in with little
>or no understanding of the consequences.
I think this is the main problem I have here, I'm willing to agree that
probably things will work out for the best but it seems a little to
early in the game after the into of RSS 2.0 to say that Namespaces are
'flourishing' and that we 'seem to be muddling through', give it half a
year, see how many producers are putting out RSS 2.0 and how many
aggregators are having problems.
>Re: entity-encoded HTML. You are incorrect, this long predates
>RSS 2.0. It was official added in RSS 0.92, but it was actually in
>use even before that.
Quoting from my post: "{I know that with RSS 0.92 you could
use entity encoded HTML, case in point Jon Udell's rss feed:
http://radio.weblogs.com/0100887/categories/rss/rss.xml but it seems
like it's becoming more of a 'what a great idea' scenario with RSS 2.0}"
the impression I had was that you considered this a deficiency that was
somehow a strength. To my mind it limits RSS to a html structure, it
limits the technologies one can use to parse RSS and increases the price
of parsing it; as long as one is using namespaces just put the tags in a
html namespace and don't escape them, this requires of course that one
is still publishing well-formed xml. Or on the other hand, put a CDATA
section in and let the aggregator determine how they will handle CDATA
sections.
> It is probably the #1 most hated feature
>of the RSS 0.9x/2.0 format among RSS consumers/developers (since it
>means much more work for them to strip out HTML tags they don't
>want, or format things intelligently in an all-text display, or
>whatever... and I know firsthand how much this sucks, because
>I've done it). No developer in their right mind would design
>a format like this; if rich content was required, they would most
>likely require valid XHTML and work out a system where it could
>be embedded directly into the XML document, and require text-only
>alternates as fallbacks (like the OBJECT tag in HTML, or even
>ALT text for images as a minimal analogy). But RSS doesn't do
>any of that, and entity-encoded HTML is also probably
>the #1 most loved feature of RSS 0.9x/2.0 among RSS content
>producers. And there are a lot more content producers than
>developers.
I have a difficult time making this distinction between a content
producer and a consumer/developer. If you produce content you want the
content consumed, a good producer would thus give some thought to want
content consumers can consume. This is like the situation with html at
the beginning of the modern web, a bunch of producers coming out,
realizing 'hey stuff does not consume equally across the board'. There's
also the problem of developers who are producer/consumers; i.e people
who set up their own little channels, and who write their own little RSS
consumers. These small hacks are one reason I assume that RSS up to 2.0
has been successful. It is also these small hacks which I suppose will
have the most difficulty dealing with the new format, since I have seen
some few breakages.
>Most formats (including most of the other syndication formats
>that have been proposed or are being proposed) are developer-
>centric. RSS 2.0 (and RSS 0.9x before it) is user-centric...
>it always has been and it continues to be a series of poorly
>thought out short-term choices that help content producers
>in some demonstrable way right now. And that makes for a lot of
>high-profile fights (especially among developers, who rightly
>think this mess will be a living hell to support), and it
>makes for a really really really wretched format, and it is
>makes for something that is completely unstoppable.
Well I think developers go where there are users right? And developers
go to RSS because the most users are there at this point, it has
certainly a great deal of forward momentum for this reason, but I would
not consider it completely unstoppable.
|
