Bill de hOra wrote:
This is from the atomactivity-00 spec:
[[[
<entry>
<id>tag:photopanic.example.com,2008:activity01</id>
<title>Geraldine posted a Photo on PhotoPanic</title>
<published>2008-11-02T15:29:00Z</published>
<link rel="alternate" type="text/html"
href="/geraldine/activities/1" />
<activity:verb>
http://activitystrea.ms/schema/1.0/post
</activity:verb>
<activity:object>
<id>tag:photopanic.example.com,2008:photo01</id>
<title>My Cat</title>
<published>2008-11-02T15:29:00Z</published>
<link rel="alternate" type="text/html"
href="/geraldine/photos/1" />
<activity:object-type>
tag:atomactivity.example.com,2008:photo
</activity:object-type>
<source>
<title>Geraldine's Photos</title>
<link rel="self" type="application/atom+xml"
href="/geraldine/photofeed.xml" />
<link rel="alternate" type="text/html"
href="/geraldine/" />
</source>
</activity:object>
<content type="html">
<p>Geraldine posted a Photo on PhotoPanic</p>
<img src="/geraldine/photo1.jpg">
</content>
</entry>
]]]
I see the following duplication:
1: atom:id, activity:id
2: atom:title, activity:title
3: atom:published, activity:published
4: atom:l...@rel=alternate, activity:l...@rel=alternate
5: atom:souce, activity:source
1,2,4,5 I think are duplicates, 3 depends on what activity:published
means. But on reading through the spec, I see that "5.5. The
activity:object Extension Element" is saying to use atom:* elements. So
I think the example XML is buggy, and here's my attempt at a fix by
throwing in xmlns and xml:base declarations:
Note that the top-level entry here represents the activity or action,
while the content of activity:object (which is also an Atom Entry in all
but name) represents the object of the activity.
Therefore these are in fact not duplicates. The entry-level atom:title
is a human-readable description of the activity ("Geraldine posted ...")
while the activity:object atom:title is the title of what Geraldine
posted, which in this case is a photo with the title "My Cat".
It's clear to me this needs refactoring. As a strawman let me suggest:
[[[
<entry xmlns:atom="http://www.w3.org/2005/Atom";
xmlns:activity="http://activitystrea.ms/spec/1.0/";
xml:base="http://example.org/activities"; >
<id>tag:photopanic.example.com,2008:activity01</id>
<title>Geraldine posted a Photo on PhotoPanic</title>
<updated>2008-11-02T15:29:00Z</updated>
<link rel="alternate"
type="text/html"
href="/geraldine/activities/1" />
<link rel="alternate"
type="text/html"
href="/geraldine/photos/1" />
<content type="html">
<p>Geraldine posted a Photo on PhotoPanic</p>
<img src="/geraldine/photo1.jpg">
</content>
<activity:when>2008-11-02T15:29:00Z<activity:when>
<activity:type>
tag:atomactivity.example.com,2008:photo
</activity:type>
<activity:verb>
http://activitystrea.ms/schema/1.0/post
</activity:verb>
</entry>
]]]
This is very similar to the "implied activity" shorthand syntax
described later in the spec, which is in fact what we expect most
publishers to generate. The full-blown activity entries are intended to
be posted by publishers such as FriendFeed and Plaxo whose entries
represent actions rather than simply lists of objects.
You are correct that in this case there is ambiguity for a few elements:
* If the verb is something other than "post", atom:published becomes the
activity time rather than the published time. The definition of the
"post" verb means that for that verb the activity time and the
publication time are always the same, since it was not published until
it was posted.
* atom:author becomes the activity actor rather than the author of the
object. Again, in the "post" case these are the same, but for other
verbs they are not necessarily the same. Unfortunately existing practice
constrains the solution here; for example, YouTube's "favorite" feeds
have atom:author set to the user that owns the feed, not the user who
authored the video. Therefore the spec currently says that the author
belongs to the activity, not to the object.
I think I've addressed many of your points above, so I'll just respond
to those I haven't yet:
- I suspect activity:type could be a machine tag and therefor using
atom:category with a scheme could be an option. This would allow a
useful extension point.
I did actually already get feedback in favor of machine tags, but they
made me wary for two reasons:
* They are not yet widely known or adopted, as far as I can tell.
* (and this point relates to the use of atom:category in general) many
existing aggregators display to the user all categories regardless of
scheme, and a design goal of this specification is for the new
annotations to cause no visible difference in legacy software, so that
there will be less resistance to adoption.
- If this was an IETF standards track, I would suggest an IANA registry
for activity:verbs.
Do you intend the IANA registry to replace the use of URIs as the
extension mechanism with simple keywords?
This is certainly something that could be considered.
I think the of an activity entry format outside any one silo has legs
and is a good idea, but I expect some objections and a need for hard
graft to get it done. In no way do I think this is slam dunk as Sam
suggests in his weblog [1]. Some reasons why:
- How this aligns with the OpenSocial activity format needs to be
squared up (and technically as well as you can get more bang for the
byte with that format)
http://code.google.com/intl/fr/apis/opensocial/docs/0.7/reference/opensocial.Activity.html
In discussions with OpenSocial folks we got the impression that they
would consider using an Atom-based format for activities. I used their
schema as one of my research sources for this specification.
Right now the main "inspiration" for this spec are the syndication-based
activity aggregators such as FriendFeed, Plaxo, Movable Type Action
Streams, etc, but I agree that it is important to align with OpenSocial too.
- There is repetition of data - practically speaking there are a lot
more activity events than blog posts, I'd guess easily one order of
magnitude, probably two. Having a uniform means of serving them will
result in more events, maybe getting us to three orders. I imagine we'll
see claims the web will collapse under the weight.
The "implied activity" shorthand is intended to address this. In the
weblog case, one needs only to add a single element to each entry to
mark it up as a weblog entry:
<object-type xmlns="http://activitystrea.ms/spec/1.0/";>
http://activitystrea.ms/schema/1.0/blog-entry/
</object-type>
though of course in practice many activity consumers are likely to
present an un-annotated entry much like a weblog entry because that's
what they do today.
The work for things such as photos and videos is slightly more since
some providers would need to add thumbnail links and so forth, but it
was a very strong requirement that existing feeds would require only
minimal changes -- and, in most cases, only additions -- to hit the
important use-cases for this spec.
- Having duplicate places to put data will easily confuse publishers, as
will clients be confused by data acquisition from parent elements. This
is just how things are with XML modelling.
The most important feedback I've taken from this is that the spec should
be re-organised to emphasise the implied activity shorthand rather than
starting with the full "activity entry" case, since I expect only
activity aggregator services to publish the latter, and indeed the
motivation for this separation is that these publishers already have
feeds that represent activities rather than objects.
Thanks for the very detailed feedback. Six Apart is hosting a meet-up
regarding activity streams publishing this afternoon[1] where we can
take a look at the feedback we've recieved.
Cheers,
Martin
[1] http://upcoming.yahoo.com/event/1470821/
(Folks are welcome to come, though I realise this is late notice for
those who are only just finding out about it now.)
