> > Yes, though I believe Mark's "Web Linking<http://tools.ietf.org/html/draft-nottingham-http-link-header>" > draft does this already. It does (Section 6.2). > I started thinking about this earlier in the week with a view to having > e.g. a representation of a bookshelf referring to a > collection/feed/url-list/etc. of books using rel="collection". I then > started looking at parent/child/sibling relationships which are currently > being discussed in a separate thread (my preference is for something like > e.g. "rel=descendant level=2" for grandchildren as I subsequently realised > that suggested abbreviations "asc" for ascendant and "desc" for descendant > can be confused with item ordering). Do you think these "family" relations > serve all the use cases for a "collection" relation? > In AtomPub, a collection is defined as: > A Resource that contains a set of Member Resources. Collections are > represented as Atom Feeds. Collections are used to indicate where you can POST a new entry in a Service document, and what you can post is defined in app:accept: > The content of an "app:accept" element value is a media range as defined in > [RFC2616]. The media range specifies a type of representation that can be > POSTed to a Collection. In the current Web Linking draft, the edit relation is redefined (Refers to a resource that can be used to edit the link's context.) but we still lack a relation type for links where we can POST things (and we shouldn't use "collection" for this purpose). Since we can't use more than a single relation type for a link, it might be complex to define something that is both a "collection" and a resource where you can "post".
Received on Friday, 11 September 2009 13:58:11 UTC