The atom:category element works just as well, and avoids the need to create new namespaced elements (which increases the chance that existing clients will be able to do something interesting with it)
<atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="event" /> <atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="task" /> <atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="message" /> <atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="contact" /> <atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="link" /> etc... - James Aleksander Slominski wrote: > 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="http://example.org/edit/first-post.atom"; /> > <link rel="enclosure" > href="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 >
![http://example.org/media/img123.png"](http://example.org/media/img123.png"){kind=link}