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.
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?
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.
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?
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.
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:
<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">
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?
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.
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.
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.
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.
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.
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 AtomI’ll float this draft and see what the board thinks:
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.
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.
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.
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.
I posted the following on Rogers' blog yesterday morning, in this thread.
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.
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.
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.
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. :-)
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.
I’m following the board.
As long as you don’t purge dissenting opinions, fine.
Testcase? I’m not seeing that.just noticed that I’m getting that warning on an RSS feed that uses an atom:link for USM.
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.
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.
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.
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?
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!
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.