[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] New poll for syndication



"Mark Ketzler" <mketzler@bizslice.com> writes:

> [Ken MacLeod writes:]
> 
> > Since neither group seems likely to budge on that issue, I suspect
> > we need to find another solution.
> 
> Is this the case, will neither side budge on this? Isn't XRSS by
> implication an extensible superset of RSS? Can the "original RSS
> stakeholder's" speak to this and explain their position re: a name
> change?

That would be nice.

> Isn't the fragmentation of the RSS community (including the only
> actual users!) a higher price to pay than the effects of a slight
> name change like XRSS.

I'd ask that in reverse, why won't the folks proposing a new version
of RSS without RDF+NS change their name?  It was also suggested and
even seriously discussed not too long ago (rss-classic, if I recall).
If it was so easy, plain, and clear, then either side could just as
simply do it.  It's not that easy and clear!

If there were no proposal for a new version of RSS without RDF+NS then
there's no reason to break the chain of versions.  If there were no
proposal, then RSS 1.0p would merely be a new version and anyone who
wouldn't want to upgrade wouldn't have to.

It's not even clear that there *is* any substantive interest in a new
version of RSS without RDF+NS, if there were then there would be
action being taken on proposals, and yet there's not.  New elements
have been suggested for RSS for *months*, what or who is blocking them
from being adopted?

Let's presume, anyway, that there *is* interest in a new version of
RSS without RDF+NS, just as there is clearly interest in a new version
of RSS with RDF+NS, what is the best way we can both work together
amicably to produce new versions moving forward, without disrespecting
any of the original stakeholder's claims to the name RSS?

Let's not fragment.  Let's find another solution.  What's wrong with
sharing the name?  What would be wrong with us pooling some of our
resources and fostering both approaches?  This doesn't have to be an
"us vs. them" solution at all.

  -- Ken