Re: RSS : a "namespace" in itself ?

* rcade <[email protected]> [2009-02-12 00:40]:
> 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.

Except, elements in a namespace and elements outside a namespace
aren’t the same thing even if they have the same localname. So
this proposal does not define how to use RSS in other XML
dialects so much as it specifies a different version of RSS that
is embeddable, by virtue of being in a namespace, unlike any
other existing (non-RDF (roughly)) version.

The existing version of RSS – the real thing, with namespace-less
elements – cannot really be used inside other XML dialects now,
and will still not be any more usable inside other XML dialects
after this new, formally incompatible but embeddable version of
RSS has been standardised.

Of course, since RSS is mostly processed by tools that wouldn’t
know a namespace from a hole in the ground, it will appear that
this new incompatible version is really kinda mostly compatible
as long as you squint right. Just like all other versions of RSS.

Except some tools always squint wrong, leading to situations like
the different existing versions of RSS predefining different sets
of named character entities, which some tools care about and
others don’t, leaving implementers to figure out which version of
RSS will break fewer tools.

That is what we’re going to get *more* of.

What is the cost to benefit ratio?

Given that, what is the need that is now suddenly driving the
standardisation of yet another incompatible version of RSS? The
motion spun out of nought but an inquiry about phrasing. Never
was there any mention of a need for embeddable RSS for some
application currently under development, not by the thread
starter and not by any other participant. Why is a committee
driving innovation that no one asked for?

RSS is enough of a minefield already. Why bury a few more charges
for the unwary to step on?


* Randy Morin <[email protected]> [2009-02-12 01:10]:
> Although I agree that using backend.userland.com might be a
> better solution, I'm not personally comfortable with hi-jacking
> their domain without permission.

Is it hijacking to document a pre-existing choice made by the
owner of the domain himself which is already wired into a variety
of codebases?


* scamden <[email protected]> [2009-02-12 01:35]:
> Theoretically, any URL that provides the XSD should be legal,
> though.

Any URI whatsoever is legal. There is absolutely no requirement
in XML about what kind of resource should be at the other end of
a namespace URI. There is not even a requirement that the URI be
dereferencable. In fact even the use of a host name for which no
DNS record actually exists is legal.

It is courteous and helpful, of course, if there *is* something
there. Personally I prefer a short explanatory page aimed at
humans, not machines, à la <http://www.w3.org/2005/Atom>. (Not a
shining example, but roughly what I mean.)

But that should not be a concern in this discussion until the
more pressing ones are considered.


Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-public/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rss-public/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/