[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Version Notification for draft-divilly-atompub-hierarchy-00
On May 11, 2009, at 10:17 AM, Peter Keane wrote:
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 . 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.