Tim Bray wrote:
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 category items belong together thematically. Given entry children are unordered I'd rather not see them peppered between other elements. I claim keeping the markup tidy is important enough to justify the parent.
Well, there's a lot of prior art there, and [...]
I'd say link to the prior art in the pace.
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>
I hadn't considered it; can't say if anyone else needs it.
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?
It's a {uri}name thingy. Do we really need another one of those?
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.
That's true; but as an implementor I don't know how to tell such a feed from another.
cheers Bill
