[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Notes on the RSS 0.91 2000-06-09 draft



Typos:

 - Under "About this document", last para: "is explains"

 - Under "What is RSS?": RSS is not an XML dialect, but an XML
   application.

Technical comments:

 - Remove the maxlengths. Alternative, rephrase them to be guides to
   people as to what a good length is. Ie: make it a guide to proper
   use rather than a pointless technical requirement that people may
   feel a need to enforce in software. URLs shouldn't have them at
   all.
 
   I know they are included because Netscape included them and because
   people seem to conform to them, but please let us lose them as soon
   as possible.
 
 - language element: the list of allowable values seems to be a subset
   of RFC 1766 language code. Why not just specify that? If this moves
   us into RSS 0.92, then I'm perfectly happy with that.

 - What is the difference between pubDate and lastBuildDate? I have
   read the both the Netscape spec and yours several times, and I
   still have no idea. If nobody else knows the difference either,
   perhaps one should be deprecated.

 - textInput could be explained in more depth. The spec never says
   what it is suppose to be used for.

 - The values of the skipDays and skipHours elements are not well
   explained. Does RSS 0.91 really use <day> sub-elements? This is not
   what the RSS 0.91 DTD says.

   Also, the description of the skipDays element seems to have a typo.
   During _days_ listed in the element, no? Days are presumably also
   GMT? Hours should be 0 to 23, no?

 - purpose of image should be explained.

 - textinput/title: the label of the submit button. I think that
   description is too specific, in that it assumes a web interface.
   Some RSS client are not web-based and I see no reason to disallow
   these. IMHO the element should be explained in terms of its
   function.

 - textinput/name: What is this?

 - URLs: allow empty URLs or item URLs to be left out? This opens for
   'inline' content a la scriptingNews. data URLs could also do it.

 - image shouldn't be required. It's not required in RSS 0.91 and it
   does not make sense to require it anyway.

   <URL: http://my.netscape.com/publish/help/mnn20/quickstart.html >

 - Also, the current specification (RSS a la Winer :-) leaves a lot
   undefined. In my opinion it should use some kind of formal
   definition of its structure. Doing so clarifies so many things that
   I think it is worth the bother. Below is a quote from a document
   I've written about RSS:

      Below is an informal DTD that shows the RSS structure. Elements
      that are not defined have #PCDATA content. Although the DTD
      requires elements to have a particular order, RSS does not. The
      DTD does this because it would be very difficult to describe the
      structure otherwise.
      
      <!ELEMENT rss (channel)>
      
      <!ELEMENT channel (title, link, description, language, image?,
      			 copyright?, managingEditor?, webMaster?, rating?,
      			 pubDate?, lastBuildDate?, docs?, textInput?,
      			 skipDays?, skipHours?, item+)>
      
      <!ELEMENT image (title, url, link, width?, height?)>
      
      <!ELEMENT item (title, link, description?)>
      
      <!ELEMENT textInput (title, description, name, link)>
      
      <!ELEMENT skipDays (day+)>
      <!ELEMENT skipHours (hour+)>

--Lars M.