It’s just data

Crossfire

Rogers Cadenhead: If Randy wants to change elements to “elements and attributes” as a spec clarification, I’m comfortable solving the problem in that manner.

Positively breathtaking.

It gets better.  Rogers declares that he knows the author’s intent.  It is not like the author is dead.  It is just that he (Rogers) doesn’t exactly have an productive working relationship with the author.  Nor does he apparently respect the author’s intent — originally posted over three years ago — in other matters.

Rogers then proceeds to post a rationalization.

With apologies to Jon Stewart, “And I wanted to — I felt that that wasn’t fair and I should come here and tell you that I don’t — it’s not so much that it’s bad, as it’s hurting RSS.”


I’m not going to get dragged into another pointless argument about RSS politics.

I think you’re wrong on this issue, Sam, and you’ve been giving bad advice in the validator.

But if I’m wrong, you should be able to answer my question: If RSS 2.0 does not allow namespace attributes to core elements, where do I declare a namespace in an RSS feed?

Posted by Rogers Cadenhead at

Rogers,
Since XML Schema enables a format to forbid attributes but cannot provide a mechanism for preventing namespace declarations [because this would be silly], it stands to reason that it is quite possible for a format to restrict namespaced attributes while still allowing namespace declarations.

Whether this is actually the intent of RSS? We could just ask the author of the spec. 

PS: XML pedantry...how I’ve missed thee.

Posted by Dare Obasanjo at

But if I’m wrong, you should be able to answer my question: If RSS 2.0 does not allow namespace attributes to core elements, where do I declare a namespace in an RSS feed?

Call me stupid, but don’t you do it like this:

<rss version="2.0">
  .
  .
  .
  <foo:bar xmlns:foo="http://foo.com">
    <foo:baz>
      .
      .
      .
    </foo:baz>
  </foo:bar>
  .
  .
  .
</rss>

I’ve no dog in this fight. But (assuming) the attribute-set of the RSS core elements is fixed and xmlns is not among the allowed attributes, the above will work perfectly fine, no?

Is there some use-case where this won’t work?

Posted by Jacques Distler at

you’ve been giving bad advice in the validator.

Here’s the history behind that advice: Rogers, Sam, Rogers, Randy, Sam.

In the end, I decided to take a much less radical position than the one that you were advocating — this message was implemented as a warning.

For now, I’ve gone ahead and added a few links to that page so that readers can come to their own conclusion.

If/when the RSS Advisory Board produces a non-draft specification that contradicts and/or “clarifies” what the frozen Harvard version of the specification says, I’ll add another link.

Posted by Sam Ruby at

But (assuming) the attribute-set of the RSS core elements is fixed and xmlns is not among the allowed attributes, the above will work perfectly fine, no?

It would. But the first version of RSS 2.0 that supported namespaces, published in fall 2002, included a sample file with the spec. This sample file declared the namespace in this manner:

&lt;rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule"&gt;

This sample file was linked in the spec for two years.

So how can we say now, as Sam appears to be advocating, that RSS 2.0 never allowed namespace attributes to core elements?

Posted by Rogers Cadenhead at

as Sam appears to be advocating

As near as I can tell, it was Randy that came up with this interpretation.  And you seem to have consistently agreed that that’s what the frozen Harvard spec actually says.  And, by implication, that’s what the latest ratified RSS Advisory Board spec says too.

Meanwhile, both of you seem to want to change “elements” to “elements and attributes”.  If that gets ratified, I’ll simply link to that too.

Posted by Sam Ruby at

Clarifying Namespace Support in RSS 2.0

Randy Charles Morin has proposed the addition of four words to the RSS 2.0 specification (emphasis added): In the section Extending RSS , we propose that the following sentence be changed: "A RSS feed may contain elements not described on this...

Excerpt from Workbench at

If you are gonna repeat my arguments, then at least try to get them correct. xmlns and xml namespace prefix elements are not extensions. RSS is a dialect of XML and xmlns and xml are part of base XML, they are not extensions attributes.

Posted by Randy Charles Morin at

Just a passing comment:

If it was me, I would just recommend implementors to ignore unrecognized elements and attributes instead of nitpicking over whether or not to allow namespace-qualified attributes. This approach doesn’t change the spec and needs only one clear line in the recommendation doc.

Posted by Don Park at

If it was me, I would just recommend implementors to ignore RSS and stick with a format which actually deals with this issue.  This approach doesn’t change the unchangeable (yet ever-changing) RSS spec and needs only one clear line in the recommendation doc.

Posted by Mark at

If it was me, I would just recommend implementors to ignore unrecognized elements and attributes instead of nitpicking over whether or not to allow namespace-qualified attributes. This approach doesn’t change the spec and needs only one clear line in the recommendation doc.

That would be a sane approach.

Two exceptions: attributes that start with xmlns: (duh!), and attributes on namespace qualified elements where that extension specifically allows it (example).

This would be consistent with the W3C’s general approach to validity.  Two examples: xml:base and xlink.  The former arguably is “part of XML”, and yet the spec for that attribute explicitly states that:

This specification does not give the xml:base attribute any special status as far as XML validity is concerned. In a valid document the attribute must be declared in the DTD, and similar considerations apply to other schema languages.

In the case of RSS 2.0, one needs to interpret the term “schema” as “prose”, and ask oneself if the xml:base is clearly declared in that “schema”, and come to the conclusion that the answer is no.

Another example in xlink.  Can I validly use xlink attributes on XHTML elements?  No.  Can I validly use xlink attributes in SVG diagrams embedded in XHTML documents?  Yes.

These are examples of what is common in W3C specified vocabularies, and what users of such vocabularies would naturally expect from what is specified by RSS 2.0 at Harvard Law.

But the RSS Advisory Board appears to be on a different path.  Which is a pity, as they are throwing away all the credibility that they had built up.

Posted by Sam Ruby at

Wait, the RSS Advisory Board built up credibility?  Did I miss a cabal meeting?

Posted by Mark at

This approach doesn’t change the unchangeable (yet ever-changing) RSS spec and needs only one clear line in the recommendation doc.

I’ll float this draft and see what the board thinks:

---

Really Simple Syndication Best Practices Profile

Editor’s Note: This profile contains a set of recommendations for Really Simple Syndication, a web syndication format documented in RSS 2.0 (revision 2.0.8). Public comments are welcomed at RSS-Public.

Copyright Notice

Copyright 2007 RSS Advisory Board. This is version 1 of this document, published May 24, 2007. The current version will always be available at this link and other drafts are available.

Recommendation

Just use Atom.

License

Copyright 2007 RSS Advisory Board. Redistribution and reuse of this document is permitted under the terms of the Creative Commons Attribution-ShareAlike 2.0 license.

Posted by Rogers Cadenhead at

link to discussion on the RSS Advisory Board weblog.

Posted by Sam Ruby at

I’ll float this draft and see what the board thinks:

In fact, for publishers, that is really the only sensible thing to say. At this point, whenever I’m talking with someone who hasn’t made up their mind ahead of time (or has had their mind made up by a higher-up), I tell them “if you write code to consume feeds, be sure to support RSS; if you write code to produce feeds, only emit Atom (call it RSS if you like that better; no one will notice or care)”.

So far, I haven’t heard of any regrets from those who followed the advice.

Posted by Aristotle Pagaltzis at

New Book: RESTful Web Services

Sam Ruby and Leonard Richardson have just published RESTFul Web Services. I haven’t had a chance to read it yet, but will see if I can wheedle an author copy out of my publisher. Knowing Sam, it should be both comprehensive and complete. Seems to be...

Excerpt from Burningbird at

I’ll float this draft and see what the board thinks:

In fact, for publishers, that is really the only sensible thing to say. At this point, whenever I’m talking with someone who hasn’t made up their mind ahead of time (or has had their mind made up by a higher-up), I tell them “if you write code to consume feeds, be sure to support RSS; if you write code to produce feeds, only emit Atom

Serious question: when you make a recommendation like this, do you also relate the story of how your blog became unreadable as a result of your Atom usage? Is there a “best practices profile” that you point them to, so they can avoid making the same mistake?

I like Atom - I really do - but “Just use Atom” (without further qualification) is only a sensible suggestion if you don’t actually care whether your feeds can be viewed or not.

Posted by James Holderness at

Is there a “best practices profile” that you point them to, so they can avoid making the same mistake?

There are published conformance tests that allow one to select a feed consumer based on spec compliance.  But clearly this issue is one that has been around long enough and is widespread enough that it merits a warning, complete with links to prior dicussions and the test results themselves.  So this morning I committed a change to the feed validator to do exactly that.  Testcases: atom, xhtml.

Thanks for bringing this up.

Posted by Sam Ruby at

do you also relate the story of how your blog became unreadable as a result of your Atom usage? Is there a “best practices profile” that you point them to, so they can avoid making the same mistake?

First off: it wasn’t my use of Atom, exactly; it was my use of XML features that cannot be handled with strcpy alone. RSS is less likely to expose this sort of flaw in user agents because the vocabulary isn’t in a namespace and the number of people who embed their content as XHTML directly in the feed’s infoset is indistinguishable from zero. Extension elements may well suffer similar breakage there, however.

Nitpicking aside, though:

I don’t generally give that particular account, but sometimes I do. Just the other day in #atom, I advised someone to drop their prefix usage and gave them that link. Said person also had to add a feed-level permalink (I think) before their feed would work as a Firefox Live Bookmark, which is another case where validity of the feed was insufficient.

I guess the main reason I don’t point people anywhere in particular is simply that there is nowhere in particular to point them to; otherwise I would. But as things stand now, all there is is a smattering of scattered weblog posts.

Posted by Aristotle Pagaltzis at

Incidentally, 1.5 years later, Safari still has that bug. For shame, Apple.

Posted by Aristotle Pagaltzis at

Aristotle, what’s the bug specifically? If you filed it, do you have a bug number? If not, could you please file it at https://bugreport.apple.com (requires a free ADC account) or give me enough info to file a bug? I work on Safari (though not the feed-parsing part, which is actually in a separate a system framework) and can try to have it fixed, if it isn’t already.

Posted by Maciej Stachowiak at

Maciej: here are three test cases, complete with a baseline.  You can also browse (that’s browse, not live bookmarks) these feeds using Firefox 2 to see the expected results.

Posted by Sam Ruby at

But clearly this issue is one that has been around long enough and is widespread enough that it merits a warning, complete with links to prior dicussions and the test results themselves.  So this morning I committed a change to the feed validator to do exactly that.

Thanks Sam. I think that’s a good move. However, I just noticed that I’m getting that warning on an RSS feed that uses an atom:link for USM. I’m assuming that wasn’t intentional?

I guess the main reason I don’t point people anywhere in particular is simply that there is nowhere in particular to point them to; otherwise I would. But as things stand now, all there is is a smattering of scattered weblog posts.

That was kind of my point. A lot of people in the Atom community like to make fun of the work the RSS advisory board is putting into the best practices profile, but I think Atom could benefit just a much from an effort like that. I know flaming is fun, but sometimes it seems such a waste of time.

Posted by James Holderness at

I posted the following on Rogers' blog yesterday morning, in this thread.

[link]

For some reason it never appeared. Maybe you can copy it and paste it into the thread on my behalf?

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

I don’t usually agree with Sam Ruby, but this time he got it exactly right. I have been really clear about this and consistent. There is an easy and fair way forward for your work. Either define a new format, or define a profile. I think Sam is saying he will work with you on his validator to add support for either path you choose. But saying you’re “the” advisory board, working on “the” spec is clearly (imho) not an option for anyone at this time.

Then, by the way, you won’t always have to ask (and won’t be asked) what the intent of the author is, it won’t matter. If you’re trying to do a profile, then what people create will have to be both conformant to your profile and also validate against the RSS 2.0 spec. I think this is the preferable way to go (and is largely the way you are currently going). If it’s a new format you’re free to change any aspect of the spec you want, or create a wholly new format like Sam and Tim and the Atom folks at IETF did.

BTW, it would be helpful to see some evidence that you’re presenting these ideas to the group you represent. We can’t post to your group list, and the only people posting these days seem to be you and Randy. I’d like to hear from some of the other members of your group Rogers. Thanks in advance.

Posted by Dave Winer at

I just noticed that I’m getting that warning on an RSS feed that uses an atom:link for USM. I’m assuming that wasn’t intentional?

Testcase?  I’m not seeing that.  And no, that would not be intentional.  That would be a bug.

A lot of people in the Atom community like to make fun of the work the RSS advisory board is putting into the best practices profile,

A lot?

To my knowledge, the overwhelming majority have not commented.  Here's a list of contributors.  Exactly how many have made fun of the work?

For my part, I think it is important work that should continue. I’ve aggressively moved to keep the feed validator up to date with this effort, even to the point of aligning the test cases.

Unfortunately, this work seems to have been usurped by an effort to create a new specification, starting with a feature that some members of the board see as both useful and harmless.

There clearly is a power struggle going on.  And you know what they say about power.

The parallels are striking.  One of the first votes the original advisory board was whether or not to create a new validator.  Dave was voted down.  But Dave did it anyway.  Times change, what once was praised is now reviled.

One of the first votes of the newly reconstituted RSS Advisory board was to standardize on the Feed Validator.  It passed 8-0.  But Rogers appears intent on forking it anyway.  No vote required.  Oh, how times change.  Doing what was once requested is now bad advice.  The apparent sin?  Providing links to multiple points of view.  Apparently shining light on areas that are uncomfortable is an intolerable act.

As evidenced here, I am not opposed to shining light on areas where tools conformance to the Atom specification is an issue that providers need to be aware of.  No, that’s not every single bug with every single implementation (nor do I do that with RSS, for that matter), but longstanding and widespread issues do deserve mention, and get it.

I once gave Rogers commit access to the Feed Validator.  Beyond trumpeting it on his weblog, he did nothing with it.  I even gave him the password to the mailing list, but again nothing.

If Rogers is interested in contributing, and actually does so, I would gladly once again give him commit access.  In fact: done.  My reason to do so is simple: I find that it is much easier for people to criticize than to actually make a constructive contribution.  By granting him commit access, I am actually eliminating excuses to throw stones.

But I will ask that such contributions not be of the nature of purging alternate points of view, but one of adding code, tests, documentation, and/or perspective.

but I think Atom could benefit just a much from an effort like that.

It is my belief that more people use validators than carefully read specs.  But you are welcome to start such an effort, if you are so inclined.

Posted by Sam Ruby at

A lot of people in the Atom community like to make fun of the work the RSS advisory board is putting into the best practices profile

Who, exactly? Personally, I’ve occasionally said things to the effect that the Board are in a somewhat hopeless position, given the format they revolve around, but I welcome the work anwyay: just as in my advice to others, I refuse to ever write code to emit RSS, but I still have to deal with RSS coming down the wire.

I think Atom could benefit just a much from an effort like that.

Absolutely! In fact, the unambiguous content model means Atom would extract more benefit from an effort like that. I was very disappointed when I learned that contrary to what I heard before I got involved, the Atom WG wouldn’t be working on an Implementor’s Guide.

Posted by Aristotle Pagaltzis at

Maybe you can copy it and paste it into the thread on my behalf?

The most I can say is that somebody purporting to be Dave Winer posted this comment on my weblog.  Furthermore, that person chose not to Dave’s OpenID enabled scripting.com weblog for identification.  If you really are Dave, please post something using your OpenID confirming it.  I hope you can appreciate my need to be careful here.  Thanks!

I was very disappointed when I learned that contrary to what I heard before I got involved, the Atom WG wouldn’t be working on an Implementor’s Guide.

The problem was a lack of people interested in actually doing the work.  If you or James started one, I would gladly contribute.  If, however, your position is that it would be really nice if somebody else did that work, well, good luck with that.  :-)

Posted by Sam Ruby at

Unfortunately, this work seems to have been usurped by an effort to create a new specification, starting with a feature that some members of the board see as both useful and harmless.

Sheesh. The spec clarification was not proposed because we think it’s a harmless change. That’s just crazy, and it’s the kind of baseless charge that’s prompting us to install the Feed Validator locally on rssboard.org. The board voted to recommend and use the validator, and we can do that just as much on our own server as yours.

I intend to use that newly granted commit access to document RSS 2.0 as it is described in the spec and — if approved — profile. If a situation arises where your interpretation of the spec differs from that of the board, I’m following the board.

Posted by Rogers Cadenhead at

I’m following the board.

As long as you don’t purge dissenting opinions, fine.

Posted by Sam Ruby at

just noticed that I’m getting that warning on an RSS feed that uses an atom:link for USM.

Testcase?  I’m not seeing that.

Looks like it might only be happening when the atom namespace is declared in the RSS element, something I do in pretty much all of my test feeds.

Testcase

Exactly how many have made fun of the work?

Ok, maybe “a lot” is an exaggeration. It doesn’t take more than a few to give a bad impression. I don’t want to make a big deal out of this. I just find it a little disappointing.

Unfortunately, this work seems to have been usurped by an effort to create a new specification

I wouldn’t say that. Personally I think there’s more value in the profile than there is in a new “clarified” spec. However, if the board ever did vote to approve such a spec, I would want it to be as good as possible. Until the idea is outright rejected by the board I will continue to contribute on both.

It is my belief that more people use validators than carefully read specs. 

Feed producers, yes. My interest, though, is mainly from the point of view of a feed reader. Anyone wanting to write code to parse RSS feeds successfully needs a lot more information than is provided in the spec. The same can be said of Atom, although for different reasons. A feed validator is of very little help in that regard.

Also, I’m assuming that the work done on the profile has contributed in some small part to the warnings and recommendations made by the validator. So even if the document itself isn’t widely used, I would hope that its development has helped make the validator more useful.

But you are welcome to start such an effort, if you are so inclined.

No, I guess I’m not. My experience with the Atom WG hasn’t been very positive, so I try to avoid getting involved there. But I guess if I’m not willing to do it myself I should STFU, so I will.

Posted by James Holderness at

I was very disappointed when I learned that contrary to what I heard before I got involved, the Atom WG wouldn’t be working on an Implementor’s Guide.

That’s partly my fault (and partly, you know, everybody else who didn’t write it either).  My basic problem was this: writing an implementor’s guide would have required interacting with implementors, and too many of the implementors at the time were insufferable fuckwits.  Of course, it’s possible I’m just projecting.  At any rate, give it another generation (in Internet time, which isn’t that long really), let this round of fuckwits move on to other things, and maybe you’ll see an implementor’s guide before you die.

Posted by Mark at

Anyone wanting to write code to parse RSS feeds successfully needs a lot more information than is provided in the spec.

Um, you have seen feedparser.org/docs, right?

Posted by Mark at

Looks like it might only be happening when the atom namespace is declared in the RSS element, something I do in pretty much all of my test feeds. Testcase

Fixed.  Thanks!

Posted by Sam Ruby at

Danny Ayers Raw: Semantic Web: Really Simple Syndication Best Practices Profile

Rogers Cadenhead , in Sam Ruby’s comments : Editor’s Note : This profile contains a set of recommendations for Really Simple Syndication, a web syndication format documented in RSS 2.0 (revision 2.0.8). Public comments are welcomed at RSS-Public ....

Excerpt from Planet Social Media Research at

Just use Atom

Rogers Cadenhead: Really Simple Syndication Best Practices Profile Editor’s Note: This profile contains a set of recommendations for Really Simple Syndication, a web syndication format documented in RSS 2.0 (revision 2.0.8). Public comments are...

Excerpt from Bill de hÓra at

Really Simple Syndication Best Practices Profile

Really Simple Syndication Best Practices Profile...

Excerpt from Koz's Web at

If, however, your position is that it would be really nice if somebody else did that work, well, good luck with that. :-)

I thought briefly about taking it upon me. Then I thought of the 30 other project ideas in my TODO.bluesky file, as well as my existing projects I barely maintain, and thought better of it.

writing an implementor’s guide would have required interacting with implementors, and too many of the implementors at the time were insufferable fuckwits

I am monumentally unsurprised.

Posted by Aristotle Pagaltzis at

links for 2007-05-23

Classmate PC - Intel’s move to overthrow the OLPC since it uses an AMD chip (tags: Intel) 300+ Easily Installed Fonts for Ubuntu (tags: Ubuntu) JavaScript: The Lingua Franca of the Web Some programmers will do almost anything to avoid getting...

Excerpt from All in a days work... at

Sam Ruby: Crossfire

Just use Atom. :)...

Excerpt from Public marks with tag rss at

Add your comment