Comments on each doc 1.) http://martin.atkins.me.uk/specs/atommedia - This spec describes a bunch of elements but not how they are supposed to be used. I'm especially confused about atom:link with rel="preview". What is it a preview of? The example in the spec has a single preview (pic) and two enclosures (also pictures). How is that expected to be treated? I'd expect there to be a 1:1 mapping between enclosures and previews but there doesn't seem to be any such rule in the spec.
2.) http://martin.atkins.me.uk/specs/activitystreams/atomactivity - Verbs seem to be poorly defined and unnecessary. It seems they are either a way to categorize items in a feed (i.e. use atom:category) or a way to point to an end point where an action can be taken (i.e. use rel="verbname" the same way AtomPub has rel="edit". - The list of base object types is missing update types that are common on social networking sites such as relationships ('Dare is a friend of Rob', 'Dare is a fan of Metallica'), profile changes ('Dare is now married', 'Dare has updated his occupation to cubicle dweller') and even reviews ('Dare rates the Zombies application ** out of *****) 3.) http://martin.atkins.me.uk/specs/activitystreams/atomactivity - As I mentioned above, I can't see why an extension element is needed for activity:verb instead of atom:category or l...@rel="post|markfavorite" - activity:object just seems super weird. It is effectively an atom:entry embedded inside the atom:entry. This seems like a significant amount of duplication of data and a recipe for lots of confusion by feed consumers and producers. Almost every element that is a child of the activity:object seems redundant to the same elements that are children of the parent atom:entry. There needs to be more explanation of this design so it can be properly understood. I can imagine some simple scenarios where the activity:object may seem to help but it breaks down really quickly - activity:object-type should either be an attribute/element of activity:object or even better a machine readable atom:category. These are just quick impressions based on my experiences in this space. I'll try to go over the specs in more detail later. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #139 If I'm sitting in my camp, hear a twig snap, start to investigate, then encounter a small woodland creature, I will send out some scouts anyway just to be on the safe side. (If they disappear into the foliage, I will not send out another patrol; I will break out the napalm.) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Martin Atkins Sent: Thursday, January 01, 2009 4:38 PM To: Atom Syntax Subject: Some Draft Atom-related Specs for Activity Streams 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
