There are a couple of different ways we could implement this.
One is through categories. We could specify context attributes
through the <category> element within <activity:object>. These would
have a scheme URI in the http://activitystrea.ms namespace. The term
could be something like "activity:mood." Benefits to this are that we
don't really have to invent anything new, this is part of the Atom
spec already. This would also give other sites the ability to put in
their own custom categories in their own namespace - not sure if
that's a benefit or not, but it would be there.
The other way would be to have a specific <activity:context> element
that has specified properties - <mood>, etc. This would be within the
<activity:object> element.
I think I prefer the category approach, however. Using the scheme
attribute in categories will allow us to do other things with
categories as well (I see machine tags have been popping up
occasionally on this list).
I can write this up if anybody wants to see what this would look like
integrated into the spec.
Michael Richardson wrote:
> It seems to me that there are valid reasons to provide context about
> the activity. The context would contain things that are more related
> to the user, or the environment in which the activity occurred, than
> the activity itself. Some examples of things that could go in here
> would be mood, location, and posting source (eg, Twitter's 'from SMS|
> web|whatever'). It nicely solves the problem of what to do with mood
> and other things that aren't really related to the activity object and
> more related to the user posting them.
>
I expected context-related information to appear just as top-level
elements in activity feeds.
For example, the location in which an activity occured could be encoded
by using GeoRSS elements as direct children of the atom:entry element.
I don't think we really need to bless any generic way of doing this;
each use-case can be addressed by finding an appropriate existing
specification or writing a new one orthogonal to activity streams.
(By the way, I consider using atom:category with a custom scheme to be
functionally equivalent to an element in a custom namespace when it
comes to simple, unstructured data. The practical difference is that
when atom:category is used legacy processors will tend to present the
"term" or "title" to users, whereas custom elements are generally
ignored. Therefore the decision about whether to use a custom XML
namespace or a custom category scheme is based on whether this is
something that should be displayed to users as tags.)