On May 11, 2009, at 10:17 AM, Peter Keane wrote:
Nikunj- Regarding the h:role extension (master|detail): seems to me the role is ulitimately a function of the collection itself and not the entries that might be posted. In other words, the collection itself should be noted as being a "metacollection." This came up in an atom-protocol thread previously [1]. There, the suggection was to use atom:category child of app:collection, which makes good sense to me. Is there ever a case when a single collection would accept both "master" and "detail" entries? If so, I could see the need for the attribute on app:accept.
Collections that don't specify any particular role on the accepted data are non-committal about the kind of entry that would be created upon POSTing. Any existing collection is likely to fall in this category. When the server of such a collection receives a POST request, it may or may not create a child feed. For example, the portfolios feed of GData finance creates a collection of positions as soon as a new portfolio is created. However, it doesn't advertise this fact in any well-known or self-describing manner. In order to make it known to a hierarchy-aware client that the server is unable to advertise such behavior, we would like to allow the case where app:accept doesn't advertise a value for h:role.
A use case for a single collection allowing either kinds of (master and detail) entries is when type A entry that groups multiple type B entries can be a sibling of some type B entries. For example, an order can be nested such that its contents can be smaller orders or individual items. The top-level order would only represent billing information and the catch-all shipping information. For every other sub-order, its own shipping information may be specified. When an entry is posted to the top-level order collection, it can be either a sub-order or an item.
I hope this clarifies the use case where a single collection may accept both master and detail entries.
--peter [1] http://www.imc.org/atom-protocol/mail-archive/msg11049.html