Suppose tool X claims that it requires feature Y. The first question to ask is whether other tools have similar requirements. Find out what is common. Refactor.
Then see if what results is really required. See if there are other ways of achieving the same goal which might be better.
If the requirement survives to this point, see if it would place an unreasonable burden on other tools to support this feature. If not, the next stage is to see if we can agree to make the feature required. Required is good. It provides clear guidance as to what is expected. It makes the results predictable.
Dare: each item in my comments.rss2 feed has a wfw:comment element present. Can you be more specific about what you would like to see added?
Meanwhile, your message itself highlights a number of areas that we should get clear in s specification: exactly what should a title should be used for? exactly how many times should content be encoded?
Sam,
My bad. I was subscribed to the RSS 0.91 feed and didn't realize you already had taken care of this in the RSS 2.0 feed. As for the questions you mention my post raises
title: A title should be title of the content. The only reason my titles are my name are because I haven't had free time so haven't applied the changes to RSS Bandit that bring it in line with Joe's recent changes to the CommentAPI spec.
content: I'm not sure what you mean by how many times content should be encoded? Preferrably once. One of my major points of consternation when working on RSS Bandit was that content could be unencoded even if it was markup (xhtml:body), encoded, or even some times double encoded. I think I can handle most cases now but would love for one or two definitive ways of doing this as opposed to to three or four different ways that exist today.
Dare, I have no intention of putting namespace qualified elements in my rss 0.91 feeds.
Re encoding... it looks to me that you had encoded your content one too many times in your prior message. But this shouldn't be a judgment call, this should be clearly specified. Perhaps a concrete example would help.
Suppose I wanted a title of <foo>, with the angle brackets and all. One way to encode this that works with both HTML and XML would be:
<title><foo></title>
This presumes that title is a simple string. If, however, a title is meant to be encoded HTML, what you would end up with is a double encoding:
<title>&lt;foo&gt;</title>
content:encoded is most commonly used in this double-encoded manner.
Can you cite an example of xhtml:body that is incorrectly encoded?
I agree on the necessity of agreeing to a precise definition of "element" contents.
Somewhere else this issue was approached by providing specific alternatives for the various needs: http://purl.org/rss/1.0/modules/richequiv/
"Required is good. It provides clear guidance as to what is expected. It makes the results predictable."
How is required better than "support it fi you can"?
Aaron: lets talk specifics. In the case of perma-link and post-id, one can always put the same value in both. Why would you want to do this? I personally would prefer to sacrifice a little bandwidth for a bit of clarity.
See the second to the last paragraph here.
Sam,
Having a <guid/> and that can point to the same thing or are sometimes not always together breaks the "View Source" nature of the WWW. We've already seen how Dave's idea of how a very core element of RSS is different from that of most of the users primarily because most people just do a "View Source" then intuit what each element should mean.
Heck, I know that's what I did. Explanations that Dare's RSS feed for his kuro5hin diary has two elements with the exact same value because MT & Blogger have an internal database ID or that he may one day provide different feeds for different categories even though his kuro5hin diary has no way of creating category specific views will probably not fly. I deal with this kinda stuff every day at work when something that was designed for a narrow purpose is utilized in a broader scope than originally envisioned.
Re: Tim's comment about a small simple core: This may be hearesy, but I wonder what the goal of this approach is? I can see how from a blogging tool standpoint this makes things easier, but from an end user standpoint it severly limits the baseline functionality that we can consistently expect when interacting with feeds in aggregators. At some point here it seems the real activity that should be encouraged is consumption of feeds, not creation (allthough that's obviously important). If the focus shifts to consumption, and the types of applications/capabilities required for rich (read replacing the browser as primary reading tool), doesn't this argue for a richer core at the expense of simplicity?
An apology up front if this is a derail, or out of scope, I've been lurking for a long time, and I haven't really seen an aggregator-centric view of this being expressed. People like Brent Simmons have mountains of requests from users who want to take better advantage of syndicated content, and I'd love to see some kind of statement in the wiki, or otherwise that described the aggregator role in the discussion.
Re: Tim's comment about a small simple core: This may be heresy, but I wonder what the goal of this approach is? I can see how from a blogging tool standpoint this makes things easier, but from an end user standpoint it severely limits the baseline functionality that we can consistently expect when interacting with feeds in aggregators. At some point here it seems the real activity that should be encouraged is consumption of feeds, not creation (although that's obviously important). If the focus shifts to consumption, and the types of applications/capabilities required for rich (read replacing the browser as primary reading tool), doesn't this argue for a richer core at the expense of simplicity?
An apology up front if this is a derail, or out of scope, I've been lurking for a long time, and I haven't really seen an aggregator-centric view of this being expressed. People like Brent Simmons have mountains of requests from users who want to take better advantage of syndicated content, and I'd love to see some kind of statement in the wiki, or otherwise that described the aggregator role in the discussion.
Josh - if you take a look at the evolution of RSS, it started out with a few elements, mostly all of them required. Over time, new elements were introduced, some overlapping with the way others have traditionally been used, and elements which previously were required are optional.
Fundamentally, what I would like to see a return to a core set of elements that aggregators can depend on to be there. I think we are pretty much saying the same thing.
And, yes, I would love to hear from Brent. On the wiki, on his blog, or whereever he feels comfortable expressing himself.
Sam, I agree that it would be great if there were a base set that aggregators could depend on. I guess my concern is that this goal mainly supports the various classes of tool developers far more than it supports the users. If everyone is going to have to rev their code to support echo, does it make sense to have a discussion about the benefits users will receive after widespread adoption of the new standard? If all us readers get is the same headlines / brief descriptions as today, in part because the blog software vendors are deemed compliant just by supporting the core, I don't see what has changed.
As a coder, I totally understand the value of 1 clear, well defined, community owned spec. I just think the focus is making coding easier and limiting objections to adoption, and not on the applications that you want to enable and what it will take for an explosion of new users/capabilities.
The reason that I think a user/reader first approach would produce a dramatically bigger core is that a lot of the value in the content we subscribe to is spread accross many sites. I don't want (as an end user) to care that some of the sites in a discussion mix are hosted on platform x, and as such I lose aggregator feature y, at that point in the discussion. Very quickly I have to leave the aggregator and go back to the browser. A great example of this is threads, clearly not part of a simplified core, and just as clearly crucial to the readers experience. Why let UserLand, SixApart, Blogger, etc. off the hook for not producing this portion of the spec, by letting them say they produce core compliant echo? As a potential aggregator developer I can't rollout features that rely on a richer data set, because the user experience will suffer everytime a 'core-only' site comes into play. I guess I'm asking you to consider the user experience of the reader as well. We all agree that I should NOT care if I'm using MT, Manila, Blogger etc. if I want to create a new post from a blogging tool, why should I care what tool you use if I want to read a site (or better yet, a discussion spanning sites) from a next generation aggregator?
p.s. Thank you so much for taking this whole mess on. I'm a very passionate user of this technology, and I'm very happy to see some real collaboration and progress.
I seem to recall that it was SamRuby who made a comment on a weblog discussion that he would like to see more use of TrackBack.
It would seem that presently TrackBack functionality is problematic at times.
I wonder if TrackBack and the improvement thereof, is on the Echo Agenda?