2009/5/18 Peter Keane
<pkeane@xxxxxxxxxxxxxxx>
Here is an excerpt from RFC 5023
This is the basis of my suggestion of using atom:category to specify
that an atom:entry is of a particular "kind" or exhibits particular
properties. And filtering on such is already built into the AtomPub
spec:
---------------
8.3.6 The "app:categories" Element
The "app:categories" element provides a list of the categories that
can be applied to the members of a Collection. See Section 7.2.1 for
the detailed definition of app:categories.
The server MAY reject attempts to create or store members whose
categories are not present in its categories list. A Collection that
indicates the category set is open SHOULD NOT reject otherwise
acceptable members whose categories are not in its categories list.
The absence of an app:categories element means that the category
handling of the Collection is unspecified. A "fixed" category list
that contains zero categories indicates the Collection does not accept
category data.
Categories can be useful but in the case specified by Nikunj in the hierarchy I-D, we really need another mechanism to describe the behavior (master/children).
For example in my case (Feedbooks), categories are useful to describe the nature of each entry (part/chapter/section), but the rel values/h:role as described in the hierarchy I-D fulfill a different purpose (describe the behavior) and I don't want to mix both of them together.