intertwingly

This is a slightly more formalized write-up of a proposed profile for RSS that has been discussed and brought up again. Rather then just produce an iteration of what Don Box wrote up, I thought I'd take a step back to codify some of the design... [more]

Trackback from tima thinking outloud.

Under Channel: "Only one title, description or link is permitted."  Does this mean only one of the three, or only one of each?  They are all required so I'm guessing the latter.  If that is the case perhaps change the language to "Only one each of title, description and link is permitted."

Correct Lance and noted. So is my use of depreciated instead of deprecated.

I never did like the one channel per feed limitation, but since it's part of the RSS 2.0 spec anyway, I can live with it. In any case, this is redundant: "Item -- Notes: Recommended to not exceed 15 per channel." since there is only one channel.

One more housekeeping item, Tim. I think "modulized equivelant" should be "modular equivalent" Thanks!

Christian: Thanks and noted. I will rephrase that to read "Total number of items SHOULD NOT exceed 15."

Suggestions for inserting more standard specification language (MAY, SHOULD, SHOULD NOT) is appreciated.

Interesting, his section on tag mappings uses a bunch of prefixes instead of namespace URIs and even better doesn't point out where one can find the docs for said elements.

PS: Exactly what is supposed to be the impact of the "RSS Core Profile" on aggregator authors?

Christian: RSS supports any amount of channels that you want. You just have to put them in a namespace extension. For example <channels:channel>. Remember RSS supports extensions, so we can pretty much add anything we want to RSS profile.

Yes, I am joking. But also trying to make a point.

Sorry, Randy, but your point is lost on me. I get it, but I could just use RDF. Also, I think you're missing the point that Timothy states here when you wrote "The RSS profiles presented by Don Box and Timothy Appnel invalidate all of these three blogs. In fact, the profile invalidates most of blogosphere." I'm sure aggregators will continue to support RDF or RSSx.x in some fashion, but, by definition, the profile is forward looking. Non-compliance with the profile doesn't mean inaccessibility or deprecation. It simply means non-compliance with the profile. It is up to each individual tool author to decide how to handle non-compliant feeds. If the history of the web is any indication, I think these blogs will continue to be handled by the major aggregators. This does not mean that those who want to codify best practices should merely resign themselves to the status quo.

RCM: if you had a tool which could use that information, and an example that I could follow, then I do my best to provide it.

I am not just saying this to make a point, it is something that I have consistently demonstrated over the last 18 or so months.

Dare: Good point. I was rushing a bit and tried to avoid typing out all of those URIs. I'm well aware that prefix does not necessarily map to a specific URI. I will work that into the next draft. Thanks for the feedback.

The impact on aggregator authors like yourself is better predictability. This will take time to realize will require further steps such as implementing warnings into the RSS Validator that are based on some best practices I'm trying to codify here.

Charles: You're jokes aren't funny. They are a distraction. Please stop. The point you're persisting to make is off-base (my opinion, but no one else is concuring with you either) and without creditable backup. If you're going to think outloud do it properly -- I'd love to hear it.

Tim, my apologies. I did not mean to offend anyone.

After 'crossing swords' with Sam not too long ago, I was a bit hesitant to post here again, but during a private email exchange with Tim, he encouraged me to put up some questions.

Here 'tis:

1) Why, exactly, is there a [recommended] 15 item per channel limit?  Why not 32, or 100? Why a limit, really?

2) Is there anything (particularly on a philosophical level) that would prevent me from linking to other rss channels within a given item within an RSS document?

With these questions, consider the following scenario:

Consider an online encyclopedia carefully architected to follow the principles underlying REST, where queries are formulated as URI's.  From this, I can offer rationales that justify each of the above questions.

The rationale behind my first question would be this scenario: A result set could be sent back as an RSS file, which could conceivably return a much larger set of results than 15.

The rationale for the second question would be this scenario:  A result set would be limited to not more than 15 items, but if I get, say, 20 hits for a query, then I can receive an RSS file that contains 14 items to actual results; the 15th item would be a link to an RSS file containing results 15-20.

I have a question regarding this:
"Those wishing to embed markup language or larger pieces of content in the description tag should use the mod_content module."

What happened to <xhtml:body>? Is it not going to be mentioned in the profile and is there a reason for specifically recommending mod_content over <xhtml:body>? If anything, I would be apt to recommend <xhtml:body> as the element of choice.

Robert, see the RSS 0.91 spec and DTD.  The limits were there in the beginning.  Now imagine that you wrote a tool to that specification a few years ago.  What would you do with a feed from today?

A persistent theme of my weblog writings has been extensibility.  I look at this both from a producer as well as a consumer side.

As to whether the limit should be 15, 32, or a 100, I don't worry too much about that.  A feed with a thousand items is valid RSS 2.0.  The most you will ever see is a warning that this might be a bit excessive, and that not all consumers will appreciate what you have done.

Robert does make a good point and I take all responsibility for it appearing here. ;)

> As to whether the limit should be 15, 32, or a 100, I don't worry too much about that.

Should I strike that limit from the Core and leave it up to said profiles that use it as a foundation?

Christian: In reviewing the previous discussion the general consensus seemed to be content:encoded over xhtml:body based on the +1's where posted.

Some reasons cited -- content:encoded was more commonly used today and was easier for publishers. xhtml:body would require authors to produce perfectly valid xhtml each time. Sadly this is the exception and not the norm for most. Jon Udell made a rare post and asked if there was room for both in order to incent tool makers to emit better (and valid) xhtml. Ironically Jon's feed breaks my RSS plugin which is why he's not listed on my I Read page. This is my bad of course because I didn't fully support namespaces as I should have and I need to fix it. thankfully the practice is not wide spread. I suspect that many more may have made the same assumption that I did. Would in-line xhtml:body element be nice? Yes, but I don't think its time is here yet. That said I'm open to allowing both.

Also keep in mind that I took a small step back from Don's work to define the core design considerations that others may be based on.

My feeling is that every specification that has ever called itself RSS has required well formed XML.  If your aggregator breaks when xhtml:body is present, then you have a bug, pure and simple.  I don't mean to imply that you have to do anything but drop the bits on the floor, but your tool shouldn't spill its guts in the process.

Longer term, I would prefer to move away from grammars achieve XML well-formedness by virtue of obscuring structure via XML encoding.

I suppose I'll just come out and say I'm strongly against Timothy's core profile. The problems:

1) No namespace. Let's kill this bird dead. The profile isn't a true standard--it's kind of our 'idea' RSS document right? Well why not suggest people use a namespace? Sure nobody but a few will do it but we need to start somewhere.

2) Not enough. Timothy's core elements simply provide little gain over RSS 0.91. The plain-text description is nice but why not per-item authors? Which leads me to the third point...

3) Heavy reliance on modules. I just don't see the justification for making developers wade through a bunch of modules to get at core information like author. I also don't see much point in making consumers play the module game eg picking between dc:source, ag:source, and the like. Core functionality, and even non-core functionality like 'image', doesn't belong in modules. I'd say the heavy reliance on modules violates the Really Simple constraint.

4) Technically all RSS consumers are (contain) XML parsers and according to the XML spec there are certain things you must do like support namespaces and certain things you mustn't do like guess at the form of the document. If we're not going to set even these minimal constraints then we'll be back here in six months.

5) Please layer with other specs. Why not support xml:lang and xml:base? I thought this was in the Box profile, what's the motivation for removing it?

Timothy,
I have to concur with Sam here. I currently produce two separate feeds that use content:encoded because it was the easy way out at the time since I can't control the content directly. However, there's no real reason I can't tidy it up before outputting it as RSS, in fact, I mean to. At the very least, I'd like to see <xhtml:body> recommended on par with mod_content.

Bo,
1.) By definition a profile is a subset. A profile of RSS 2.0 that put RSS elements in a namespace would not be a subset of RSS 2.0 but an entirely different spec.

2.) By definition any profile of RSS 2.0 will probably end up looking like RSS 0.91

3.) Modules are RSS's killer app. half the interesting things that can be done with an RSS feed via RSS Bandit rely on modules (dc:date, content:encoded, xhtml;body, slash:comments, dc:author, wfw:comment, etc)

4.) What incarnation of the XML 1.0 spec says that you MUST support namespaces? This is patently incorrect given that the Namespaces in XML recommendation is about a year older than the XML 1.0 recommendation.

5.) How many RSS aggregators do you know can properly handle xml:base if it was required?

PS: When are you going to start providing an RSS feed for your blog? I'm half considering starting up a screen scraping service. :)

Sam: That the limit of 15 was there from the beginning I had always known - my issue was related to why that particular number?

What would I do if I wrote a tool that handled the 0.91 spec a few years ago and had to deal with a feed from today?  I would do one of two things: I would either take the first 15 items and ignore the rest, or I would patch the program to become more extensible and accept more than 15 items.  Evolve or die.

But the thing is, maybe the example scenario I used was never meant for the 15-item feed aggregators.  Maybe I wanted to use RSS because it's a well understood format that could be viewed by an aggregator for development purposes, that contains a spec that is easy to 'view source' with, but is meant to be processed, for the most part, by completely different kinds of programs.

If the hypothetical encyclopedia I proposed was geared to all things found in the Computer Science domain, and you're writing about new things related to this area of expertise, wouldn't it be nice to be able to help new users through your writings by somehow providing them with a 'related reading' section that was simply RSS data from the encyclopedia transformed into [X]HTML?

Let me bring this back on topic.  Tim is proposing, from what I understand, to codify a minimum set of constraints that all RSS feeds share in order to be considered RSS. When you want to get RSS 0.91, you add additional constraints to get the 0.91 spec.

I would propose that, since it so far doesn't seem to matter to some of us what the limit should be, that there should be no limit.  Let the limits be an additional constraint inherent within the various versions of RSS.

Robert, I don't think this is the intent of the profile: "Tim is proposing, from what I understand, to codify a minimum set of constraints that all RSS feeds share in order to be considered RSS." I think that conformance to the RSS spec indicates whether or not something is considered RSS, the profile is merely a guideline for those wishing to implement what we consider to be "best practices".

<OffTopic>(Apologies in advance)
Sam: Could/do you support an interface to pose questions or address comments to you that don't necessarily correspond to a previously blogged item or topic? Perhaps even something as simple as dearsam@intertwingly.net or asksam@intertwingly.net. For example, I'm curious as to how you came up with your domain name. There may be other interesting (or not so interesting) things your readers may want to get your take on. It goes without saying, of course, you would select which items to respond to... but this way we wouldn't have to pollute topics with irrelevant posts like I am doing right now.</OffTopic> :)

Robert: the number of items in an RSS feed will not affect whether or not such a feed validates.  I do believe that it would be helpful if some warning were issued when the number of items is excessive.

Christian: I'll hold off on an askSam or similar feature until the flames die down.  Meanwhile, you can find what you are looking for here or here.

Bo: Adding to what Dare said on your second point, this profile allows for modular extensions via namespaces which is a huge gain over RSS 0.91. With that extensibility available a whole new dimension is opened for the format. Which, to your third point, needs to be applied consistently and, in my opinion, with as few redundancies as possible for the sake of clarity.

Why not an per item author? Because a feed could be generated by an application or as part of an API where there is no author.

Based on feedback collected from the comments on Sam's weblog I've updated the draft of the core profile.... [more]

Trackback from tima thinking outloud.

Tim, to your last point, why couldn't item:author be optional then?

Lance: Because we are trying to define a "core" that other profiles will be layered on top of. Also dc:creator exists, is in wide use and has its advantages over author.

My comments on the outstanding issues: How to identify the profile/version? What would be wrong with this?
<rss version="2.0" xmlns:profile="http://purl.org/rss/2.0/modules/profile">
<profile:version>1.0</profile:version>

etc. This has the benefit of allowing the RSS version to remain constant, while simultaneously identifying a feed that complies with the profile and leaving room for future iterations of the profile. I'm not stuck on the structure, just the intent.

Link: http strongly recommended.
content:encoded/xhtml:body: I say strongly recommend xhtml:body, yet allow for content:encoded. Profiles that build on the core can be more restrictive.

Christian: Interesting idea about the namespace. I like it, but judging by the number of XSLT processors reporting issues that may be problematic to implement in reality.

Your preference on content:encoded/xhtml:body is noted. I agree this is something that should drop to profiles that build on this.

That mention of content:encoded is just a footnote for those familiar with the practice of place encoded HTML in the description tag.

great discussion at sam ruby's. tim appnel is documenting the consensus....

In further proof that, petty squabbles and under-specification notwithstanding, the pervasiveness of RSS is a veritable inevitability, Cafe au Lait, one of the best resources for news on Java package releases, has added a feed. Cafe au Lait now... [more]

Trackback from Christopher Elkins's Weblog