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

Re: [rss-public] Re: RSS : a "namespace" in itself ?

Expand Messages
  • Sam Ruby
    ... Atom happens to be in a namespace, and may therefore theoretically be more suited to solving this particular type of problem, but beyond the AtomPub
    Message 1 of 42 , Feb 11, 2009
    • 0 Attachment
      rcade wrote:
      >
      > --- In rss-public@yahoogroups.com <mailto:rss-public%40yahoogroups.com>,
      > Geoffrey Sneddon <foolistbar@...>
      > wrote:
      > > Atom already provides all this. Why do we need RSS too?
      >
      > Under that logic we don't need RSS at all. Atom does everything RSS
      > does and is more precisely specified. Whenever anybody asks me which
      > format they should use on a new project or site, I tell them Atom.
      >
      > But a lot of people are using RSS -- it's the most popular feed format
      > by quite a large margin [1], so I think there's value in defining how
      > they can use RSS in other XML dialects.

      Atom happens to be in a namespace, and may therefore theoretically be
      more suited to solving this particular type of problem, but beyond the
      AtomPub format, I must confess that I can't think of a single example
      off of the top of my head where this is done.

      But for the sake of discussion, let's ignore Atom for the moment. Do
      you know of any tools for which this proposal solves a real problem?

      > Along those lines, I think "http://backend.userland.com/rss2
      > <http://backend.userland.com/rss2>" is a
      > better choice for the namespace URI than
      > "http://www.rssboard.org/rss-namespace
      > <http://www.rssboard.org/rss-namespace>", given James' tests and the
      > Google Code Search result. So I'm revising my suggestion.
      >
      > I think we should add a sentence to the end of the Extending RSS
      > section in the specification [2]:
      >
      > "Using RSS elements in other XML dialects requires the namespace
      > declaration "http://backend.userland.com/rss2
      > <http://backend.userland.com/rss2>". This declaration
      > MUST NOT be used in an RSS document."
      >
      > I don't see how it encourages people to declare a default namespace
      > for RSS by telling them they MUST NOT do it. The proposed revision
      > would help educate more implementers that RSS elements do not belong
      > to a namespace.

      If that were the only goal, then I would suggest that simply stating
      that RSS elements do not belong in a namespace would be a more
      straightforward way of addressing that requirement.

      > 1: 80% use RSS, 16.6 use Atom, as of the last time I looked.
      > http://workbench.cadenhead.org/news/3227
      > <http://workbench.cadenhead.org/news/3227>
      >
      > 2: http://www.rssboard.org/rss-specification#extendingRss
      > <http://www.rssboard.org/rss-specification#extendingRss>

      - Sam Ruby
    • Randy Morin
      Awesome! I think then that most of us are in agreement, we just need to decide whether to go with the userland or rssboard namespace. I m going to start a
      Message 42 of 42 , Feb 12, 2009
      • 0 Attachment
        Awesome! I think then that most of us are in agreement, we just need
        to decide whether to go with the userland or rssboard namespace. I'm
        going to start a brand new thread (this one is too loud to follow).

        Randy

        --- In rss-public@yahoogroups.com, "scamden" <sterling@...> wrote:
        >
        > After some further research: Visual Studio only generates a
        warning
        > if the URI points to a file with extension .xsd that either cannot
        be
        > opened or is not in a valid XSD format.
        >
        > SlickEdit, on the other hand, generates a popup warning any time
        that
        > the URI is not an XSD.
        >
        > I fully understand that having the URI point to an XSD is optional,
        > but I think that it is optimal. I'm happy, though, if we just
        choose
        > a URI that has no file extension. We can point it at an HTML
        document
        > for now, and then later if we decide to develop an XSD we can point
        it
        > there instead.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.