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. 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. Can entries have multiple types? Like an entry that includes both the event details and contact details for the organiser? Will typical Atom 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)? 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. -- Dave
