Subject: Entry types

From: James M Snell <[email-masked]>
Date: Mon, 01 May 2006 12:40:57 -0700

Looking at Google's gdata and IBM's open activities APP implementation
as examples, there appears to be a solid use case for defining a common
categorization scheme for associating a type label to an entry.

For instance, Gdata defines the following:
 <atom:category
   scheme="http://schemas.google.com/g/2005#kind"
   term="http://schemas.google.com/g/2005#contact"/>

Our stuff uses:
 <atom:category
   scheme="http://ibm.com/oa/type"
   term="task" />

I'm wondering if it would make sense to have a single common "type"
scheme that could be used consistently across implementations.

 <atom:category
   scheme="http://www.w3.org/2005/Atom/Entry-Kind"
   term="http://schemas.google.com/g/2005#contact"
   label="Contact" />

 <atom:category
   scheme="http://www.w3.org/2005/Atom/Entry-Kind"
   term="http://ibm.com/oa/type#task"
   label="Task" />

The category could be used on Feeds and Entries.

Thoughts?

- James

---

From: David Powell <[email-masked]>
Date: Tue, 2 May 2006 13:24:21 +0100

> 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

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Tue, 2 May 2006 13:48:31 +0100 (BST)

> d) "duck-typing", eg assuming that contact:firstName implies the type.

In order of preferences: c, a, b, d

> of category?,

Well RFC 4287 says for atom:category

"""This specification assigns no meaning to the content (if any) of this
element"""

Therefore I guess it would be fine from the spec point of view. However I
do agree with you that it would be overloading the general meaning we give
to a category.

I'm not sure, it probably depends on the circumstances.
> entry is about, it ought to be under control of the publisher.

Agreed.

> I suppose a quick vcard:* check is pretty easy with XPath.

Second that point too.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Tue, 02 May 2006 08:47:36 -0700

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.

> 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

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

> event details and contact details for the organiser? Will typical Atom

In our implementation no, but it generally, it's possible.

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

> 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