Hi Martin,
Interesting stuff. Are you actually submitting these as Internet-
Drafts? (please do, if not already...).
Cheers,
On 01/01/2009, at 7:37 PM, Martin Atkins wrote:
Hi folks,
A small group of which I'm a member has been working on a
specification for describing activities as Atom entries. An
"activity" for our purposes is an action a user has taken on a
social website, such as posting a photo or marking it as a favorite.
The draft we have so far is here:
http://martin.atkins.me.uk/specs/activitystreams/atomactivity
In the process of working this through, we discovered a number of
other problems that we believe require Atom extensions to solve, so
we've also got drafts of a number of peripheral specifications.
As Sam Ruby posted earlier in the month[1], one issue encountered
was the lack of a standard way to publish media items such as photos
and videos in Atom. While a couple of publishers (notably Google
properties) use the elements from MediaRSS for this purpose, the few
implementations I found were inconsistent. It was suggested that a
more Atom-shaped media specification might be useful, so we drafted
up this:
http://martin.atkins.me.uk/specs/atommedia
We also have a small specification for describing the "service
provider" that hosts a feed (for example, YouTube or Twitter). This
is intended to be similar in design to atom:author.
http://martin.atkins.me.uk/specs/activitystreams/provider
Finally, we have a small extension to Atom Threading Extensions to
allow some metadata about the parent entry to be included in the
child so that consumers can avoid fetching source feeds in certain
cases. This is intended to be similar in principle to atom:source
http://martin.atkins.me.uk/specs/activitystreams/commentmeta
I'm well aware that these drafts need plenty more editorial work,
and may need more detail in certain spots, but since some folks are
ready to start implementing based on these drafts I wanted to throw
them out here to get a few more eyes on them, so that if there are
any major problems with the technical direction we're taking we
might fix them before there are too many implementations to change.
I would appreciate it if folks here would cast a critical eye over
what we're proposing and let me know if you see fundamental flaws in
our approach to any of these problems.
We will of course continue to refine these documents and hopefully
we would be able to bring some or all of them over here and work on
them with the wider Atom community.
Thanks,
Martin
-----------------------------------------
[1]http://www.imc.org/atom-syntax/mail-archive/msg20818.html
--
Mark Nottingham http://www.mnot.net/
