Hm. From what I can tell by RFC 5023, I can have:
1. Only one level of work spaces on the web sites. These can't be nested.
2. Only one level of collections within each work space. These can't be nested.
3. As many levels of categories I want through altering "scheme" values, like so:
<categories fixed="no">
<atom:category scheme="
http://example.org/acme/photos/" term="chrome" />
<atom:category scheme="
http://example.org/acme/photos/" term="products" />
<atom:category scheme="
http://example.org/acme/photos/products/" term="hats" />
<atom:category scheme="
http://example.org/acme/photos/products/" term="mittens" />
<atom:category scheme="
http://example.org/acme/photos/" term="illustrations" />
</categories>
Is this perfectly fine? As far as I can tell, this allows for an extensible category tree that can be freely manipulated by the client. The only challenge I can see is how to manage existing categories; renaming, deleting, etc., as well as moving entries from one category to another.
I've thought about tackling each of these like so:
- Moving entries from one category to another: PUT the entry with the new atom:category element in it, effectively removing the association with the old category.
- Deleting a category: Move all entries out of the category, effectively making the category void which can implicitly be translated to "deleted" by the server.
- Renaming a category: Say the old is called "hats" and should be renamed to "headwear", you would create the "headwear" category, then move all entries from "hats" to "headwear".
That seems to solve all obstacles I can see, but the question is: is this kosher per RFC 5023? I can see a problem in the rename/moving algorithm if a category contains a large amount of entries as you would need to PUT each individual entry, which could take a lot of time.