Update: Added question on multiple <cf:listinfo> elements.
Just passing time with my everyone-has-one while waiting for official word:
cf:listinfo without cf:treatAs should be ignored by consumers, and should be a validator warning - it’s not illegal, but a pretty strong sign of an oops. (And since order isn’t specified, I guess linear parsers have to go through the motions with cf:listinfo, since they don’t know if they’ll see a cf:treatAs later in the file.)
Repeating an element in cf:sort or cf:group shouldn’t mean anything - aren’t they both just booleans, so it doesn’t matter how many times you set $sort['dc:date'] = true;? I’d say the same thing goes for having more than one each of cf:sort or cf:group, which I thought at first was what you were asking, though their IG ought to warn consumers not to choke on either sort of repeat.
If an item is in both, then the top of the column for that element’s content ought to have a “sort-by” widget, and each item’s value ought to have a “only-these” widget by it. Doesn’t seem like a problem to me, am I missing something?
Lacking the element for a cf:sort ought to make it null, and where you put nulls is either up to your sorting algo (which I’d guess means first, mostly) or up to where you shove them out of the way (last would probably usually be better). Lacking the element for cf:group doesn’t strike me as any more of a problem: if you are using it to filter by category, then “only this category” on an item without a category should show all the items without a category. ("Group" I’m not sure about, unless it’s a synonym for sort.)
Did you know that your asterisks-to-ul code doesn’t tolerate having a comment end with a list item? I tried to stop there, but it wouldn’t let me.
Repeating an element in cf:sort or cf:group shouldn’t mean anything - aren’t they both just booleans
What does the following mean?
<cf:listinfo>
<cf:sort>
<my:field data-type="date">my field as date</my:field>
<my:field date-type="text">my field as text</my:field>
</cf:sort>
</cf:listinfo>
If an item is in both, then the top of the column for that element’s content ought to have a “sort-by” widget, and each item’s value ought to have a “only-these” widget by it.
I don’t see widgets mentioned in the spec, but as an analogy, mysql doesn’t particularly care for statements of the form:
select * from item order by pubDate group by pubDate;
Lacking the element for a cf:sort ought to make it null
I wish I could remember who sat on the other end of Socrates' log.
Ignoring the typo in the attribute name, repeating an element for sorting with two different data-types means that the publisher thinks it would be useful to allow sorting of the list by that element in either order. Erm. Full RFC 2822 dates, where a date sort puts January 1 first, and a text sort puts weekdays together? Had they asked us before they announced, I would have +1’ed your request that an element only be allowed to have one data-type, since that’s the closest I can come to a useful example of an element having two, so I doubt that implementors will actually provide for multi-type sorting. Which means that the sorting algo for that example will be unpredictable, with some implementations saving the last data-type they saw, and others discarding any later data-types once they’ve seen one, which makes it a validator warning if MS won’t give us spec text, and an error if they will.
Widgets I inferred from the typoed
The consumer of the feed should then use the cf:sort and cf:group elements to show a user interface that allows the user to sort on the item properties listed under cf:group, and to filter/group by the items listed under cf:group.
Since, most curiously, there’s no spec text to say which of multiple sort elements is primary, and that the primary (or for that matter any) sort should be used for initial display, I’m assuming they mean for implementors to start with whatever order pleases them, and let the user tell the program if she wants to sort by a cf:sort element, which I suspect will usually show up like the column heads in Windows Explorer’s “details” view. How that gets shoehorned into a typical aggregator is left as an exercise for the poor implementor.
While I still think having an item that doesn’t contain the sort key isn’t an error, I would hope that if someone says that pubdate is a sort key then no items would contain it, which is certainly very good cause for warning.
Markup in the human readable name? How would you be able to tell whether or not it was (escaped) markup?, he asked in a wide-eyed and innocent way.
1. cf:listinfo without a cf:treatAs means that you should sort and group the feed using those fields but you shouldn’t apply list semantics to deleting items and the like.
2. Ignore latter occurences of the same element in cf:group and cf:sort.
3. It means you can both sort and group by the field. E.g. the category element.
4. That’s up to the client to decide. This is no different from what clients that can sort by category need to do when some items don’t have a category.
5. The readable name for the group can’t contain HTML.
PS: I’ll talk to Sean about adding these to the spec.
1. cf:listinfo without a cf:treatAs means that you should sort and group the feed using those fields but you shouldn’t apply list semantics to deleting items and the like.
OK, so no error or warning.
2. Ignore latter occurences of the same element in cf:group and cf:sort.
Sounds like a warning is merited here.
3. It means you can both sort and group by the field. E.g. the category element.
OK, so no error or warning.
4. That’s up to the client to decide. This is no different from what clients that can sort by category need to do when some items don’t have a category.
I’ll probably do something like what Phil suggested, i.e., produce a warning if none of the items match, unless the field is a well known one (like category).
5. The readable name for the group can’t contain HTML.
Not 100% foolproof, but I’ll probably produce a warning if I see some sequence like </ in the readable name then.
PS: I’ll talk to Sean about adding these to the spec.
Here’s a bunch more feedback about the RSS announcements made yesterday: Phil Ringalda: MS Embraces RSS. “Simple List Extensions: ouch. That crunching sound you heard was me getting bit on the butt, hard.” Dave Winer: Quick postscript on Microsoft...
Now, Mark. In RSS today, we have more than our share of the nattering nabobs of negativism. When will the impudent corps of effete snobs stop their pusillanimous pussyfooting? Why should RSS be held hostage by hopeless, hysterical hypochondriacs of history?
Data above the level of a single site is immensely valuable to people. If you’re in the software business and have you’ll know by by now that data is the new platform. Which is why David Berlind’s take on Microsoft’s RSS is disappointing ...
[more]
Mark Evans :: Frustrations With Blog Search (and Technorati) Daily Source Code #200 Micro Persuasion: The Day RSS Turned Pro Subscribe to Your Own Feedburner Statistics How To Use Mime-Types To Get Your Aggregator To Subscribe To An Atom ... As I...
Mark Evans :: Frustrations With Blog Search (and Technorati) Micro Persuasion: The Day RSS Turned Pro Subscribe to Your Own Feedburner Statistics How To Use Mime-Types To Get Your Aggregator To Subscribe To An Atom ... Bill de h�ra: Expect...
More reactions on Microsoft’s RSS announcements. Here’s a bunch more feedback about the RSS announcements made yesterday: Phil Ringalda: MS Embraces RSS. "Simple List Extensions: ouch. That crunching sound you heard was me getting bit on the butt,...
Reactions to MS RSS announcement (some repetition here).
Reactions to MS RSS announcement (some repetition here). More reactions on Microsoft’s RSS announcements. Here’s a bunch more feedback about the RSS announcements made yesterday: Phil Ringalda: MS Embraces RSS. "Simple List Extensions: ouch. That...
I’m looking into adding FeedValidator support for Microsoft’s Simple List Extensions Specification, and have a few questions. – Sam Ruby So now developers of RSS readers that want to consume podcasts have to know how to consume the RSS 2.0 element,...
Dare Obasanjo: Gnomedex 5.0 Trip Report: Dean Hachamovitch on Longhorn, IE 7 and RSS Phil Ringnalda: MS embraces RSS Sam Ruby: Simple List Questions...
Microsoft introduced the term shared source, and now seems to be extending their unique idea of “sharing” to syndication. The first attribute that the the Simple Sharing Extensions for RSS and OPML is to “treat the item list as an or...
[more]