Specs being reviewed by the Atom-syntax group at IETF
Martin Atkins
I also forgot to mention that I posted about the various Atom extensions
on the atom-syntax mailing list at IETF to get some feedback from the
Atom community about the technical direction and whether there are any
fundamental problems in these specs.
The thread is here:
http://www.imc.org/atom-syntax/mail-archive/msg20825.html
I got some encouragement from Mark Nottingham to post some or all of the
specs as IETF Internet-Drafts, which probably wouldn't be a bad idea
once they're a bit more complete if only to get a few more eyes on them.
Dare Obasanjo
that list
~~
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 link@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.
Martin Atkins
I think in the interests of addressing the right audience I'm going to
respond to your activity-related feedback here and your media-related
feedback over at atom-syntax...
Dare Obasanjo wrote:
>
> 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".
atom:category was considered but decided against because existing
software treats atom:category as user-visible tags.
Since this metadata is for machines only, we do not want it to affect
how existing non-activity aggregators process entries today.
atom:link is also inappropriate because the verb is not intended to be
retrieved. It acts as an identifier only.
I will try to make this clearer in a future version.
> - 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
> *****)
This was raised at the meetup and is in the process of being addressed
now, with MySpace serving as the primary example for the moment.
With that said, we did not currently have profile changes on the list so
I've made a note to consider that.
> 3.) http://martin.atkins.me.uk/specs/activitystreams/atomactivity
> - 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
I have on my list that I need to clarify the use of "Activity Entries"
(which is where atom:object comes in). This design is intended to be an
extension of the feeds that are being generated today by FriendFeed and
Plaxo, and in future by MySpace, where each entry represents an activity
rather than an object.
In this case, the top-level entry title is something like "Martin posted
'AtomActivity Draft' in his weblog", so software cannot readily extract
the title of the entry itself ("AtomActivity Draft").
The intentin is that FriendFeed and Plaxo would add an activity:object
element containing whatever metadata they are able and willing to expose.
Normal content publishers such as YouTube and Flickr would not be
expected to use this form, and can instead use the implied activity
shorthand as described in the spec.
I would be grateful if you could let me know if the above explanation
makes things clearer, since something like this should ultimately end up
in the spec.
> - activity:object-type should either be an attribute/element of
> activity:object or even better a machine readable atom:category.
>
activity:object-type *is* a child of activity:object, but it can be used
at the top-level when the entry represents an object rather than an
activity.
Dare Obasanjo
On Jan 11, 12:37 pm, Martin Atkins <m...@degeneration.co.uk> wrote:
>
> > 3.)http://martin.atkins.me.uk/specs/activitystreams/atomactivity
activity:subject to identify who is taking the action. For situations
such as
- more than one person owns the activity feed (e.g. blogs with
multiple authors, activity streams for groups of users)
- using AtomActivity as the representation of a feed of my friends'
activities (e.g. exposing my FriendFeed or Windows Live news feed in
Atom so I can consume it in Google Reader)
Both of these are scenarios we have already shipped in Windows Live.
I should also explicitly state that I expect that this model may end
up having unintended complexities due to verb proliferation. Just in
Windows Live, I already see lots of verbs we need to describe our
existing implementation that don't come out of the box with your
current spec drafts (e.g. Dare is planning a trip to London on TripIt,
Dare reviewed Rain NightClub on Yelp and gave it **** out of *****,
etc). I expect to see a lot more such specialized activity types as we
add new partners.
With this model, it seems partners that want to consume our activity
feeds will have to touch their code every time we add a new partner
service that they haven't specifically written code to handle AND they
need an RFC-style spec from us.
> > - activity:object-type should either be an attribute/element of
> > activity:object or even better a machine readable atom:category.
>
> activity:object-type *is* a child of activity:object, but it can be used
> at the top-level when the entry represents an object rather than an
> activity.
twice the opportunity to make mistakes. I've seen this practice with
MediaRSS and the main problem I see is that apps that process feeds by
example instead of reading the spec (i.e. the majority of app
developers) will be tripped up by this after they ship.