| TOC |
|
This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC 2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
This document presents an extension that allows activities on social objects to be expressed within the Atom Syndication Format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
2.
Notational Conventions
3.
Activity Concepts
3.1.
Verbs and Object Types
4.
Activity Entries
4.1.
Activity Title, Summary and Detail
4.2.
Time of the Activity
4.3.
Activity Link
4.4.
Activity Verb
4.5.
Activity Object
4.5.1.
The activity:object-type Extension Element
4.6.
Activity Target
4.7.
Activity Actor
4.8.
Activity Generator
5.
Object Entries
5.1.
Implied Activity
5.1.1.
The verbs for the Implied Activity
6.
Activity Feeds
6.1.
A Note about Legacy Feeds
7.
The 'post' Verb
8.
Requirements for Activity Re-publishers
9.
Security Considerations
10.
IANA Considerations
11.
Normative References
Appendix A.
Acknowledgements
Appendix B.
Examples
B.1.
Activity Entry Examples
B.2.
Object Entry Example
Appendix C.
Object Entries in RSS
§
Authors' Addresses
| TOC |
This document presents an extension that allows activities on social objects to be expressed within the Atom Syndication Format (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.) [RFC4287].
| TOC |
The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML elements and attributes described in this specification is: http://activitystrea.ms/spec/1.0/.
In this document, this namespace is referred to as "the AtomActivity namespace", and the namespace prefix "activity:" is used for the above namespace URI. The namespace prefix "atom:" is used for the namespace URI http://www.w3.org/2005/Atom. The namespace prefix "thr:" is used for the namespace URI http://purl.org/syndication/thread/1.0. The choices of namespace prefix are arbitrary and not semantically significant.
This specification uses a shorthand form of terms from the XML Infoset [W3C.REC-xml-infoset-20040204]. The phrase "Information Item" is omitted when naming element and attribute information items. Therefore, when this specification uses the term "element," it is referring to an element information item in infoset terms. Likewise, when this specification uses the term "attribute," it is referring to an attribute information item.
This specification allows the use of IRIs [RFC3987]. Every URI [RFC3986] is also an IRI, so a URI may be used wherever an IRI is named. When an IRI that is not also a URI is given for dereferencing, it MUST be mapped to a URI using the steps in Section 3.1 of [RFC3987]. When an IRI is serving as an identifier, it MUST NOT be so mapped.
The text of this specification provides the sole definition of conformance. Examples in this specification are non-normative.
This specification uses "the Atom specification" to refer to [RFC4287] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.).
| TOC |
For the purpose of this specification, an activity is a description of an action that was performed (the verb) at some instant in time by some actor (the actor, as described in Section 4.7 (Activity Actor) ), with some social object (the object). An activity feed is a feed of such activities.
An activity may also have a target, which is the object into which or to which the action was done. Whether a target is allowed and the specific meaning of a target is defined by each verb.
It is expected that in many cases consumers of activity feeds will use them to turn machine readable descriptions of activities into human-readable sentences such as "Joanne posted a Photo: 'My Cat'". The process for forming such sentences is not defined by this specification.
| TOC |
Verbs and object types are identified by IRIs (verb and object identifiers) as defined by [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.) though these IRIs MAY not resolve to any useful resource. One verb is defined by this specification in Section 7 (The 'post' Verb).
Other specifications MAY define further verb and object types with corresponding IRIs. Such specifications MUST define the meaning of these verb and object identifiers, and SHOULD also describe how any additional properties of the verb or object type are to be encoded in an Atom entry.
Verbs and object types MAY derive from other verbs and object types. The properties required by the parents will also be required by the derived types. For example, if there is a base object type image and a derived type of photo, all properties that are defined for image are also defined for photo. Consumers that do not support the photo object type may use their recognition of the image object type as a fallback when processing an object of type photo.
| TOC |
An activity entry is an entry element as described by the Atom specification that represents an activity. The actor of the activity entry is the author of the entry. The verbs and object of the activity are identified explicitly in the Activity entry as described in the following sections. An Atom entry is considered to be an activity entry if and only if it has at least one activity:verb child element and one or more activity:object child elements as described in the following sections.
| TOC |
In an activity entry, the atom:title, atom:summary and atom:content elements as described by [RFC4287] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.) MUST contain a human-readable description of the activity. This text will be used by general Atom processors that do not understand this extension. This text MAY also be used by feed processors that do not recognize the verb. Any other non-activity elements may be used in an activity entry to effect a desired handling by non-activity processors.
Feed producers MAY use information from outside sources to choose a suitable language to use for the activity description. For example, a feed producer responding to an HTTP request might use the HTTP Accept-Language header or a user preference otherwise determined to select a language. Feed producers SHOULD use xml:lang as described in [RFC4287] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.) section 2 to identify the language used.
| TOC |
The time at which an activity occurred is represented in the atom:published element within each activity entry. An activity entry MUST have exactly one atom:published element.
The time stored herein is the time that the activity occurred, not the time that the associated activity object was published. Feed processors MAY use this element to sort a list of activity entries into chronological order.
| TOC |
An activity entry SHOULD include an atom:link element with a link relationship of "alternate", a type of "text/html" and a href attribute containing the URL of an HTML-based representation of this activity or the associated object. Though this link does not have any special significance in this specification, general Atom processors that do not support the activity extensions will often present such a link to the user.
| TOC |
Verbs are represented using the activity:verb Extension Element. All activity entries MUST have at least one activity:verb element.
The content of the activity:verb element MUST be a verb identifier (an IRI as defined by [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.)). Note that the definition of IRI excludes relative references. Although the IRI MAY use a dereferencable scheme, processors must not assume that it can be dereferenced.
The verb identifier within this element defines a verb for this activity. A given activity entry MAY have more than one activity:verb element, which indicates that there are several verbs describing this activity. Where multiple verbs are used, all verbs MUST be generalizations or specializations of one another. For example, the general verb "to experience" might be specialized by a verb "to listen to". If a derived verb is used, publishers SHOULD also include all of its ancestor types so that a consumer may use the most specific verb it understands.
An activity feed processor SHOULD use the most specific verb it understands within each entry. If none of the activity's verbs are understood by the processor, the processor MAY use other information to infer the verb, or the processor MAY use the content of the atom:title, atom:summary and/or atom:content to obtain a human-readable description of the activity as a fallback.
<entry>
<id>tag:versioncentral.example.org,2009:/commit/1643245</id>
<published>2009-06-01T12:54:00Z</published>
<title>Geraldine committed a change to yate</title>
<content type="html">Geraldine just committed a change to yate on VersionCentral</content>
<link rel="alternate" type="text/html"
href="http://versioncentral.example.org/geraldine/yate/commit/1643245" />
<activity:verb>http://activitystrea.ms/schema/1.0/post</activity:verb>
<activity:verb>http://versioncentral.example.org/activity/commit</activity:verb>
<activity:object>
<activity:object-type>http://versioncentral.example.org/activity/changeset</activity:object-type>
<id>tag:versioncentral.example.org,2009:/change/1643245</id>
<title>Punctuation Changeset</title>
<summary>Fixing punctuation because it makes it more readable.</summary>
<link rel="alternate" type="text/html" href="..." />
</activity:object>
</entry>Example: This example introduces a "changeset" object type and a "commit" verb, both ficticious, invented for the ficticious example service "VersionCentral". Since the "commit" verb is a derived type of "post", VersionCentral's activity entries include both the "post" verb and the "commit" verb so that consumers which do not support their proprietary extension may fall back on the "post" verb.
| TOC |
The object is represented using the activity:object extension element. The activity:object element contains information about the main object of the activity. All activity entries MUST have one or more activity:object elements. The content model of activity:object is identical to that of atom:entry when used to describe an object as described in Section 5 (Object Entries).
activity:object MUST contain exactly one atom:id element. If this object is also published elsewhere, the atom:id value SHOULD be the same in all representations.
activity:object SHOULD contain exactly one atom:title element, whose value provides the human-readable display name for the object.
activity:object SHOULD also contain exactly one atom:link element with a link relationship of "alternate" and the type "text/html", with the href attribute containing the URL of the HTML representation of the object if available.
activity:object MAY also contain an atom:source element, as described by the Atom specification, describing the feed where this object resides. Processors MAY use this information to give context to the activity. If an atom:source element is not present, the feed which contains the object is the source.
activity:object MAY also contain a thr:in-reply-to element, as described by [RFC4685] (Snell, J., “Atom Threading Extensions,” September 2006.), identifying a second object that this object is considered to be in reply to.
activity:object MAY contain additional elements whose meaning depends on the definition of the object types identified in the activity:object-type element as described in Section 4.5.1 (The activity:object-type Extension Element).
An activity entry and its associated object entry MUST NOT share the same atom:id value.
If an activity entry contains more than one activity:object element, that activity entry represents several activities. These activities all share the same actor, target, verbs, and time but use each activity:object element in turn. When a set of activities is coalesced in this way it holds no special meaning to activity processors; it is intended to allow publishers to provide pre-coalesced activities to generic Atom consumers.
| TOC |
The content of the activity:object-type element MUST be an object identifier (an IRI as defined by [RFC3987] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.)). The definition of IRI excludes relative references. Though the IRI MAY use a dereferenceable scheme, processors MUST not assume that it can be dereferenced.
The object identifier within this element gives an object type for the object described by this object entry. A given object entry MAY have more than one activity:object-type element, which indicates that this object has several types. Where multiple types are used, all types MUST be generalizations or specializations of one another. For example, the general type "web page" might be specialized by a type "weblog entry". If a derived type is used, publishers SHOULD also include all of its ancestor types so that a consumer may use the most specific type it understands.
An object entry SHOULD have at least one activity:object-type element.
Activity feed processors SHOULD use the most specific object type that they understand within each entry. The processor MAY use other information to infer the object type if it cannot understand any of the object types given. If it cannot so infer the object type, a processor MUST act as though no activity:object-type element is present.
If no activity:object-type element is present, the object has no specific type. Processors SHOULD refer to such objects only by their titles. For example, when forming an activity sentence a processor might say "Johan posted 'My Cat'" rather than "Johan posted a photo: 'My Cat'".
| TOC |
The activity:target element contains information about the target of the activity, for verbs that support a target. The target is the object that the action was done to. The content model of activity:target and the meaning of its child elements are identical to that of activity:object. The precise meaning of the target as relates to the activity depends on the verb in use, but its meaning is somewhat similar to the English preposition "to". The activity:target extension element MUST NOT be used for indirect objects that are not targets.
For example, in Figure 2 the target is a photo album to which photos were added.
| TOC |
The actor of an activity is identified by the atom:author element of the activity entry. The Atom specification defines the atom:author element to identify the author of an entry, feed, or source feed. This specification extends the object model of atom:author to include the additional elements defined for activity:object.
If an activity entry does not contain an atom:author element, a consumer SHOULD use the atom:author of the contained atom:source element or of the containing atom:feed, as defined in Section 4.2.1 of the Atom specification.
| TOC |
The atom:generator element is defined by the Atom specification as a feed-level element for identifying the agent used to generate a feed. This specification defines an additional use of the atom:generator element as a child element of an activity. In this context, it identifies the agent used to create that individual activity entry.
If an activity entry does not contain an atom:generator element, then the atom:generator of the contained atom:source element is considered to apply. In an Activity Feed Document, the atom:generator element of the containing atom:feed element are considered to apply to the entry if there are no atom:generator elements in the locations described above.
| TOC |
An object entry is an entry element as described by the Atom specification that represents the object of an activity. Any entry that does not meet the criteria for being an activity entry as described in Section 4 (Activity Entries) is considered an object entry by this specification. In particular, this means that a valid Atom entry without any activity annotations is considered to be an object entry by this specification.
Object entries are intended to be used by feeds that describe the creation of content. In a valid object entry, all Atom elements SHOULD describe the object that was created or otherwise the object of an activity, rather than describing the activity itself.
The content model of an object entry is the same as that of an activity:object element used within an activity entry, as defined in Section 4.5 (Activity Object).
| TOC |
When used alone, outside of the context of an explicit activity entry, an object entry has an implied activity. The implied activity entry for an object entry is constructed as follows:
Processors SHOULD generate suitable human-readable descriptions of the action and insert them as described in Section 4.1 (Activity Title, Summary and Detail).
If the resulting entry will be published, processors SHOULD generate suitable values for all other elements that the Atom specification requires as children of atom:entry. In particular, an atom:id value SHOULD be generated; this value MUST NOT be the same as that of the object entry's atom:id.
If the resulting entry is to be published, processors MAY omit elements from the generated activity:object element to reduce overhead. Such processors SHOULD bear in mind the requirements in Section 4.5 (Activity Object).
Processors expecting activity entries SHOULD apply the above transformation to any object entries they encounter in order to process them as activities, or at least act as if they have done so.
Due to the way it is constructed, there is no way to represent additional properties for the verb(s) of an implied activity. If a particular verb requires additional properties then it MUST NOT be used in an implied activity.
| TOC |
When appearing as a child of an object entry (that is, an entry that does not also have an activity:object child element), the content of the activity:verb element MUST be the verb type of the implied activity for the object entry, as defined in Section 5.1 (Implied Activity). When used in this way, the content model is identical to when used in an activity entry as described in Section 4.4 (Activity Verb).
| TOC |
This specification defines no required extensions to the atom:feed element as defined by the Atom specification. Therefore a standard Atom feed that contains only activity entries as defined above can be considered to be an activity feed. Processors MAY create an activity entry representing the implied post activity of an object entry (see Section 5.1 (Implied Activity)) in order to synthesize an activity feed from a traditional Atom feed.
A feed MAY contain both activity and object entries.
| TOC |
This section is non-normative.
The implied post activity as described in Section 5.1 (Implied Activity), along with the advice about untyped object entries in Section 5 (Object Entries), are together intended to provide a mechanism for processing traditional non-activity Atom feeds as Activity Feeds. At the time of writing this specification, most such feeds serve to describe the activity of posting an item such as a weblog entry or a photo.
It is acknowledged, however, that there exist feeds that have other meanings, such as a list of a particular user's "favorite" objects. When applying the advice for processing feeds without activity extensions to such feeds, a processor will likely misinterpret the nature of the activity. In practice, however, it seems that most feeds of this kind include something in the title indicating their nature, so rendering such a misinterpreted activity to a sentence will lead to something such as Joe posted "Funny Cats" in "Joe's Favorite Videos", which, while not ideal, is an acceptable result in situations where activities are primarily for human consumption.
| TOC |
This specification defines a single verb, which has the verb Identifier IRI http://activitystrea.ms/schema/1.0/post.
This verb describes the act of posting or publishing an object on the web. The implication is that before this activity occurred the object was not posted, and after the activity has occurred it is posted or published.
This verb is used when creating the Implied post activity for a standalone object entry that has no explicit verb. It MAY also be used as the value of activity:verb in an explicit activity entry.
In an activity entry which has the 'post' verb, the value of the atom:published element SHOULD be the same as the atom:published element in the associated object entry.
If an activity using this verb has an activity:target element, the target object is the collection in which the item was posted.
The 'post' verb has no additional properties or modifiers.
| TOC |
An activity re-publisher is any system that produces feeds that contain activities or objects that were obtained from another feed or feed-like data source. This section contains requirements for such systems that aim to allow consumers of such feeds to process the activities described in such feeds in a way similar to how they would have processed the activities when obtained directly from the source, and to allow consumers to detect duplicate activities or objects obtained via multiple feeds.
An activity re-publisher may choose to produce either object entries or Activity Entries, except where the the re-publisher is re-publishing an activity entry, in which case the activity entry MUST be produced to avoid loss of information that cannot be expressed in an object entry.
Where a re-publisher produces a full activity entry from a source object entry, the mapping process described in Section 5.1 (Implied Activity) MUST be used. A re-publisher MAY perform additional mapping steps when doing this conversion.
Where a re-publisher produces a full activity entry from a source RSS object entry, the mapping process described in Appendix C (Object Entries in RSS) MUST be used. A re-publisher MAY perform additional mapping steps when doing this conversion.
If a source object entry does not contain verb or object type information, a re-publisher MAY use information obtained elsewhere to synthesize appropriate verb or object type annotations.
When a re-publisher reproduces a source activity entry, the publisher MUST copy the atom:id and atom:published elements from the source activity entry without modification, and MUST similarly preserve the contents of all elements in the AtomActivity namespace where these elements are used correctly as per this specification. Additionally, the re-publisher SHOULD copy the entry's atom:generator element without modification, if present.
When a re-publisher reproduces an entry, the atom:source element MUST be used in accordance with its definition in the Atom specification. A re-publisher SHOULD include as much information as possible from the source entry, paying special attention to data that is of significance to the object type(s) and/or verb(s) used on the entry where these are known to the re-publisher.
When a re-publisher produces a feed of activities aggregated from multiple sources but known via some externally-obtained information to be by the same actor, even if that actor is represented by a different object in different source feeds, the re-publisher SHOULD create a feed-level atom:author element that describes the re-publisher's representation of the actor and then substitute this representation in any atom:author, activity:object or activity:target element known to represent the same actor.
| TOC |
As this specification defines an extension to the Atom Syndication Format, it is subject to the same security considerations defined in [RFC4287] (Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005.).
Publishers or Consumers implementing Activity Streams as a stream of public data may also want to consider the potential for unsolicited commercial or malicious content and should take preventative measures to recognize such content and either identify it or not include it in their stream implementations.
Publishers should take reasonable measures to make sure potentially malicious user input such as cross-site scripting attacks are not included in the Activity Streams data they publish.
Consumers that re-emit ingested content to end-users MUST take reasonable measures if emitting ingested content to make sure potentially malicious ingested input is not re-emitted.
Consumers that re-emit ingested content for crawling by search engines should take reasonable measures to limit any use of their site as a Search Engine Optimization loophole. This may include converting un-trusted hyperlinks to text or including a rel="nofollow" attribute.
| TOC |
None.
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997. |
| [RFC3339] | Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002. |
| [RFC3987] | Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005. |
| [RFC4287] | Nottingham, M. and R. Sayre, “The Atom Syndication Format,” December 2005. |
| [RFC4685] | Snell, J., “Atom Threading Extensions,” September 2006. |
| [RSS_2.0] | Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002. |
| TOC |
...
| TOC |
This appendix is non-normative. Where these examples include fragments of XML documents, assume the namespace declarations xmlns="http://www.w3.org/2005/Atom" xmlns:activity="http://activitystrea.ms/spec/1.0/" are in scope.
| TOC |
A typical activity entry
<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="http://example.com/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="http://example.com/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="http://example.com/geraldine/photofeed.xml" />
<link rel="alternate" type="text/html"
href="http://example.com/geraldine/" />
</source>
</activity:object>
<content type="html">
<p>Geraldine posted a Photo on PhotoPanic</p>
<img src="/geraldine/photo1.jpg">
</content>
</entry>This example shows a typical activity entry using the post verb defined by this specification and a hypothetical "photo" object type. It also demonstrates the use of atom:title and atom:content to provide fallback content for feed processors that do not support activity extensions. An activity stream application might render this entry into the sentence "Geraldine posted a photo titled 'My Cat' in Geraldine's Photos", with the photo title and the source feed title presented as links.
| Figure 1 |
<entry>
<id>tag:photopanic.example.com,2009:/activity/4859568/PhotoAdd/2519358/2009171</id>
<title type="text">Geraldine added two new photos to the My Pets album.</title>
<published>2009-06-21T00:28:35Z</published>
<author>
<name>Geraldine</name>
<uri>http://example.com/geraldine</uri>
<id>tag:photopanic.example.com,2009:/Person/4859568</id>
<activity:object-type>
http://activitystrea.ms/schema/1.0/person
</activity:object-type>
<link rel="alternate" type="text/html"
href="http://example.com/geraldine" />
</author>
<link rel="alternate" type="text/html"
href="http://example.com/geraldine/activities/1234" />
<content type="xhtml">...</content>
<activity:target>
<activity:object-type>http://activitystrea.ms/schema/1.0/photo-album</activity:object-type>
<id>tag:photopanic.example.com,2009:/Photo_Album/2519358</id>
<title>My Pets</title>
<link rel="alternate" type="text/html"
href="/geraldine/albums/pets" />
</activity:target>
<activity:object>
<activity:object-type>http://activitystrea.ms/schema/1.0/photo</activity:object-type>
<activity:object-type>http://activitystrea.ms/schema/1.0/image</activity:object-type>
<id>tag:photopanic.example.com,2009:/Photo/2519358/60764840</id>
<title>My Cat</title>
<link rel="alternate" type="text/html"
href="/geraldine/photos/1643" />
<link rel="preview" type="image/jpeg"
href="/geraldine/photos/1643/thumb.jpg" />
<link rel="enclosure" type="image/jpeg"
href="/geraldine/photos/1643/full.jpg" />
</activity:object>
<activity:object>
<activity:object-type>http://activitystrea.ms/schema/1.0/image</activity:object-type>
<activity:object-type>http://activitystrea.ms/schema/1.0/photo</activity:object-type>
<id>tag:photopanic.example.com,2009:/Photo/2519358/60764844</id>
<title></title>
<link rel="alternate" type="text/html"
href="/geraldine/photos/1634" />
<link rel="preview" type="image/jpeg"
href="/geraldine/photos/1634/thumb.jpg" />
<link rel="enclosure" type="image/jpeg"
href="/geraldine/photos/1634/full.jpg" />
</activity:object>
</entry>Example: An activity entry showing the use of the actor, verb, object and target elements. Also illustrated is the use of multiple objects in a single activity entry, which serves as a shorthand for publishing multiple consecutive activities with the same verb and target.
| Figure 2 |
| TOC |
A simple object entry
<entry>
<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>
</entry>
This example shows an object entry describing the object referred to in the activity from Appendix B.1 (Activity Entry Examples). That example would also be an acceptable implied post activity for this entry, assuming that this entry were in a feed whose attributes match those of the atom:source in the activity entry example.
| TOC |
For compatibility with existing deployments, this specification also recommends a subset of the activity markup that may be used in RSS 2.0 (Klyne, G., “Date and Time on the Internet: Timestamps,” July 2002.) [RSS_2.0] feeds to add verb and object type annotations to objects published in RSS rather than Atom feeds.
Objects published as RSS 2.0 item elements may use the activity:verb and activity:object-type elements with equivalent content models and semantics as described above for their use in Atom object entries.
Activity processors should use the following process to construct the implied activity for an object entry published as an RSS 2.0 item element, or should act as if they have done so:
If the above procedure results in an activity entry that is not valid as per this specification or the Atom specification, processors should treat the result as they would had the invalid entry arrived in a real feed rather than having been synthesized.
| TOC |
| Martin Atkins | |
| Six Apart | |
| David Recordon | |
| Chris Messina | |
| Citizen Agency | |
| Monica Keller | |
| Ari Steinberg | |
| Rob Dolin | |
| Microsoft |