Message from discussion Namespace Attributes to Core Elements
Received: by 10.114.27.20 with SMTP id a20mr599647waa.23.1204642683747;
Tue, 04 Mar 2008 06:58:03 -0800 (PST)
Received: from el-out-1112.google.com (el-out-1112.google.com [22.214.171.124])
by mx.google.com with ESMTP id k36si5460586waf.1.2008.03.04.06.57.57;
Tue, 04 Mar 2008 06:58:02 -0800 (PST)
Received-SPF: pass (google.com: domain of sa3r...@gmail.com designates 126.96.36.199 as permitted sender) client-ip=188.8.131.52;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of sa3r...@gmail.com designates 184.108.40.206 as permitted sender) smtp.mail=sa3r...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by el-out-1112.google.com with SMTP id m34so890505ele.13
for <email@example.com>; Tue, 04 Mar 2008 06:57:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
DomainKey-Signature: a=rsa-sha1; c=nofws;
Received: by 10.114.154.1 with SMTP id b1mr2175057wae.118.1204642669841;
Tue, 04 Mar 2008 06:57:49 -0800 (PST)
Received: by 10.114.241.19 with HTTP; Tue, 4 Mar 2008 06:57:48 -0800 (PST)
Date: Tue, 4 Mar 2008 09:57:48 -0500
From: "Sam Ruby" <ru...@intertwingly.net>
Subject: Re: Namespace Attributes to Core Elements
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 4, 2008 at 8:57 AM, rcade <cadenh...@gmail.com> wrote:
> On Mar 3, 2:11 pm, Sam Ruby <ru...@intertwingly.net> wrote:
> > While the original RSS 2.0 specification only allowed arbitrary
> > namespace qualified elements to be defined, in June of 2007 the RSS
> > Advisory Board voted to accept a clarification which extended this
> > provision to namespace qualified attributes. Since that time, this
> > clarification has yet to be acknowledge or incorporated by Harvard,
> > resulting in the first and only known substantive difference between two
> > otherwise functionally compatible RSS 2.0 specifications.
> This is better than the current warning, but it still takes the
> position that the spec did not allow namespace attributes until the
> board extended it. That's not our position, as evidenced by the vote.
> As for Harvard, I was told by Berkman Center director John Palfrey
> that its involvement in RSS 2.0 began and ended with the publication
> of the RSS 2.0.1 spec in July 2003. Harvard's only interest has been
> in keeping the spec and related documents online and available for
> reuse under a Creative Commons license. I do not see any reason to
> think Harvard will ever get involved in matters such as the namespace
> issue we're discussing here, and I say that as someone who tried
> several times to solicit its active participation.
> Now that the board is the custodian of RSS 0.90 and RSS 0.91, I'd like
> to see the validator rely on the board as the custodian of RSS 2.0 as
> well. We've managed with the RSS Profile to create a lot of common
> ground between the validator and the board. I talk up the validator
> all the time as I help developers and publishers add atom:link and
> other recommendations to their feeds. If you relied on our
> interpretation of the RSS spec, which is the result of an open and
> accountable process, we could take this cooperation further.
You've snipped off important parts of my email, and are bringing up
The current text does not take the position that prior reversions of
the spec did not allow namespaced attributes. In fact, it says that
such revisions are "silent" on the matter.
Yes, the people who made the change that is the subject of this email
assert that it is a "clarification". It is equally fair to point out
that the web page that contains the Harvard version of the spec was
updated in 2007 and that update did not include this change. And that
the OPML 2.0 spec was updated in 2007 and did. We can debate further
what we can infer from this, but that will only result in more links
on that page.
The profile is an original work that as near as I can tell is
unequaled in matters relating to the 2.0 version of RSS.
NetScape is actively forwarding requests for the RSS 0.90 spec to the
RSS Adivsory Board's copy. This is not the case with requests made to
the prior custodians of the RSS 2.0 spec. Simply put, there is a
The current situation is messy. I wish it were otherwise. But you
first ask me not to take sides, and now you ask me to do so.
The ways forward that I can see:
1) the current approach. Point to the closest approximation I can
find to the spec before it was forked, but otherwise ignore the
dispute. Unfortunately, that can't be done without appearing to "take
2) openly acknowledge the dispute. Add even more links. In general,
this adds fuel to the fire.
3) do as you suggest, and effectively take sides. I'm not keen on
4) actively work with the RSS advisory board to roll back this one
change. Is there any possibility of this happening?
- Sam Ruby