intertwingly

Gordon Weakliem: Forget silent data loss, even the SEC can’t get basic RSS right. The feed Tim pointed to yesterday (financial filings) declares itself as RSS 2.0 but uses rdf:about instead of <guid>. But that’s really beside the point. As someone pointed out in the comments, you want this information to be accepted and managed by a third party (e.g. a regulatory agency), not managed by the company itself, at least for the financial filings. How about for press releases and the like - not-regulatory filings, but still material data? For similar reasons, I don’t think that simply publishing to the web is sufficient in itself. I can name at least one popular blogger who’s been taken to task for modifying or deleting postings and has been accused of “rewriting history” for doing that. There’s certainly the potential for that if a corporate weblog were the exclusive source for those releases.

I have so many things to say on this, I almost don’t know where to start.

• What Gordon wants is called non-repudiation.  Some say that The best infrastructure for the exchange of XBRL instance documents is ebMS, ebXML Messaging . This is available today as an Open standard and provides all the required security (integrity, non-repudiation and encryption) as well as reliable messaging.  I see signs that Tim is regaining his perspective.  It is only a matter of time before he resumes his rallying cry for 80/20 proof points.
• For companies that can manage to retain control over their private keys, Digital Signatures may help.
• There really is no need to actively send data to a mutually trusted third party as long as arbitrary third parties can fetch and cache the data themselves.  For example, the quoted text above is available in a Bloglines cache.
• The SEC’s use of a namespace qualified attribute to replace an optional core element in RSS 2.0 comes at an interesting time, as the RSS Advisory Board is evaluating the adoption of a new draft of the RSS specification which explicitly states that None of the restrictions described in this specification apply to elements or attributes defined in a namespace.  This is a sharp reversal from three days ago when the profile stated The elements defined in the RSS 2.0 specification must not be extended by attributes defined in a namespace.  The prior position was based on statements that the Harvard version of the spec is clear on the matter and didn’t provide any wiggle room.
• The only other known use case for namespace qualified attributes on core elements is to make it easier for consumers to detect that a given feed is not schema valid.  As near as I can tell, it was this use case that caused the reversal — if there was any other discussion, I can’t find it on the rss-public mailing list archives.  I guess that if the demand for this feature was great enough, one might forgive a stray into judicial activism, but during the three days that this warning has been deployed, this message has not received a single referal from the results of validating a feed.  During the same period, InvalidRFC2822Date received 201 hits from the validation results of unique feeds.  An additional 45 produced non-sensical RFC2822 dates and another 15 produced implausible ones.
• Meanwhile, I’m listed as one of five who contributed to the draft that is before the RSS Advisory Board.  This is a true statement.  I have made comments on the rss-public mailing list, and some of them have even resulted in changes to the draft.  What is also true is that at no time have I ever been asked to endorse this draft.  Hopefully this statement will quickly be captured into caches everywhere.

In response to Michael Pate’s reference to a Modest Proposal: stick with Atom.