On Nov 8, 2004, at 1:57 PM, Bill de h�ra wrote:
http://www.intertwingly.net/wiki/pie/PaceCategoryElement -Tim
Good idea, -1 on the details.
If there can be zero or more, The categories should be placed in an atom:categories block (we made this mistake before with entries and solved in inversely via the atom:head element).
Why? It's clearly a good idea to separate the header material and the entries because some of the header material applies to the entries. It's not obvious to me what the benefit is from pouring the categories into a block. I'm not against it, just having trouble seeing where it would help.
The idea of a path based syntax is overconstraining.
Well, there's a lot of prior art there, and for the default text, it's handy to have some shared understanding of structure. If you want to use your own non-hierarchical category text, you can, just put it in a different namespace. Hmm... would you be happier with something like this?
<cats>
<cat>this/that/the other</cat>
<cat>foo/bar/baz</cat>
<otherNS:subject>funky non-hierarchical categorization info</otherNS:subject>
</cats>
The @domain attribute is redundant - let people use URIs if they want to use URIs.
Once again, just grabbing prior art from RSS2. Why change things without a good reason?
Feed level catgeories are dubious if only because a whole side-thread will start on catgegory defaulting.
Hmm... except for, people do cat-specific feeds. If others are against them, I'm not going to make a big fuss. -Tim
