On Fri, Mar 27, 2009 at 10:52 AM, James Holderness <[email protected]> wrote: > > Peter Keane wrote: >> >> The fact that they don't use @label makes it trivial to have the >> category not display in environments where it shouldn't. > > I'm not sure I understand what you're suggesting here. In which environments > should categories without labels NOT be displayed? Would you consider a feed > reader such an environment? > > If so, are you suggesting that existing feed readers be rewritten to follow > this new rule? And would feed publishers with simple term-only categories > now need to add labels to all those categories in order to have them > displayed in these newly-rewritten feed readers? > > That sounds like an awful lot of pain for what you regard as an "elegant" > solution. Is "elegant" maybe slang for "dumbest idea ever"? >
I actually hardly ever think of the case of feed readers when I think about Atom, oddly enough. Since the spec says: The "label" attribute provides a human-readable label for display in end-user applications. (4.2.2.3)" I was assuming that was its actual role in the wild. I may be a party of one on this point (though I don't think so), but for my uses of Atom (essentially in the SynOA style [1]), a...@category is perfect for the sort of machine processing that I am likely to do with an entry or feed. And I have never had any problem using a reader to monitor application processing, etc. Inability to use a stream processor is an obvious issue which I have not confronted since I use DOM processing and a factory method that hands me the correct entry object based on the atom:category of interest. --peter [1] http://www.oreillynet.com/xml/blog/2007/09/synoa_what.html > Regards > James > >
