RE: RFC: Clearing confusion for RSS, agreement for forward motion

["Rael Dornfest" <rael@oreilly.com>]

Howdy,

Well, I've watched percolate a little, both on the lists and in my own head.
I have some thoughts which I will inline, along with apropos comments from
others (in []s, with attribution).  I'll keep this as concise as possible,
erring on the side of needing followup clarification rather than overstating
and being downright boring.

First and foremost, the last couple of days have been in my eyes rather good
ones.  I applaud Dave for taking the step of putting together this proposal
and all of you who have contributed your thoughts and concerns.

Second, I will reiterate that I speak with my own voice, not those of
RSS-DEV or any other persons or groups.  Anything that affects RSS 1.0 (via
RSS-DEV) will be placed into RSS-DEV's governance system for discussion and
decision-making.

I'd also like to echo Dave's request for continued discussion, despite any
points of disagreement, holes, or niggly nagglies that just need to be
worked out.  We've all been caught in the negative flow for some time now;
let's dedicate at least some fraction that time to putting all this right,
finding points of agreement, and building bridges.

That said, I'll get on with it...

Dave Winer wrote:

: 1. I don't like the idea of "sharing" the name. While sharing is a good
: thing in general, when it comes to naming things, well if they're
: different
: they should have different names. This is the source of the confusion.

Discussed in 7 below.

: 2. Mark Nottingham says that the number of 0.90 sources plus the "1.0"
: sources roughly equals the number of 0.91 sources. My numbers show
: otherwise, as I've posted them here and on Scripting News. Among the
: actively updating channels on My.UserLand 0.91 is by far the
: format with the
: largest installed base. So if we're going to quote numbers we
: must get some
: agreeable way of surveying the installed base before making
: decisions based
: on this.  Or we could stop quoting numbers. (Which is I think is the
: productive and forward-moving way.)

I agree wholeheartedly.  Numbers are not going to aid any more than quotes
of which has more innovative useage.

: 3. One thing's for sure, though, 0.91 has had the longest run of
: any of the
: formats. It was promoted heavily, and gained wide adoption. Orphaning this
: format is not a good option. Therefore, in my humble opinion,
: anything that
: has the RSS name must be compatible with 0.91.

Actually, 0.9 has had the longest run of any of the formats, including 0.91,
and is still in use today very much as RSS.  Anything that carries on the
name RSS should be compatible with both 0.91 and 0.9.

I'm not sure what you mean here by "compatible" but I'm sure you're not
asserting absolute backward compatibility in format.  This would immediately
rule out 1.0 on the 0.91 side and 0.9x on the 0.9 side.  I'm taking this to
mean via conversion, translation, or simply by hand.

: 4. I strongly believe RSS is a Web content syndication format and nothing
: more. You can see that I acted on this belief by creating a new format in
: OPML, and did not try to shoehorn it into RSS. However, it seems that OPML
: is in somewhat the same space as "1.0".

The rub comes in what you mean by "content syndication" and "nothing more."

Traditionally, both 0.9x and 1.0 have indeed _not_ been content syndication
formats.  They've both carried blurbs and titles, not the content at the
other end of the link.  Now of course, claims could be made on both sides
with respect to content syndication.  While blogging to RSS has indeed put
much of the content (at least in Userland's blogging way) into the feed
itself.  But there now exists an RSS 1.0 Content Module, a comprehensive
content syndication framework.

As for "nothing more," the lines are drawn very differently by different
folk.  Some feel that subject, author, pubdate, and the like are as much the
core of syndication as the title or description.  Indeed, both 0.9x and 1.0
have/are creating a way of including author in the feed.  There very much is
more that folks want to syndicate here, that's not the issue.  The divide
has been in just how this was accomplished: iterative alterations of the
core or compartmentalized extensibility.

But perhaps I digress, given that this is a recital rather than the heart of
your proposal, Dave.

: 5. I could indeed withdraw from further discussions and work on
: RSS. In fact
: that's part of my proposal, below. There are other people at UserLand who
: can represent our interests, and in fact some of our development partners
: could adequately represent our interests if a collegial
: atmosphere develops,
: and I hope it does.

That's, of course, up to you.  I do, however, agree that there are many
voices in the (until a couple of days ago) din that should be heard.

: 6. Now, putting on my "what's the best thing for RSS" hat, and
: ignoring any
: difficulty that might be there for any person, company or group,
: I think the
: best thing is to do some renamimg. Let the RSS name be used only for the
: 0.90 and 0.91 formats. Declare 0.90 deprecated and document 0.91, do more

On the naming front, see 7 below.

As far as declaring anything "deprecated," I'd propose we declare them
_both_  "frozen" in favour of further development in the RSS-* branches.  Of
course we'd encourage folks to pick a path and provide them as much
information as possible to help them make the choice that's right for them.

: tutorials, etc. Evangelize. Clear up all the confusion. Authorship credit
: for 0.91 goes equally to Netscape and UserLand. A final version

Given that personally I had nill to do with the initial development of 0.9
and 0.91, I have no problem with this.  You should, however, make efforts to
include as many of the initial developers as possible in the credits, both
from Userland and Netscape.  What I dug up for the acknowledgement section
in the 1.0 spec was:

  The members of the My Netscape Network "Brooklyn" team for RSS 0.9
  and 0.91 (Eckart Walther, Jeff Treuhaft, Wade Hennesey, Rafael Cedano,
  Bill Turpin, Dan Libby, and Mike Homer)

I leave others to fill in any omissions.

: of the 0.91
: spec is created derived from the one on backend.userland.com, and it will
: contain pointers, at the end of the document, to any websites that are
: created for subsequent formats that offer compatibility with 0.91. As a
: gesture of goodwill it will also include a pointer to the RDF fork. This
: specification will maintain a copyright notice that allows it to be
: copied in whole or in part.

There's a slant here, Dave.  The document should point to both branches
equally.  We already talked above of their both being compatible in some
sense with 0.91 and 0.9.  Talk of "forks" and "gestures of goodwill" over
branches and cross-pollination are not going to get us very far, I'm afraid.

: 7. Both branches take new names. Neither format has the letters "SS" in
: their name. The RSS-DEV list changes its name to reflect the new name for
: the RDF-and-namespaces branch.

[Mark Nottingham: RSS 0.9x and RSS 1.0 are different formats, yes, but they
are related; they have an intertwined history, and a common purpose ...
If we change names away from RSS, we loose what little momentum we
have. If we change the names so that they are fundamentally
different, people don't link them in their minds, and they become
competing efforts in the user space, not just the developer space. So, a
thought - what about keeping the RSS as the root of their
names, but moving away from competing version numbers, which gives
people a feeling that the RDF version is the latest-greatest, rather
than an option?
e.g.,
  RSS 0.91 -> RSS Simple
  RSS 1.0 -> RSS Semantic
Each of those can have their own versioning system for future
development. This would allow both of them to benefit from a single RSS
evangelization effort. Basically, we're telling the world that yes,
we can play together.
(http://groups.yahoo.com/group/syndication/message/1672)]

As I responded right away, I cast my vote for just such a recognition of
common lineage, the split, and peaceful coexistence with bridges in-between
for those who wish to work with both or move from one to the other (both on
the development and user fronts).  RSS has in it months and months of work
by a whole bunch of folks on all sides and to drop the kind of visibility it
already has (yes, there is much that's publically positive) would be a huge
mistake.

I've never much liked calling this a 'fork.'  It's more of a tree, really,
with a trunk (the solid foundation of RSS), and branches (RSS-Simple and
RSS-Semantic) based upon evolving needs, differing foci, and philosophies.
But the tree as a whole _is_ RSS.  This is not an OR; each branch is as much
RSS as the other -- this, indeed, has been the meat (or tofu) of much of the
argument.

[Dave Winer: And it's a much easier story to pass on than the competition
based on version numbers ... After the split there will be three names on
the ladder. At first RSS will be topmost, but then one or the other will be
the "new" one. (http://groups.yahoo.com/group/syndication/message/1676)]

You're spot on; versioning numbers are indeed rather confusing here.  But a
joint naming scheme renders versioning inconsequential.  No more 0.9x and
1.0 and possible leapfrogging silliness in 2.0.  RSS is the one true root
(or trunk, to continue the analogy) with RSS-Simple and RSS-Semantic (or
whatever is settled upon) as the continuance thereof.  Both RSS-* are the
"new" and there simply is no "other."

Another aspect of this is the need to build bridges, both for developers and
users, between the two branches and, obviously, back to the trunk.  These
are in the form of converters, tutorials, and documentation -- the last one
there is perhaps the most important for evangelism and getting started; we
should be helping our potential users find what works best for them rather
than lobbying.

: 8. Re the "simple" branch -- if a working group is formed, it should be
: comprised of users of the format, i.e. content developers, and it should
: take input from tool vendors, aggregators, content management system
: developers. This is an insurance that their needs are met should
: the simple
: branch evolve.

Agreed.  That was exactly the reason for RSS-DEV's governance system
(http://groups.yahoo.com/group/rss-dev/files/RSS-DEV%20Policies%20and%20Proc
edures).

I'd actually say that a working group for RSS-Simple (or whatever) _be_
formed right away so as to _assure_ that development can continue in the
manner you state above.  Whether you're an RSS-DEV'er or no, having a system
in place is key to moving forward in your branch in a fair and possible
thing.

: It will not be called RSS. Then what RSS is is very simple,
: is no longer contested, in any way, now or in the future, it has a large
: installed base, is easily documented and evangelized, there's no need for
: further discussion since it's well-known what it is.

Again, see 7 above.  I'll add, though, that what folks consider RSS is a
community thing and is larger simply than your definition of what RSS 0.91
is.  RSS refers to the systems we've built together, from a common lineage
and is in no way tarnished by moving forward in different ways according to
need, focus, and philosophy.  RSS as an overarching architecture (I'm
talking about more than the serialization format here) _is_ simple.  When
you get down to the nitty gritty, one branch may be simpler for some,
constraining for others; the other may be freeing or bloody confusing.  But
the concept is one that I believe we all inherently agree upon.

I'd say what you've written above could very much be applied to all
flavours.

: 9. I will not personally participate in the evolution of either
: branch. This
: is my exit point, personally, from RSS work. However, UserLand will
: participate in some manner in the work done on the "simple" branch, and
: possibly in the RDF branch. If either group asks my opinion on
: something, I
: will offer it, but only offlist, and only if I have the time.

Dave, while we may differ in our approaches, I've always listened to what
you have to say and take this discussion as a way forward, where
conversation can happen right there in the open on a productive level.  Of
course, your level of participation is up to you, but I would not predicate
any agreement on your leaving.  Point 9, in my opinion, has little to do
with what we're figuring out here today.

: 10. I believe there are only a few users of 0.92, while there may be many
: channels, most of them are managed with Radio UserLand, and we
: would commit
: to changing the name of the format in a subsequent release, and would
: encourage others who are deploying in this format to change the name in
: their implementations.

As would I--predicated upon an agreement on bilateral renaming (form to be
decided, per above) by both sides--in anything I have control over or input
into: XML::RSS (partially), Meerkat, Peerkat, and so on.

: 11. When we've made similar offers in the past, some have said that we
: should just change the name and let the RDF people use the RSS
: name. That is
: not acceptable. The goal is to clear up confusion in what RSS
: means. I make
: this offer to show that we're willing to share the pain to help RSS
: re-establish a clear identity.

I agree.

: 12. Arbitration. If there are disputes about this agreement, they will be
: arbitrated by a group of three content developers chosen from the

I'd not restrict that to content developers; I'd say active developers.

: Syndication list, one to be chosen by each side and agreeable to

By each side, I'm assuming you mean 0.9x and 1.0.  While coming up with such
a person as representing RSS-DEV is just a matter of nomination and voting,
how would one choose the other, 0.9x side?  This is another reason for a WG
and governance system.

: the other,

I'm not so sure forcing one group's choice to be agreeable to the other's is
a fair, not to mention expedient, provision.  The third person you mention
should take care of this balance.

: and a third to be chosen by Mark Nottingham, the founder of the
: Syndication
: list, and this person must also be agreeable to both sides.

This make sense.

: Decisions of the
: three-person panel will be made in a timely fashion and will be final.

I'd like to propose that we continue the discussion as we currently are
before having to go that route.  After all, we are at the point of
proposition, not disputing.

: 13. If this proposal is not accepted by the other side, its terms are not
: enforceable.

I'm not so sure we need to dive into the pseudo-legalese here.  If we don't
agree, we don't agree, is basically the gist of it.  But let's try our
darndest.

: 14. All parties agree to put the past fully behind us. Discussion
: of events
: that took place before agreement was reached will be off-topic on
: all three
: mail lists.

Off topic, but I wouldn't go so far as to say banned.  There's much to learn
from such discussion of history, providing it's done in a civil manner.  How
this is governed will be up to the list moderator/owner in question.

: 15. A mechanism will be set up for people to endorse this proposal, and a
: response is requested from the working group for the RDF fork.

See my note above about RSS-DEV already having such a mechanism and 0.9x
needing one.  As we need polls, I'd like to nominate Mark Nottingham as
pollster, gathering input and coming up with fair and balanced questions and
choices.

All in all, I like where this is going.  It seems the only real disconnect
is between a complete rename and branched rename, which I think we can work
out pretty well.

I've gone on for a time, so I'll end here.  Please do let me know if there
are any bits I've written that need clarification -- as I mentioned, I
wanted to be as brief as possible, leaving the nitty gritties for further
along.

All the best,

Rael