Hi Al- [apologies if threading on this discussion is messed up -- I seem to have it in 3 thread]
I'd contend that atom:category is exactly the right mechanism for the functionality you've listed (I'll explain below). The same and/or related issues have come up again and again in regards to Atom, and I'd suggest that there is a real need for a few "practices" (I've learned not to prefix that w/ "best" :)) that might facilite these uses. First, atom:category can serve as a typing mechanism for atom entires & documents. That typing can take many forms, and the atom:categ...@scheme give you a namespace within which to create types. This from RFC 5023, 8.3.6: "The server MAY reject attempts to create or store members whose categories are not present in its categories list." I take to mean that categories can offer another means (aside from app:accept) to restrict the type of documents that can be added to a collection. Second, standard querying mechanisms are a must (we don't yet have one [1]) but they are essential to provide links to virtual feeds. I see no reason why the category querying mechanism in GData [2] wouldn't work just fine. On Tue, Jun 2, 2009 at 4:32 PM, Al Brown <[email protected]> wrote: >>"...Atom categories are analogous to folders in CMIS. >>It would make more sense to replace most of the CMIS extensions >>by using the Atom category mechanism to hold its filing relations. >>....Roy" [http://www.imc.org/atom-protocol/mail-archive/msg11379.html] > Categories are not a good fit for CMIS folders, or another way, a lot will > have to be added to categories for CMIS to use them to represent as folders. > CMIS requires the following functionality for folders: > 1. Typed: Folders have metadata Yes, folders should be represented by atom:entries. Use atom:category w/ @term=folder and a scheme that identifies the filetypes namespace i.e., @scheme="http://.../cmis.org/category/filetypes in addition, every atom entry for a file (directory OR regular file) has an atom:category that describes its virtual "place" in the hierarchy. Per your message re cardinality, this category is optional (ie., NOT in a directory) and can have one or more instances (covering 1...n). e.g.: <entry> <atom:category scheme="http://cmis.org/category/filepath"; term="/home/keane/docs"/> <atom:category scheme="http://cmis.org/category/filepath"; term="/public/docs"/> </entry> > 2. Constrained: Folders can constrain membership to certain CMIS types and > also have run-time restrictions Every entry of that is a "folder" type also has an atom:l...@rel=service, the href of which points to the service doc defining the atompub collection for this folder. I.e., to add a file to this folder, post an atom:entry to the collection defined in that service doc. Posted entires will either be required to have or will be assign a category indicating that they are in this directory. Moving files around (or creating these "symlinks" to other location is a matter of GET/EDIT/PUT of the atom:entry representing the file or directory (and adding/deleting atom:categories) > 3. Must be able to retrieve a portion of the folder tree (only things this > folder contains including other folders, to n-levels, or complete) and > include a) only folders, b) folders and objects, c) only objects This needs to be based on a query syntax. I could see a query of search?categor...@scheme=filetype]/home/pkeane/** getting me all docs recursively, or search?categor...@scheme=filetype]/home/pkeane/* getting me one level deep, etc. (obviously, a well-defined query syntax would need to be worked out. > 4. Easy to add/remove resources (documents) from a folder Since every folder is represented by an atom:entry that is "backed" by a collection, collecton semantics apply. (find the atom:entry representing the file and http DELETE the edit url. > 5. Clients must be able to create folders of a type with metadata Use atom:category for typing. collections can define the categories possible. > 6. Performance - systems can have 10's of millions of folders; it is > important that clients only work with portions of the folder tree that are > relevant. Again, an appropriately sophisticated query syntax should allow this w/o too much trouble. > 7. Query - folders and what they contain must be able to be exposed via > search Query again... > 8. Also allow vendors that support categorization to expose that > functionality. > Atom:category is extensible using @scheme "namespaces" [1] http://dret.typepad.com/dretblog/2009/04/feeds-as-query-result-serializations.html [2] http://code.google.com/apis/gdata/docs/2.0/reference.html#QueryRequests --peter keane > All of these capabilities are common across ECM systems. CMIS is a > specification that is leveraging Atom to expose these capabilities. Based on > these requirements, categories would have to be extended significantly and > IMHO not as a good a fit as atom:entry. > > I'd be happy to buy Roy coffee and walk him through CMIS and it's use of > Atom, APP and HTTP if he's got the time. > > -Al > > Al Brown > Emerging Standards and Industry Frameworks > CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home > Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home [..snipped...]
