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 >> >> > > > -- --- 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}