Through the use of a commonly defined category scheme. <atom:category scheme="http://www.w3.org/2005/Atom/Entry-Kind"; term="event" />
The value space for the scheme could be managed via an IANA registry, or, the term could itself be a URI. ...And yes, some would likely consider this to be tag abuse. On the other hand, we have two implementations that independently came up with the same solution to the same problem. - James Aleksander Slominski wrote: > James M Snell wrote: >> The atom:category element works just as well, and avoids the need to >> create new namespaced elements > however if i want to define my own entry type how an application know > that it is an entry type and not just new category/keyword/tag? > > for example assume i have: > > <atom:category > scheme="http://example.org/types"; term="event" /> > > does it define entry type or just a tag? it will be very hard to get > automatically determined ... >> (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... >> >> > or there is going to be a global namespace > (http://www.w3.org/2005/Atom/Entry-Kind) where "event" is defined? > > just like registry of MIME types? > > thanks, > > alek >> 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}