James Holderness wrote:
Martin Atkins:
I'm also not sure if this sort of thing matters. For what it's worth,
I did also consider using atom:name, the child of atom:author for this
purpose, since we're really talking about the name of the provider
rather than its title.
If I had to choose, I'd say atom:name was more appropriate. Your usage
seems pretty close to the RFC4287 definition.
However, I could rewrite it to use custom elements if folks think
extending the reach of these Atom elements is wrong.
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:
[[[
<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>
<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>
<activity:object-type>
tag:atomactivity.example.com,2008:photo
</activity:object-type>
<id>tag:photopanic.example.com,2008:photo01</atom:id>
<title>My Cat</atom:title>
<published>2008-11-02T15:29:00Z</atom:published>
<link rel="alternate"
type="text/html"
href="/geraldine/photos/1" />
<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>
]]]
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>
]]]
- I don't think you need an activity-object if you use atom:entry, but
I suspect it would be the top level element in a dedicated format)
- I think you need activity:when to keep event times distinct from
publishing/update times, so I added it.
- 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.
- If this was an IETF standards track, I would suggest an IANA
registry for activity:verbs.
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
- 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.
- 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.
- As a simple specification example, MUST requirements for foreign
markup extensions as this draft needs are a problem (this is why AtomPub
cannot mandate the "app:edited" element).
What I would do next:
1 write down the anatomy of a well formed activity entry[2], and get
buyin on that.
2 re-examine commonality of its elements with Atom
3 make a decision to re-use Atom format elements or embed an activity
inside it. An example of the former approach is GData, an example of the
latter is OpenSocial.
The latter is very important and is about technical and social tradeoffs
- ime reusing Atom as a base in this way tends to make more sense as you
have more and more formats and they start to look less and less like
precious snowflakes and more like snow. By analogy, microformats all
base off XHTML, but RDFa chooses to embed within XHTML [3].
Bill
[1]
http://intertwingly.net/blog/2009/01/08/Atom-Media-Extensions-for-Activity-Streams
[2] imvho: involves describing where, what, when, who, why
[3] as a datapoint, the Atom WG did not reuse Dublin Core's elements, we
chose to mint our own, mainly because they could not be redefined
outside the spec (Atom's stability around versioning requires this).
