Responses to Sean Palmer's comments on the RSS-DEV list.
* The default namespace for RSS 2.0 feeds is never mentioned; it's impossible to tell whether it's required or not.
I emailed extensively with several namespace gurus about this, including XML 1.0 author Tim Bray. I basically followed their advice. I think this should be discussed on the mail list, or offlist, and you guys tell me what to put there. I understand that there are tradeoffs no matter what we do. Check with Fredrik Lundh and Mark Pilgrim on the situation with Python.
* The specification says that /rss[@version] is mandatory, but it doesn't say what value it should take: we can gather from all the examples that it's "2.0", but that brings me to my next point...
That's correct. The spec should say that the version must be 2.0 (and this will change when the version bumps to 2.0.1).
* The specification could really do with including a normative example at the bottom. Many people learn simply from cutting and pasting, so why not put something in there to learn from? I know that it links to an example 2.0 file... but it doesn't say whether or not it's normative.
Not sure. It doesn't illustrate all the features of 2.0. But it is a 2.0 file.
* The list of language values that are allowed [1] is quite restrictive. I've not yet read an explanation for this restriction, but of course that doesn't preclude one from being extant.
The list of languages came from Netscape. At the point where the list is included in the 2.0 spec (this is new in 2.0) it says: "A list of allowable values for this element, as provided by Netscape, is here. You may also use values defined by the W3C." In other words, this was addressed in the 2.0 spec. The W3C spec referred to is:
http://www.w3.org/TR/REC-html40/struct/dirlang.html#langcodes
* The documentation for <link> and
HTML is allowed. This is specifically stated in the docs for the sub-elements of <item>. It must be encoded, again as stated in the spec. The information is there.
* "lastBuildDate"'s documentation should also note that the value must conform to RFC 822, if it should.
It should conform to RFC 822, with the caveat, as stated in the spec, that years may be 2 or 4 characters, with 4 preferred.
* Is the value of <category> space separated, or what? What's the specification of the tokens that are allowed? What if I use line breaks to separate the categories? Do I have to Capitalize them? Once again, this is quite ambiguous, and data which would be useful to authors.
The spec calls for forward-slash separated strings. A lot of your comments are about things that *are* addressed in the spec.
* <docs> is redundant if the namespace declaration is required. YAGNI.
I don't know what YAGNI means. I strongly disagree that <docs> is redundant. There have already been suggestions that the namespace point to a RDDL file. <docs> must be there to maintain backward compatibility with previous versions of RSS.
* Why can't <image> support SVG, TIF or whatever too?
It doesn't because previous versions didn't allow for it, and no one has suggested it, and people argued persuasively for deprecating <image> and I personally don't care either way, but if others feel that these formats are very important let's allow for them.
* "The purpose of the <textInput> element is something of a mystery." So why was it included? Once again, YAGNI.
Ask Dan Libby. Perhaps it needs to be said more clearly. 2.0 is continuous with previous versions of RSS. That's all the justification any element requires.
* isPermaLink="true": why punish people who provide nice persistent linsk for their feeds by making them add more data? Get people to state when they *aren't* going to maintain their item, not when they are.
The default for isPermaLink is true, so people who provide nice links are not punished.
* "forowarding": typo under the definition for <source>.
Will fix in 2.0.1.
* Under <category>: "The value of the element is a forward-slash-separated string that identifies a hierarchic location in the indicated taxonomy." An example of the use of forward slashes would be good: at the moment, there's just an example of two space separated things.
Got it. An example would be good.
* <guid>: GUID is a bit of a misnomer here, since "GUID" is a popular alternate name for a UUID. At least this one is well documented. The semantics of this element reminds me a lot of Sandro Hawke's "uname" proposal, which is interesting in itself. I probably would have chosen something like <uniqueID>, and said that it can only take a URI-ref as its value (there was a UUID URI scheme internet draft a while ago; most people use "urn:uuid:").
This was vetted back in May. I did get feedback, responded to it, etc. RSS is an imperfect format. The names chosen for the elements are the worst possible choices.
* <author>: "It's the email address of the author of the item." But the example gives the email address, and the owner's name in parenthesis. Inconsistent. How are aggregator builders supposed to interpret it? Split on any whitespace, and use the first token as the email address, most likely.
That's generally how the examples have treated email addresses in RSS in the past.
* In Comments: "The data in these elements must begin with http:// or ftp://. Among others, https:, file:, mailto:, news:, and javascript: are not permitted." Potentially a bad idea, but I think it's something that need(s/ed) discussion. I recall someone mentioning it here before.
Again this was a Netscape rule, and I didn't feel strongly that it needed to be relaxed. Morbus argued for it, but I don't know if he had a burning need for it, or if he just wanted to discuss.
* The point about guid vs. link is helpful. However, it does make me feel that <guid> is worthless. Just require <link> to be a permalink (whatever that means), and be done with it, perhaps?
Believe me, guid is very useful. I probably should write a more detailed explanation of the diffs. Would you read it if I did?
* Namespaces. This section is very sketchy indeed for me: can we use a prefix on the elements now that 2.0 uses XML namespaces? Will that break current aggregators? Where can we add the new data: can we put it above the root element, or add it on as non-prefixed attributes, or what? How should we document our extensions, and are there any sorts of extensions that are liable to break aggregators? Is there a general theme (e.g. adding new optional elements under channel/item) that is most recommended, and if so, why? Should aggregators look out for these common forms of extensions? If so, how should they handle them?
I don't think any aggregators mind if a feed contains elements they don't understand. This has been an assumption all along. You can add new data anywhere you like, as the spec says, but it's just common sense (or so it seems to me) that the structure called for in the spec must be adhered to. You can't put any data above the root element because that would break its XML-ness. In any case, I'm not going to try to, myself, write a style guide for namespaces. I think Morbus did a great job of putting forth a strawman for people to comment on.
General comment -- I responded to these points directly. No doubt someone will take issue with how I said something. So be it. Time is short. Gauge interest by the amount of thoughtful debate. Let's all try to filter the ad homina.
