August 26, 2005
@ 06:15 PM
Comments [4]
Microsoft's Simple List Extensions Specification Updated
Sean Lyndersay has posted about an update to the Simple List Extensions specification. The update fixes some of the issues that were pointed out by members of the RSS community such as the problem pointed out in Phil Ringnalda's post MS Embraces RSS because RSS elements were being reused outside their original context. The cf:listinfo element now has the following structure

<cf:listinfo>
  <cf:sort
     ns="namespace"
     element="element"
     data-type="date|text|number"  
     label="User-readable name for the sort field"
     default="yes|no" />

  <cf:group
     ns="namespace"
     element="element"
     label="User-readable name for the grouping" />

</cf:listinfo>

This is a lot better than the original spec* which instead of naming the element being sorted on using attributes of  the cf:sort element actually included it as a child element instead. The only problem I have with the spec is that I don't see where it states the date format that is expected to be used if the data type is date. I guess this was problematic since different syndication formats use different date formats. RSS 2.0 uses the RFC 822 format, Atom 1.0 uses the RFC 3339 format while Dublin Core [which is what RSS 1.0 dates typically are] uses the format from the W3C Note on Date and Time formats. So an extension element really can't define what the date format will be in the feed it is embedded in since it may be embedded in an RSS or Atom feed.

That is a potential gotcha for implementers of this spec. I think I'll pass at implementing support for the Simple List Extensions spec in RSS Bandit this time around since my plate is full for this release. I'll add it to the list of features that will show up in the following release [tentatively codenamed Jubilee].

* I would have linked to the spec but as usual MSDN has broken permalinks such as http://msdn.microsoft.com/longhorn/understanding/rss/simplefeedextensions/ . Someone really needs to force everybody that works there to read Cool URIs don't change.


 

Categories: Syndication Technology

« MSN's Vision for Social Software | Home | Google Talk: Disappointment or Another E... »
Friday, 26 August 2005 18:45:42 (GMT Daylight Time, UTC+01:00)
Heh. Other than approximately in Topics and Classification by subject, Cool URIs forgot to mention "never ever use your 'internal' code name in a URI."

I was trying to find the spec the other day, post-Vista, but I couldn't figure out whether I wanted to get /connected/, or have something /integrated/, or what. The current division of content reminds me of what I hate most about Dell - if you want to know what laptops they sell, or what printers, tough; first you tell them whether you are a consumer or a small business or a government agency, and then they'll tell *you* what they want to sell you.
Phil Ringnalda
Friday, 26 August 2005 20:08:57 (GMT Daylight Time, UTC+01:00)
Dare,

Atom requires an uppercase timezone separator and an uppercase Z in the absence of a numeric offset. This makes Atom dates compatible with W3C-DTF, as well as XSD dates and ISO 8601.
Robert Sayre
Friday, 26 August 2005 20:20:04 (GMT Daylight Time, UTC+01:00)
On the MSDN permalinks: that's one of the main features of msdn2.microsoft.com, and it's coming to all the MSDN content, not just the Visual Studio 2005 and .NET 2.0 docs.

The permalink problem at msdn.microsoft.com looks like a problem of the MSDN team: after all, they're the ones who host the content.

But it start with the way the help content is authored. It's put together in CHMs that *only need to be internally consistent* with their topic paths. As long as their own pages and tables of contents can find the pages, it doesn't matter what the actual path is, and whether the path changes from one update to the next.

As soon as the CHM is turned into content on the Web and the internal paths of the CHM file become URLs, it does matter, of course. Given the way help content has been assembled for years at Microsoft, there isn't a lot that MSDN can do unless they can change the way the topics are authored, identified, and managed.

Today, there aren't unique identifiers on topics, and there's no good way to communicate that a given topic that used to be at path /foo/bar is now at path /baz/quux. Or, even worse, that the topic that used to be at /foo/bar is now split into two pieces and some of it can be found at /baz/quux and the rest at /thud/grunt.

Getting permanent URLs of the form you see at msdn2.microsoft.com required an enormous amount of work with the product teams, the teams that make the content tools, and work to revamp an online publishing system whose core has been around for a decade.
Tommy Williams
Saturday, 27 August 2005 00:09:37 (GMT Daylight Time, UTC+01:00)
I should start a campaign or something to eradicate RFC 822 from the list of possible date time formats for future specs. It is one of the most annoying formats to consume programmatic (esp. in XSL). And I question any human readability claims.

Sorry to highjack this post for a personal pet rant, I kept it abbreviated at least :]
Björn Graf
Comments are closed.