Marcus Campbell wrote:
> In my opinion, I think it's fair to assume that some parsers are going
> to break with the introduction of namespaces and that it's unavoidable
> or, at least, that it shouldn't be avoided.

Probably true, but since the number one design goal for the 0.9x/2.0 series
is backward compatibility, we should at least try to minimize the breakage.

> Parsers that can't handle namespaces should be the things that are
> modified to handle or ignore them, not the format / output itself.
> Removing the namespace from 2.0 makes much of the format's basis
> invalid, and hacks out pretty much all of what makes it 2.0 rather
> than 0.94 - what makes it better.

I'm nobody's namespace guru (and I was really hoping that people who were
would take care of this), but...

I see two problems: the effects on non-namespace aware parsers (including
regexes), and the effects on namespace aware parsers.

Just saying "RSS 2.0 supports namespaces, and the namespace declaration for
the core is http://backend.userland.com/rss2" says that

<foo:rss xmlns:foo="http://backend.userland.com/rss2">
<foo:channel>
...

is perfectly valid RSS 2.0, which will thoroughly break virtually everything
currently deployed. To break the rest, you only need to add

<foo:rss xmlns:foo="http://backend.userland.com/rss2">
<foo:channel>
<baz:title xmlns="http://example.com/baz">Not an RSS title</baz:title>
....

At that point you should have everything broken, since non-namespace aware
parsers believe that every single "title" element is an RSS title, and
namespace aware parsers (absent any that have been rewritten since 2.0
launched) are not looking for the element
{http://backend.userland.com/rss2}title, they are looking for {}title, an
element named title that is not in any namespace.

What to do? You can state in the spec that to be a compliant document, the
default namespace (the one with xmlns="something", with no prefix) MUST be
RSS. That would prevent people from mixing RSS in an existing document that
either had some other vocabulary that MUST be the default namespace, or that
had so many elements already in another default namespace that it would be a
pain to change. The only likely candidate I can think of would be XHTML,
though there certainly could be others. Doing that would allow existing
non-namespaced and regex apps to keep working, since <title> would always be
an RSS title, and the only way to refer to an RSS title.

Existing namespace aware apps would still break, since they're looking for
{}title, rather than {http://backend.userland.com/rss2}title. The only way I
can see to not break them is to say that the core does not have a namespace,
that {}title is in fact an RSS title, and that only things other than the
core MUST have namespaces. I assume that there must be some problem with
that, that I'm too inexperienced to grasp, but I don't know what it is. For
me, it's no more work to say "I found an RSS element, it doesn't have a
namespace declared, that means it's RSS" than it is to say "I found an RSS
element, the namespace is thus-and-such, is that the namespace that I know
as RSS?".

The spec would need a bit of explanation for why things are a touch funky,
embracing namespaces for everyone else's elements but refusing them for its
own, but after three years of explaining away <textinput>, I'd guess Dave's
pretty used to that.

Phil Ringnalda