Archive of UserLand's first discussion group, started October 5, 1998.

---

Re: What to do about RSS

Author:	Chuck Shotton
Posted:	9/3/2000; 1:47:34 PM
Topic:	scriptingNews outline for 9/2/2000
Msg #:	20773 (In response to 20762)
Prev/Next:	20772 / 20774

You mentioned in an earlier post that you wanted to see a few simple additions to RSS. What are they?

Here are a few off my "A" list. I'm certain there are more I've got scribbled down somewhere. Let me list these, then some ideas on possible fixes.

Problems/Requirements

1. Text in title and description tags doesn't have a specified encoding scheme and an allowed set of entities beyond what XML tolerates.

2. The "description" portion of an item has poorly defined semantics under 0.91. The payload type is unspecified and there are no provisions for specifying one.

3. Multiple titles and descriptions could be allowed for a single item, assuming multiple content type or encoding schemes are presented (allowing for multilingual versions, plain text vs. mark-up, etc. to all appear in a single RSS document (more in a sec on this.)

4. Information about updates, availability, and frequency are not particularly useful in their current form.

Some recommendations

1. It should be explicitly stated that the default type for text data in titles and descriptions is the equivalent of the text/plain MIME type. There are dozens of RSS sites on the net that intermingle HTML, multibyte characters, and all sorts of other unexpected stuff in what would seem to be plain text.
2. I'd propose adding two additional tag attributes for title and description tags:
   contentType and encoding

   contentType would contain the exact same information as the content-type field in a HTTP header, i.e., the MIME type of the payload data appearing between the appropriate begin and end tags. The default contentType would be text/plain if unspecified. encoding specifies what transformation(s) may have been performed on the content to get it into a form acceptable for inclusion in the XML document. e.g., a description payload might contain content of type text/html and need to be encoded using something like base64. The default encoding would be that of the enclosing XML document (generally none beyond the character set selection.) The only other alternate encoding of any significance would probably be base64.

   Here are some examples: