Loading ...
Sorry, an error occurred while loading the content.

29Re: [RSS2-Support] Re: Summary of issue with xmlns attribute

Expand Messages
  • Phil Ringnalda
    Sep 28, 2002
    • 0 Attachment
      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">

      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">
      <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
    • Show all 34 messages in this topic