Issue with atom:published vs atom:updated for Time handling?

[Marko Degenkolb]

Reading http://activitystrea.ms/head/atom-activity.html I see an issue
with using atom:published for "Time":

Atom Syndication Format requires to have a mandatory atom:updated
element (http://tools.ietf.org/html/rfc4287#section-4.1.2). AS
requires to have a mandatory atom:published element (http://
activitystrea.ms/head/atom-activity.html#activity.time + 3.1.1 &
3.1.2)

=> to be a valid Atom AND AS entry you need to provide both
(atom:published + atom:updated) which typically will be redundant
content

=> the statement "Any valid Atom entry as defined by section 4.1.2 of
[RFC4287] is a representation of an activity as defined in Section 2.1
(The Activity Construct)." (http://activitystrea.ms/head/atom-
activity.html#atom.activity) doesn't seem to be true since the
atom:published element might not be in the Atom entry whereas it is
required in an AS entry.

Can someone please shed some light on this?

[Steve Ivy]

Marko,

It's my understanding that atom:published is required by the Atom spec
as the "created date" for Atom entries. Atom AS uses the "created
date" as the time of the event.

The Atom spec also allows for atom:updated which tells a processor
that this entry has been recently modified (the "modified date") and
should be treated accordingly. I believe that Atom AS ignores the
atom:updated value.

--Steve

> --
> 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.
>
>

--
Steve Ivy
http://monkinetic.com // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[James Snell]

Steve, this is incorrect. The use of the atom:published element is optional in Atom and atom:updated is required. 

[Marko Degenkolb]

Furthermore interesting:
Both IE as well as Firefox ignore the <published> tag when displaying
an AS stream but show the <updated> value. (I haven't tried with other
readers)
This makes me really wonder why AS chose to use published as the
mandatory element for the time.

[Bo Xing]

Marco, I definitely see your point. It is a little weird that
<updated> is not required while IE and Firefox displays and sorts ATOM
entries based on their <updated> values. I think that the AS spec
needs to fix this.

As of now, I think the best practice would be to have both <published>
and <updated> fields present in your AS entries with equal values. In
the mean time, I do see certain cases where the two fields might not
be equal. For example, in an Object-only AS entry (without a verb),
<published> indicates the first time the entry was published, whereas
<updated> reflects the latest time that the object content had a
change.

[John Panzer]

atom:updated is required for entries and reflects that last best-known "significant change" timestamp.  So if you are getting updated entries you're going to see this timestamp change, and you know when the change/edit occurred.

atom:published is optional and immutable for a given entry once created; it reflects the original date of publication of the content.  It turns out this is not as useful as knowing when the content was last updated, so if you have to pick one, you pick updated.  Obviously upon initial creation updated=published in any case.

AS should be requiring atom:updated, not atom:published.

The Buzz APIs provide both, and change the atom:updated timestamp when the entry changes.  In particular if you are subscribe to a feed via PubSubHubbub, you can distinguish between a new vs. updated entry by comparing these two timestamps; if ==, this is an initial/new entry, if !=, it's an change to a previously published activity.  You can find the original activity, if you ever received it, by keying off of the atom:id GUID.

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

[Martin Atkins]

On 11/23/2010 11:36 AM, John Panzer wrote:
> atom:updated is required for entries and reflects that last best-known
> "significant change" timestamp. So if you are getting updated entries
> you're going to see this timestamp change, and you know when the
> change/edit occurred.
>
> atom:published is optional and immutable for a given entry once created;
> it reflects the original date of publication of the content. It turns
> out this is not as useful as knowing when the content was last updated,
> so if you have to pick one, you pick updated. Obviously upon initial
> creation updated=published in any case.
>
> AS should be requiring atom:updated, not atom:published.
>

Atom Activity Streams uses atom:published for its immutable nature; the
activity being described happened at a specific time and changes to the
description of that activity (which would in theory result in a change
to atom:updated) don't change the time at the activity occurred.

Atom Activity Streams requires published because we provide a more
specific meaning for it than Atom itself provides and that meaning is
required. Atom Activity Streams does not itself require updated, but
since Atom itself does anyone publishing Atom Activity Streams should
include it to comply with the requirements in Atom itself. atom:updated
is does not represent any part of the Activity Streams data model and
thus does not change the meaning of a published activity.

The requirements in Atom Activity Streams should never be looser than
Atom itself, but they are often stricter due to requirements specific to
the abstract data model Activity Streams defines, as we see in this example.

[Monica Wilkinson]

Something to consider is the concept of a "last interacted timestamp" which would reflect the last timestamp for an in reply to activity or reaction such as a like or comment.

The original activity is immutable in most systems however it is important to address subsequent relevant interactions.

I dont think atom:updated would be the right concept the way it is defined today. New field ?

In our system this is the required field and the field used for fetching deltas...

--

[Bo Xing]

Martin,

That clarifies things, and does make sense.

In this case, I think the examples on this page:
http://activitystrea.ms/spec/1.0/atom-activity-01.html need to be
changed to have what you said clearly conveyed. They do not have the
<atom:updated> fields, which could be misleading.

[John Panzer]

In Buzz today, the atom:updated changes with each new like or comment on the entry (because the entry's metadata has changed).  We consider things like the list of people who have liked something, and the count of comments/most recent comment timestamp, to be significant changes to the activity.  (In other words, we view activities as conversations, not as immutable objects.)

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

[Bob Wyman]

Atom:published is "an instant in time associated with an event early in the life cycle of the entry." Typically, it is the instant in time at which the entry was first published. However, the reality is that there are a variety of reasonable situations in which software that is creating an instance of an entry does not know when the first instance of the entry was created or even what might be considered "early in the life cycle of the entry." Also, one assumes that atom:published should be immutable across all instances of an entry -- throughout the entry's entire life cycle. That is a hard contract to satisfy if the software doesn't or can't know when the entry was first created. 

On the other hand, software can pretty much always know what time it is "now" and thus can be expected to be reasonably accurate in generating an atom:updated value. This is one of the reasons that Atom requires atom:updated but not atom:published. Atom:published is "hard" to know. Atom:Updated is easy to know.

bob wyman

[Martin Atkins]

On 11/23/2010 12:42 PM, Bob Wyman wrote:
> Atom:published is "an instant in time associated with an event early in
> the life cycle of the entry." Typically, it is the instant in time at
> which the entry was first published. However, the reality is that there
> are a variety of reasonable situations in which software that is
> creating an instance of an entry does not know when the first instance
> of the entry was created or even what might be considered "early in the
> life cycle of the entry." Also, one assumes that atom:published should
> be immutable across all instances of an entry -- throughout the entry's
> entire life cycle. That is a hard contract to satisfy if the software
> doesn't or can't know when the entry was first created.
>
> On the other hand, software can pretty much always know what time it is
> "now" and thus can be expected to be reasonably accurate in generating
> an atom:updated value. This is one of the reasons that Atom requires
> atom:updated but not atom:published. Atom:published is "hard" to know.
> Atom:Updated is easy to know.
>

I would contend that while that is true in the general case of Atom,
when considering Activity Streams the time an activity occurred is
fundamental to the concept of an activity and therefore anyone
publishing activities can be expected to have a timestamp to publish.

[Martin Atkins]

On 11/23/2010 12:07 PM, John Panzer wrote:
> In Buzz today, the atom:updated changes with each new like or comment on
> the entry (because the entry's metadata has changed). We consider
> things like the list of people who have liked something, and the count
> of comments/most recent comment timestamp, to be significant changes to
> the activity. (In other words, we view activities as conversations, not
> as immutable objects.)

That seems like correct behavior to me. Atom Activity Streams says
nothing about management of atom:updated, so the requirements from the
Atom spec apply, and any significant changes to the entry representing
the activity should therefore cause atom:updated to be changed.

However, that only has meaning at the Atom processor layer; none of the
fields in the activity streams data model are derived from atom:updated
and therefore a change to atom:updated alone does not cause any change
as far as an Activity Streams processor is concerned.

So to pick on a specific use-case, Let's imagine an implementation where
an Atom poller receives atom:entry elements and uses the atom:id and
atom:updated elements together to decide if this content has already
been processed. If and only if this combination of atom:id and
atom:updated have not been seen before would this layer translate the
atom:entry element into an Activity Streams Activity Construct and pass
it to a serialization-agnostic codepath that integrates that content
into an activity stream.

In other words, the atom:updated element informs processing by the Atom
poller but is invisible and irrelevant to the activity processing code.

This separation between the transport and the Activity processing is
intentional, both to create a resilience to new transport mechanisms
such as PubSubHubbub (where arguably any new notification is worth
processing, regardless of atom:updated) and to allow for other
serializations such as JSON Activity Streams without changes to the core
business logic.

[John Panzer]

I think this is inconsistent with the Atom serialization being built on top of (and thus sharing the semantics of) Atom, but more importantly it cuts out extremely useful use cases for no good purpose.  You seem to be saying that an AS processor will have _less_ information than a generic Atom processor, and in particular in this case it couldn't know how to order activities by most-recent-change timestamp (as, for example, the Buzz UI does).

Or I may be missing what you're saying entirely.

[Monica Wilkinson]

I read similar. The last interacted or updated timestamp is a core field which is needed regardless of format.

Any opposition to adding this as a core construct at the activity level ?

[Martin Atkins]

On 11/23/2010 04:04 PM, John Panzer wrote:
>
> I think this is inconsistent with the Atom serialization being built on
> top of (and thus sharing the semantics of) Atom, but more importantly it
> cuts out extremely useful use cases for no good purpose. You seem to be
> saying that an AS processor will have _less_ information than a generic
> Atom processor, and in particular in this case it couldn't know how to
> order activities by most-recent-change timestamp (as, for example, the
> Buzz UI does).
>
> Or I may be missing what you're saying entirely.
>

That observation (that a serialization-agnostic activity processor can't
order by updated time) is correct today.

We could of course decide to add an updated time to the activity streams
abstract data model, and we may or may not decide to represent that as
atom:updated in the Atom serialization. Until now no-one offered a use
case nor a desire to do that, so it doesn't exist in the spec today.

[Tuomas Koski]

Hi,

This is just my couple of cents and I don't claim to be a professional
in any of the matters. However I hope the points monsieur John Panzer
brought out will be considered and implemented in the specification.

Why?

1) If I have read the Atom specs correctly, a atom without <updated>
element is not an "valid" atom. Right?
2) We will loose all the flexibility the mentioned element provides.

I hope we will not use an existing and widely used specification
"wrong" by deprecating it's mandatory requirements or by redefining
the meaning and usage of the elements.

John, don't give up. Monica, thank you for the support.

And thank you all for the AS! I have implemented it successfully in
multiple ways.

Cheers,
--
Tuomas
xmpp:tuo...@xmpp.lobstermonster.org

[Marko Degenkolb]

I would like to support the statements from Tuomas, John, and Monica.
We definitely should not weaken the standard we derive from.

Another point: most of our discussion here focuses on the AS provider.
Let’s now take a look at an AS consumer (e.g. a plain feed reader
displaying activities to start with). How is that supposed to
interpret these two fields?
As long as we cannot define a distinct and meaningful contract to both
along with a good understanding how they shall be consumed, we should
require one mandatory element only – and in this case I would vote for
updated, being the mandatory field in Atom already.

[Martin Atkins]

On 11/26/2010 09:16 AM, Marko Degenkolb wrote:
> I would like to support the statements from Tuomas, John, and Monica.
> We definitely should not weaken the standard we derive from.
>
> Another point: most of our discussion here focuses on the AS provider.

> Let�s now take a look at an AS consumer (e.g. a plain feed reader

> displaying activities to start with). How is that supposed to
> interpret these two fields?
> As long as we cannot define a distinct and meaningful contract to both
> along with a good understanding how they shall be consumed, we should

> require one mandatory element only � and in this case I would vote for

> updated, being the mandatory field in Atom already.
>

atom:updated does not meet the needs of the activity time component,
since the time component is the time the event occured and should NOT
change when the metadata of the event changes.

[John Panzer]

Basic Atom already handles this case: If you supply updated but not
published, consumers generally assume published=updated (in the
absence of other data). AS could just codify this.

On Friday, November 26, 2010, Martin Atkins <ma...@degeneration.co.uk> wrote:
> On 11/26/2010 09:16 AM, Marko Degenkolb wrote:
>
> I would like to support the statements from Tuomas, John, and Monica.
> We definitely should not weaken the standard we derive from.
>
> Another point: most of our discussion here focuses on the AS provider.

> Let’s now take a look at an AS consumer (e.g. a plain feed reader

> displaying activities to start with). How is that supposed to
> interpret these two fields?
> As long as we cannot define a distinct and meaningful contract to both
> along with a good understanding how they shall be consumed, we should

> require one mandatory element only – and in this case I would vote for

> updated, being the mandatory field in Atom already.
>
>
>
> atom:updated does not meet the needs of the activity time component, since the time component is the time the event occured and should NOT change when the metadata of the event changes.
>

> --
> 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.
>
>

--