Hey David, Just some responses to your random thoughts. My goal is not to argue that the category approach is best, but only to state the rationale behind what we've done to this point.
David Powell wrote: > Monday, May 1, 2006, 8:40:57 PM, James Snell wrote: > >> I'm wondering if it would make sense to have a single common "type" >> scheme that could be used consistently across implementations. > > <random thoughts> > > "Type" seems a bit vague, this seems to be mainly about describing how > an entry should be processed. A few possible ways to do that: > > a) Using categories and a known categorisation scheme > b) Using an ex:processAs extension > c) Using domain specific extensions, eg <contact:VCard /> > d) "duck-typing", eg assuming that contact:firstName implies the type. > There are two reasons our implementation uses category to represent the kind of entry. 1. To specify how the entry should be processed (e.g. our UI shows comment entries differently than file entries) 2. To allow existing feed readers that understand the category element to present that information to users. For instance, when I load one of our feeds in Liferea, I can see right away that an entry is a Task or a Comment, or a File, etc, even tho Liferea knows absolutely nothing about our particular application. Looking at Sylvain's order of preference, I would switch c and a: In order of preferences: a, c, b, d > I think that using category might be an overloading of the semantics > of category?, I'm not sure, it probably depends on the circumstances. > Category is really a summary of the set of real-world concepts the > entry is about, it ought to be under control of the publisher. Typical > Atom consumers will probably provide a UI to filter entries by > category. Do consumers want the set of categories for an entry > polluted with physical properties of the entry? This might be ok > sometimes, but not in general. > With the category approach, I can group entries by Task, by File, by Event, etc. Note also that we're making judicious use of the category scheme to differentiate the various types of categories. For instance, we have a type scheme, we have a visibility scheme (e.g. private, public), we have a status scheme (e.g. completed, not-completed), we have a tag scheme, etc. None of the feed readers we've tested actually make good use of the scheme attribute. In fact, at least one attempts to use it as a dereferenceable URI. Hopefully, that situation improves. > Can entries have multiple types? Like an entry that includes both the > event details and contact details for the organiser? Will typical Atom In our implementation no, but it generally, it's possible. > infrastructures be able to dispatch entries to multiple processors, or > will it be like MIME-types, where this is difficult (as in the > dispatching of generic XML types based on namespace, or of RDF)? > I certainly hope not. In our case, the entry typing is used to allow us to present intelligent UI options to the user based on what kind of thing the entry is. > Microsoft has a screen saver sample [1] that uses Windows Feed > Platform to display picture feeds. It does this without any typing, > just by examining each entry in the feeds associated with the screen > saver, and selecting the appropriate ones. > > [1] http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx > > I remember seeing a demo of a calendar feed that synced with Outlook, > I suspect that that also relied on having the plugin decide which > entries it was interested in, rather than the engine dispatch entries > to specific plugins. Engine driven dispatching might be slightly more > performant, but plugin driven dispatching is more flexible and doesn't > need a well-known type extension to key off. > > Is it enough to go for the "duck-typing" approach, and not require > explicit typing? But, what if all of the extensions for contacts are > optional? What if some are shared with the extensions for > appointments? If the rules for deciding on the type of an entry aren't > specified, it might be more prone to interop problems, where one > implementation detects an entry as a contact, and another doesn't. I > suppose a quick vcard:* check is pretty easy with XPath. > > I believe there is room for both. For example, I certainly do not need a type=podcast category to determine whether or not an entry contains a podcast. However, the category-based typing does prove useful when differentiating different kinds of entries that otherwise have similar or even identical structures. For example, <!-- a comment --> <entry> <id>tag:example.org,2006:1</id> <title>A Comment</title> <link href="http://example.org/foo"; /> <updated>2006-05-02T12:12:12Z</updated> <author><name>James</name></author> <content>This is a comment</content> <category scheme="urn:entry:type" term="comment" label="Comment"/> </entry> <!-- a link --> <entry> <id>tag:example.org,2006:2</id> <title>A link to some other page</title> <link href="http://example.com/bar"; /> <updated>2006-05-02T12:12:12Z</updated> <author><name>James</name></author> <content>This is a link to some other page</content> <category scheme="urn:entry:type" term="link" label="Link"/> </entry> - James
