[Standards-JIG] PubSub JEP: Add entity updated messages

Bob Wyman bob at wyman.us
Sat Sep 10 18:55:39 CDT 2005


Matthew Fowle wrote:
> A client to the XMPP pubsub service does not have any way to 
> differentiate between an entry creation and entry update.  At best it 
> can "guess" from the <published/> and <updated/> times inside the Atom 
> entry.
	The correct place to extend the expressiveness of Atom is in the
Atom syntax itself, not in the "Atom over XMPP" protocol. For a variety of
reasons, debated endlessly on the Atom-syntax list, Atom provides no
universally available explicit method of marking an entry as being an
updated instance of a previously published entry. Two mechanisms are
provided for discovering that something is an update:
	* An entry may be explicitly marked as being an update to an earlier
instance by inserting an atom:updated value which is different from the
atom:published value. However, this explicit mechanism is optional and may
be used by some publishers only to indicate that an update is "substantial".
Atom permits publishers to create entries which are "minor" modifications to
the original entry instance without providing any explicit flagging in the
entry metadata. 
	* In any case, an entry may be recognized as being an "update" of a
previously published entry if it is seen to have the same atom:id as a
previously published entry instance and it is seen to have different content
than an instance seen earlier. However, Atom provides no mechanism to
determine in what order the original entries may have been created. The
assumption is that if you are reading from a source feed, then that entry
instance which you saw first is, in fact, the earliest that was produced.
However, this assumption is not useful when retrieving entries from
secondary sources. (i.e. an entry that contains an atom:source element
indicating that it did not originate in the feed from which it was read.)
	As with any protocol or syntax, Atom has a few rough edges. This
business of entry versioning is one of Atom's rougher edges. Personally, I
fought long and hard on the atom-sytnax list to require that atom:updated be
required on all entries. However, this requirement was considered onerous by
the majority of those involved in the process and was thus not included in
the specification.
	Having explained a bit of the history, let me repeat that errors or
weaknesses in Atom should be addressed in the Atom Working Group, not in the
JEP forums. The goal of the "Atom over XMPP" specification should be to
define how best to pass Atom over XMPP. It would not be appropriate to use
this context as one in which the semantics of Atom itself are modified.

	bob wyman






More information about the Standards-JIG mailing list