Idea: <activity:object-type> for avatar / profile picture

[Rob Dolin]

Hey all,

 

I’ve been thinking about how to represent the action when a user posts a new profile picture.  (This is one of the top 10 activities in Windows Live and I’m guessing possibly in other services.) 

 

After thinking through a bunch of alternatives (noted below), I want to suggest that we add an additional <activity:object-type> for “avatar” which would inherit from the “photo” <activity:object-type>.  I don’t have a strong preference on naming, but I noticed that both the “Person” and “Group” base object-types have references to an avatar so I thought his would be consistent. 

 

Some additional thoughts on this:

* Inheriting from Photo (like Blog-entry inherits from Article) is a simple, straightforward solution and existing implementers would only need to add a single additional <activity:object-type> element to their XML

* This could use the “Post” <activity:verb> as many existing systems ask users to upload an avatar or profile photo.

* If we added a “Update” <activity:verb> in the future, activity stream emitting systems could potentially differentiate a newly posted avatar from a user changing their avatar.

 

What do others think?  Thanks much—

--Rob

[Chris Messina]

On Tue, Sep 29, 2009 at 10:32 PM, Rob Dolin <robd...@microsoft.com> wrote:

Hey all,

I’ve been thinking about how to represent the action when a user posts a new profile picture.  (This is one of the top 10 activities in Windows Live and I’m guessing possibly in other services.) 

Indeed, I think this is a valid use case. Documenting it on the wiki — along with Facebook's "many of your friends have changed their profile photos" would be good practice.

 After thinking through a bunch of alternatives (noted below), I want to suggest that we add an additional <activity:object-type> for “avatar” which would inherit from the “photo” <activity:object-type>.  I don’t have a strong preference on naming, but I noticed that both the “Person” and “Group” base object-types have references to an avatar so I thought his would be consistent. 

Since we're discussing naming, I think I'd prefer "user-photo" or "profile-photo" since "avatar" has connotations in the Second Life community (and other 3D avatar communities).

 

 Some additional thoughts on this:

* Inheriting from Photo (like Blog-entry inherits from Article) is a simple, straightforward solution and existing implementers would only need to add a single additional <activity:object-type> element to their XML

Agreed.

 

* This could use the “Post” <activity:verb> as many existing systems ask users to upload an avatar or profile photo.

Yes.

 

* If we added a “Update” <activity:verb> in the future, activity stream emitting systems could potentially differentiate a newly posted avatar from a user changing their avatar.

I think this is covered by ATOM's built in mechanism for specifying a "last updated" date — but Mart would know better than me.

 

 What do others think?  Thanks much—

All in all, big +1. ;)

I wonder if this could possibly help "push" out profile photos to systems that rely on external user photos (I'm thinking mostly of Twitter) — so that when a user changes their profile photo. the app knows to update the cache?

 

--Rob

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

[Chris Chabot]

On Wed, Sep 30, 2009 at 6:16 AM, Chris Messina <chris....@gmail.com> wrote: 

 After thinking through a bunch of alternatives (noted below), I want to suggest that we add an additional <activity:object-type> for “avatar” which would inherit from the “photo” <activity:object-type>.  I don’t have a strong preference on naming, but I noticed that both the “Person” and “Group” base object-types have references to an avatar so I thought his would be consistent. 

Since we're discussing naming, I think I'd prefer "user-photo" or "profile-photo" since "avatar" has connotations in the Second Life community (and other 3D avatar communities).

 

The word avatar has been popularized by the book Snow Crash (http://en.wikipedia.org/wiki/Snow_Crash) though he wasn't the first to use it as such, and it originates from sanskrit (http://en.wikipedia.org/wiki/Avatar), either way it's a bit more widely used then just Second Life :)

That being said, it's indeed used to describe a 'virtual self' (a 3D representation in a chat env, second life, wow, etc) and not so much for a regular plain old picture, in OpenSocial we went for 'Profile' to describe the person entry so profile photo would be a conveniently compatible terminology from that perspective

[Chris Chabot]

ps, what I forgot to add (as does tend to happen before morning coffee) is that one of the reasons we tried to go for neutral names in OpenSocial (displayName, profileUrl, etc) is because a entity in the system doesn't have to be a person, it could also be a website (for example in Google Friend Connect the owner == the website), a contact in a CRM system, or any kind of social object, and it feels a bit funny to have a 'user photo' for a website :) 

[Rob Dolin]

Thanks for the great feedback Chris and Chris.

 

It sounds like there’s good reason for profile-photo.  I’ll write this up as a wiki page for http://wiki.ActivityStrea.ms/.

 

Thanks again—

--Rob

[Chris Messina]

To close the loop, Rob's page is here:

https://wiki.activitystrea.ms/Profile-photo

On Oct 12, 1:42 pm, Rob Dolin <robdo...@microsoft.com> wrote:
> Thanks for the great feedback Chris and Chris.
>

> It sounds like there’s good reason for profile-photo.  I’ll write this up as a wiki page forhttp://wiki.ActivityStrea.ms/.

>
> Thanks again—
> --Rob
>
> From: activity...@googlegroups.com [mailto:activity...@googlegroups.com] On Behalf Of Chris Chabot
> Sent: Tuesday, September 29, 2009 11:05 PM
> To: activity...@googlegroups.com
> Subject: Re: Idea: <activity:object-type> for avatar / profile picture
>

> On Wed, Sep 30, 2009 at 8:09 AM, Chris Chabot <chab...@google.com<mailto:chab...@google.com>> wrote:

[John Panzer]

Would <link rel="preview" type="image/jpeg" href="{URL_to_photo}" /> also be the appropriate construct to use within an <author> element if one wishes to convey the profile photo to use for the author for that particular activity?

Or, as suggested earlier, a PoCo extension?

Or...?  There seem to be no shortage of reasonable solutions, just no absolute winner for this use case.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Chris Messina]

I find the 'rel-preview' not entirely what we're looking for here... it seems like rel-logo or rel-profilephoto might be better (the latter attempting to be a more accurate use of the "photo" attribute from PoCo/vcard). 

Thus for activities created by services or companies, we might see this:

<link rel="logo" type="image/jpeg" href="{URL_to_photo}" />

...created by people, this:

<link rel="profilephoto" type="image/jpeg" href="{URL_to_photo}" />

If that's too confusing or complicated, then perhaps we might just use "profilephoto" or a combination of old and new:

<link rel="preview profilephoto" type="image/jpeg" href="{URL_to_photo}" />

Is that kosher?

[John Panzer]

I'd be very happy with a convention for rel=$profile_photo_relname and an href that points at the photo.  Is that sufficient?  Would it be good to have some guidelines about what the aspect ratio/source resolution should be, for best results?

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Kevin Marks]

class="photo" is already in hCard (via vcard) for this;

http://microformats.org/wiki/hcard#Notes_on_derivation_from_vCard

OpenSocial has thumbnailUrl:

http://wiki.opensocial.org/index.php?title=Opensocial.Person_%28v0.8%29#opensocial.Person.Field.THUMBNAIL_URL


HTML5 has rel="icon"

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#rel-icon

as does Atom:

http://atompub.org/rfc4287.html#element.icon

along with "logo"

http://atompub.org/rfc4287.html#element.logo

for an image representing the feed.

I'd say to keep the rel="photo", and add another more specific rel if
you must, but rel="profilephoto" seems odd to me.

rel="photo icon" seems to fit precedents here.

[John Panzer]

I am irresistibly attracted to "photo icon".

--

[Bob Aman]

> I'd be very happy with a convention for rel=$profile_photo_relname and an
> href that points at the photo.  Is that sufficient?  Would it be good to
> have some guidelines about what the aspect ratio/source resolution should
> be, for best results?

My strong preference would be for 1:1 ratio, but it's one of those
things where no matter what gets recommended, we'll still end up with
images of other aspect ratios on a regular basis.

-Bob Aman

[Richard Cunningham]

+1 for a 1:1 version

In particular a 50px x 50px version would be useful as many sites
already produce those.

[Bob Aman]

> +1 for a 1:1 version
>
> In particular a 50px x 50px version would be useful as many sites
> already produce those.

If recommending a 1:1 aspect ratio would be an exercise in futility, a
specific size would be even more unlikely to be followed.

-Bob Aman

[Martin Atkins]

John Panzer wrote:
> I am irresistibly attracted to "photo icon".
>

Note that unlike in HTML, Atom doesn't allow multiple relationships on a
single link. Assuming what you're trying to say here is rel="photo" and
rel="icon", you'd need to write out two link elements to express that.

[Bob Aman]

Quite true. I had forgotten about that:
http://atompub.org/rfc4287.html#rel_attribute

Also,
http://www.iana.org/assignments/link-relations/link-relations.xhtml

-Bob Aman

[Chris Messina]

That's annoying.

I suppose that the best approach here would be to use rel-photo within the <author> element, or within the <activity:actor> element. That way we don't need to worry about getting prematurely specific. It also allows for larger sized images, which will be increasingly important as we move to larger and higher DPI displays...

I wrote about this problem in 2007, calling for the standard avatar/profile photo size to be 512x512:

http://factoryjoe.com/blog/2007/04/21/raising-the-standard-for-avatars/

As for the different sizes/dimensions... hard to say. I think that we should support various dimensions starting with 1:1 and 4:3 proportions (at any pixel width/height). But for the most part, I think the client can do the work to resize/position profile photos as fits their use cases.

Also, in terms of who supports which dimensions, I ALSO already did this research:

http://spreadsheets.google.com/pub?key=pSGbbhtwI4kO707_PHKNaGw&output=html

50x50 is far from the standard — in fact, there is NO standard.

So... the best thing to do is just make it possible to point to a photo for an author and see how people adopt it.

But, let's please get this into the spec.

Chris

[Kevin Marks]

Atom specifies 1:1 for icon (it also specifies 2:1 for logo, ie wider than tall) - both SHOULD

I'd forgotten it doesn't allow multiple rel values on a link; annoying.

See also:

http://wiki.whatwg.org/wiki/RelExtensions

which is a reasonable place to add any new ones.

[John Panzer]

• +1 on getting consensus captured (& into spec)
• Most important is just an agreed upon rel name.
• Next (nice if) is a SHOULD on aspect ratio, just as a guideline -- 1:1 or anything close would work well, you can always center.
• Not that worried about resolution, hopefully people will provide reasonably high source resolution to allow for down-rezzing as needed.

[Rob Dolin]

Hey all,

 

As there seems to be consensus, I have added a sentence to the wiki page (http://wiki.activitystrea.ms/Profile-photo) indicating a preference (but not requirement) for a 1:1 aspect ratio.

 

It would be nice (should) but is not a requirement that the photo have a 1:1 aspect ratio. 

 

 

I have kept the sentence recommending using <link rel=”preview” as this is consistent with the spec’s Photo section: http://martin.atkins.me.uk/specs/activitystreams/activityschema#photo

 

The URL and metadata for a thumbnail version of the photo. The URL is represented as the value of the href attribute on an atom:link element with rel preview and a type of either image/jpeg, image/png or image/gif. Publishers SHOULD include media:width and media:height attributes on the atom:link element describing the dimensions of the linked image. Processors MAY ignore thumbnails that are of an inappropriate size for their user interface.

 

Use of rel=”preview” for a thumbnail image is also consistent within the spec for video. 

 

 

FWIW—

--Rob

 

From: activity...@googlegroups.com [mailto:activity...@googlegroups.com] On Behalf Of John Panzer
Sent: Friday, October 30, 2009 1:06 PM
To: activity...@googlegroups.com
Subject: Re: Idea: <activity:object-type> for avatar / profile picture

 

• +1 on getting consensus captured (& into spec)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com
To unsubscribe from this group, send email to activity-strea...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en
-~----------~----~----~----~------~----~------~--~---

[Chris Messina]

I'm -1 for rel-preview. 

rel-preview, in my thinking, should correspond to a *preview* image of a larger image or a stillframe/poster image for a video. 

We are specifically not talking about a "preview" of a person but instead a photo of a person. 

I appreciate Rob's line of thinking and desire to maintain consistency, but I think that rel-photo for an author makes more sense, since the semantics should read:

"this is a photographic representation of the author [or actor]".

Therefore, I'm +1 rel-photo, and for a "SHOULD" that the photo use a 1:1 aspect ratio.

Chris

--

You received this message because you are subscribed to the Google Groups "Activity Streams" group.

To post to this group, send email to activity...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[Bob Aman]

> I'm -1 for rel-preview.

-1 for rel="preview" for the same reasons.

-Bob Aman

[John Panzer]

I'm +1 on rel-photo, +0 on rel-preview, +1 on SHOULD have 1:1 aspect ratio. 

--

You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

--

[Kevin Marks]

+1 on rel-photo (per hCard, PoCo) -1 on rel-preview +1 on SHOULD 1:1 ratio

[Peter H. Reiser]

+1

Von meinem iPhone gesendet

[Peter H. Reiser]

upps iphone email did not work to well . so here again

+1 on rel-photo (per hCard, PoCo) -1 on rel-preview +1 on SHOULD 1:1
ratio

Regards
Peter

[Richard Cunningham]

It would be good if the dimensions of the photo were available. Whilst
these images SHOULD be 1:1, I expect at first these sites aren't going
to want to add another image dimension to the ones they store - at
first at least.

[Monica Keller]

Guys

We have already agreed on link rel="avatar" to represent a user's
photo as described here

http://martin.atkins.me.uk/specs/activitystreams/activityschema#anchor13

MySpace has link rel="preview" before and had to change it to be
compliant with the spec. We have TweetDeck using it even.


Can we please keep it I think its fairly clear and we had consensus
already.

On Oct 30, 1:24 pm, "Peter H. Reiser" <peter.rei...@gmail.com> wrote:
> +1
>
> Von meinem iPhone gesendet
>

> Am Oct 30, 2009 um 10:03 PM schrieb Kevin Marks <kevinma...@gmail.com>:
>
> > +1 on rel-photo (per hCard, PoCo) -1 on rel-preview +1 on SHOULD 1:1  
> > ratio
>

> > On Fri, Oct 30, 2009 at 1:53 PM, John Panzer <jpan...@google.com>  

> > wrote:
> > I'm +1 on rel-photo, +0 on rel-preview, +1 on SHOULD have 1:1 aspect  
> > ratio.
>

> > On Fri, Oct 30, 2009 at 1:47 PM, Bob Aman <api.boba...@gmail.com>  

> > wrote:
> > > I'm -1 for rel-preview.
>
> > -1 for rel="preview" for the same reasons.
>
> > -Bob Aman
>
> > --
>
> > You received this message because you are subscribed to the Google  
> > Groups "Activity Streams" group.

> > To post to this group, send email to activity-
> > str...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/activity-streams?hl=en
> > .
>
> > --
> > --
> > John Panzer / Google

> > jpan...@google.com / abstractioneer.org / @jpanzer

>
> > --
>
> > You received this message because you are subscribed to the Google  
> > Groups "Activity Streams" group.
>

> > To post to this group, send email to activity-
> > str...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/activity-streams?hl=en
> > .
>
> > --
>

> > You received this message because you are subscribed to the Google  
> > Groups "Activity Streams" group.

> > To post to this group, send email to activity-
> > str...@googlegroups.com.

[Chris Messina]

I think we previously discussed this here?

http://groups.google.com/group/activity-streams/browse_thread/thread/a554cf82cf20fb6c/

Though there was no resolution.

Monica — would it really be super hard to change this from rel-avatar to rel-photo? Seems like a fairly straight-forward change at this point, and since the spec is not final, isn't really something that should be set in stone.

Are there any other implementations of rel-avatar? And, Monica, can you point to where this decision was hashed out before? I recall the discussion, but not the outcome.

Chris

To post to this group, send email to activity...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.

[Monica Keller]

Yes it would be hard to change now because our consumers already
depend on it.

Also other publishers like Cliqset are already using it see
http://cliqset.com/feed/atom?uid=ciberch
btw props to cliqset

But yeah it has been in the spec for a while so anyone who uses it is
following this standard

It was pointed out to me that rel="preview" was not accurate enough so
I changed it in August for MySpace and proceeded to update our wiki
give it to partners etc

link rel="avatar" is effectively in the implementors version.

If we feel strongly enough to change it we should probably do it for
the next version

thanks

On Nov 1, 4:00 pm, Chris Messina <chris.mess...@gmail.com> wrote:
> I think we previously discussed this here?
>

> http://groups.google.com/group/activity-streams/browse_thread/thread/...

>
> Though there was no resolution.
>
> Monica — would it really be super hard to change this from rel-avatar to
> rel-photo? Seems like a fairly straight-forward change at this point, and
> since the spec is not final, isn't really something that should be set in
> stone.
>
> Are there any other implementations of rel-avatar? And, Monica, can you
> point to where this decision was hashed out before? I recall the discussion,
> but not the outcome.
>
> Chris
>

[John Panzer]

Sounds good to me. So can I assume anything in the AS Person
construct can / should be used as extensions is any atom:author or
atom:contributor?

My only quibble is that restricting this to 3 MIME types used in 2009
for 2d images is a bit limiting.

[Chris Messina]

I'm a little confused by your wording John — can you rephrase?

Chris

[John Panzer]

Sorry.  I was initially confused as to whether '"person" Object type' also maps to the atom:author, or not.  The description diverges from atom:author for example, the mapping is nonobvious.  My particular primary use case involves the originator of the content.

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Peter H. Reiser]

John -

What is your particular primary use case ? 

e.g. author = object owner , person = activity owner on the object ?

e.g. person likes a object from author ?

-p

[John Panzer]

The http://salmon-protocol.org case, where I want to identify, most importantly, who said something (= whoever generated a comment, note, activity, etc.)  It sounds like this is separated from atom:author in activity streams for some reason, I'm not sure why.  Preferably, I would like to not drag in all of Activity Streams just for a profile photo (though I am happy to pull in Activity Streams when there are structured activities involved of course!).

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Martin Atkins]

John Panzer wrote:
>
> My only quibble is that restricting this to 3 MIME types used in 2009
> for 2d images is a bit limiting.
>

The intent of that requirement is that publishers must at least provide
a JPEG, GIF or PNG, but may provide other representations too, and that
consumers must at least support decoding JPEG, GIF or PNG images but may
also understand other representations.

In other words, it's a baseline for interop.

However, I agree that right now it's currently not made clear that
providing multiple representations is allowed/encouraged except in order
to provide different sizes, so it should be reworded to make it clear
that multiple combinations of type, width and height are allowed.

[Martin Atkins]

John Panzer wrote:
> The http://salmon-protocol.org case, where I want to identify, most
> importantly, who said something (= whoever generated a comment, note,
> activity, etc.) It sounds like this is separated from atom:author in
> activity streams for some reason, I'm not sure why. Preferably, I would
> like to not drag in all of Activity Streams just for a profile photo (though
> I am happy to pull in Activity Streams when there are structured activities
> involved of course!).
>

Since atom:author (being an Atom Person construct) does not provide for
atom:link children we cannot today use this link rel="avatar" here.

Since atom:link is an Atom namespace element we can't extend the Atom
Person construct with it without either publishing a new rev of Atom or
nesting it inside a foreign extension element.

For Activity Streams we chose to standardize on using the Atom "entry"
construct (which, sadly, is not called out as a data type distinct from
its element name in the Atom spec as Person is) to represent all objects
including people, since the Atom entry construct (modulo extensions
added as the Atom spec allows) provides a rich vocabulary for describing
the properties of a variety of different kinds of objects, while the
Person construct provides only for people and has a somewhat limited
data model.

[Bill de hOra]

Martin Atkins wrote:
> John Panzer wrote:
>> The http://salmon-protocol.org case, where I want to identify, most
>> importantly, who said something (= whoever generated a comment, note,
>> activity, etc.) It sounds like this is separated from atom:author in
>> activity streams for some reason, I'm not sure why. Preferably, I would
>> like to not drag in all of Activity Streams just for a profile photo (though
>> I am happy to pull in Activity Streams when there are structured activities
>> involved of course!).
>>
>
> Since atom:author (being an Atom Person construct) does not provide for
> atom:link children we cannot today use this link rel="avatar" here.

atomPersonConstruct =
atomCommonAttributes,
(element atom:name { text }
& element atom:uri { atomUri }?
& element atom:email { atomEmailAddress }?
& extensionElement*)

> Since atom:link is an Atom namespace element we can't extend the Atom
> Person construct with it without either publishing a new rev of Atom or
> nesting it inside a foreign extension element.

I believe you can. I went through this putting atom:link inside
atom:category last year. It was never the intent of the Atom WG to
disallow adding atom elements as children of other atom elements. If the
RNC doesn't allow atom:author to contain atom:link because of its
"-atom:*" declarations, so much the worse for the RNC as its non-normative.

Bill

[John Panzer]

+1. The spec is clear that atom:link is allowed here.

> --
>
> You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> To post to this group, send email to activity...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
>
>
>

--

[Martin Atkins]

Section 6.2 says:

The Atom namespace is reserved for future forward-compatible
revisions of Atom.

Which I take to mean that it explicitly forbids the use of the Atom
namespace for anything other than forward-compatible revisions of Atom.

Other than this, I find no text that explicitly permits the use of
Atom's elements in unusual contexts. Do you have a citation for a
section of the spec that permits us to alter the requrements for
elements in Atom's own namespace?

[Bill de hOra]

Martin Atkins wrote:

> Section 6.2 says:
>
> The Atom namespace is reserved for future forward-compatible
> revisions of Atom.
>
> Which I take to mean that it explicitly forbids the use of the Atom
> namespace for anything other than forward-compatible revisions of Atom.

Take as forward-compatible revisions of Atom elements and the addition
of new ones.

> Other than this, I find no text that explicitly permits the use of
> Atom's elements in unusual contexts.

Putting any XML element inside an existing atom: elements comes unknown
foreign markup, the atom:* namespace is not a special case. Given that
the spirit of Atom to allow extensibility, I would be looking for a spec
citation that calls out atom-in-atom extensions as having different
rules. So I do think this is ok.

> Do you have a citation for a
> section of the spec that permits us to alter the requrements for
> elements in Atom's own namespace?

Being strictly technical here for a minute, an xmlns is just a
namespace, it says nothing about the arrangement of the XML document,
which is left to specs or schema. In Atom's case the schema isn't
normative, for scenarios exactly like this, where reasonable extensions
are unintentionally forbidden by the schema language (either because of
the way it was written or because the schema language just can't
articulate a construct).

And there's community consensus on a previous case - the thread about
atom:category and atom:link is here

<http://www.imc.org/atom-syntax/mail-archive/msg20456.html>

If you want, I can raise the author scenario on atom-syntax, but I'm
sure the outcome will be the same as the atom:category case.

Bill

[Martin Atkins]

Bill de hOra wrote:
>
> If you want, I can raise the author scenario on atom-syntax, but I'm
> sure the outcome will be the same as the atom:category case.
>

My intent is to avoid stepping on toes. If we can get a green light that
extending author to have a data model that is closer to entry then I've
no objection to using atom:author to indicate the actor of an activity.

However, this feels like something that ought to be a separate spec
rather than an extension created explicitly by the activity streams
specifications.

[John Panzer]

I'm pretty certain this is exactly parallel to atom:category (which ended up getting stuck inside of various things); what kind of green light do you need?  (I think I'm still also a card-carrying member of atom-syntax :) )

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Rob Dolin]

Could someone please give an example of what the two options would look like in XML? 

 

I’m a bit concerned that When a user does an action like “share”, I’m not sure “author” is the right English description since the share’er is not necessarily the author.  Whereas “actor” might be a more appropriate description.

 

FWIW—

--Rob

 

From: John Panzer [mailto:jpa...@google.com]
Sent: Thursday, November 05, 2009 2:04 PM
To: activity...@googlegroups.com
Subject: Re: Idea: <activity:object-type> for avatar / profile picture

 

I'm pretty certain this is exactly parallel to atom:category (which ended up getting stuck inside of various things); what kind of green light do you need?  (I think I'm still also a card-carrying member of atom-syntax :) )

[Martin Atkins]

John Panzer wrote:
> I'm pretty certain this is exactly parallel to atom:category (which
> ended up getting stuck inside of various things); what kind of green
> light do you need? (I think I'm still also a card-carrying member of
> atom-syntax :) )
>

I guess what I'm proposing is that someone would draft up a simple spec
for how we intend to extend atom:author, distinct from the activity
streams specifications, and post it for feedback on atom-syntax.

Assuming that it gets a generally favorable reception on atom-syntax, we
can then refer to this specification from the AtomActivity spec's
description of how the actor is represented in the Atom serialization.