This has been considered, discussed, argued, rehashed, argued some more
and then ignored.
Looking at existing implementations (e.g. the Google Data API, IBM's
Open Activities impl, etc) it is likely going to be far more common to
differentiate different types of entries than it is to differentiate on
the type of collections.
An APP server can either define a type of collection ("This collection
can only contain entries of type Foo") or can specify a list of entry
types a collection may contain. The difference is subtle but important.
For instance, the GData collection associated with Google Calendar is
current a collection of event entries. In theory, it could also contain
"task" entries, "meeting" entries, "reminder" entries etc. In IBM's
Open Activities (e.g. the product our interop endpoint is based on), a
collection can contain tasks, comments, files, links, etc. Also
consider weblog implementations that produce podcasting feeds. Some
implementations support mixing podcast entries with non-podcast entries.
The common thread of each of these is that the focus is on different
types of entries, not different types of feeds/collections.
What I personally would like to see at this point is some extension that
allowed an entry to declare what kind of entry it is [1]. Ideally, that
same extension would define a means of expressing the kinds of entries
that may be posted to an APP collection.
[1] http://www.snellspace.com/wp/?p=306
Aleksander Slominski wrote:
> hi,
>
> i wondered if anybody considered a need to have different types of
> collections?
>
> at minimum i think it would be useful to allow at least URIs as a
> appTypeValue i.e. modify section 7.2.4 from
>
> appTypeValue = "entry" | "media"
>
> to
>
> appTypeValue = "entry" | "media" | atomUri
>
> or maybe even better to
>
> rel = atomNCName | atomUri
>
> to allow in future to extend list of standard media types
>
> this is similar to how atom:[EMAIL PROTECTED] works (4.2.7.2 The "rel"
> Attribute
> in RFC 4287)
>
> thanks,
>
> alek
>
