James M Snell wrote:
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
one possibility would be to simply have app:member-type inside
atom:entry i.e.:
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://purl.org/atom/app#>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<app:member-type>entry</app:member-type>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>Some text.</content>
...
</entry>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Atom-Powered Robots Run Amok</title>
<app:memeber-type>media</app:member-type>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<link rel="edit" href="" class="moz-txt-link-rfc2396E" href="http://example.org/edit/first-post.atom">"http://example.org/edit/first-post.atom" />
<link rel="enclosure"
href="" class="moz-txt-link-rfc2396E" href="http://example.org/media/img123.png">"http://example.org/media/img123.png" />
</entry>
<entry xmlns="http://www.w3.org/2005/Atom">
<title>Some event</title>
<app:memeber-type>http://example.org/events/1.0</app:memeber-type>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344eddddd</id>
<updated>2003-12-13T18:30:02Z</updated>
<author><name>John Doe</name></author>
<content>...</content>
</entry>
</feed>
this would make it all nicely orthogonal: collections types and entries
types where collection type can be interpreted as a filter on types of
entries inside ATOM store.
best,
alek
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
--
--- Memorable Quote from Firefly (105. Out Of Gas)
-Ship like this, be with you until you die -That's because it's a deathtrap
|
signature.asc
Description: OpenPGP digital signature
