Subject: versioning extension?

From: Jan Algermissen <[email-masked]>
Date: Tue, 12 Sep 2006 00:40:33 +0200

Hi,

is anybody working on (or planning to work on) a versioning extension  
for Atom? I am about to use Atom in two (considerably different)  
projects that require versioning and would be happy to join forces  
and contribute real (enterprise-)world use cases. (Note: not  
'enterprisey' use cases :-)

Jan

---

From: Tim Bray <[email-masked]>
Date: Mon, 11 Sep 2006 16:23:59 -0700

On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote:

> is anybody working on (or planning to work on) a versioning  
> extension for Atom? I am about to use Atom in two (considerably  
> different) projects that require versioning and would be happy to  
> join forces and contribute real (enterprise-)world use cases.  
> (Note: not 'enterprisey' use cases :-)

Eeeeeeeeeeeeeeeeeeeeeeek!  Flee for your lives!  *runs for the  
nearest exit*  -Tim

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 12 Sep 2006 01:39:01 +0200

> Eeeeeeeeeeeeeeeeeeeeeeek!  Flee for your lives!  *runs for the  

Umm...am I missing  something? Is it that bad?

What I am basically aiming at is a common means to relate entries to  
each other to indicate one is a version of the other or to link from  
an entry to a feed that consists of versions of that entry,

If I am not completely wrong, versioning is definitely an issue if  
you want to employ Atom in beyond-blogging contexts. Most people that  
deal with collections of items are definitely interested in keeping  
track of the former versions of the items.

What is so bad about it?

Jan

---

From: Karl Dubost <[email-masked]>
Date: Tue, 12 Sep 2006 09:17:18 +0900

Le 12 sept. 06 à 08:39, Jan Algermissen a écrit :
> What I am basically aiming at is a common means to relate entries  
> to each other to indicate one is a version of the other or to link  
> from an entry to a feed that consists of versions of that entry,
>
> you want to employ Atom in beyond-blogging contexts. Most people  
> that deal with collections of items are definitely interested in  
> keeping track of the former versions of the items.

Are you talking about threading?

Why not putting it outside of Atom and use the power of links for  
threading.
Similar discussion but for comments happened on microformats ML.

So IMHO, it is slightly off-topic, in the sense you could achieve it  
by an application built on top of Atom without touching Atom
AND Tim Bray could come back in the room :p

 From the microformats ML

Le 12 sept. 06 à 08:35, Karl Dubost a écrit :
> Hi Steph,
>
> Le 12 sept. 06 à 07:17, Stephanie Booth (bunny) a écrit :
>> A while back somebody showed me a blog marked up with hatom. That
>> person used hatom on the comments too (on the single post page) --
>> that meant two hfeeds: one containing only the post, and another one
>> with the comments.
>>
>> Does this way of using hatom on comments make sense to you? I noticed
>> that neither K2 nor Sandbox wordpress themes do this.
>
> Completely logical.
>
> Each individual comment is nothing more than a weblog post.
> The only technical difference is that it is not made on another  
> weblog, but directly on the weblog of the person.
>
> Each individual comment is structured like a weblog post.
> It has  (required)
> 	- an id, the URI of the comment
> 	- a title, often the same than the original weblog post, sometimes  
> a different (see SPIP)
> 	- a date when it has been done (updated)
> It has (recommended)
> 	- often an author
> 	- content (core text of the comment)
> 	- link (the URI of the Weblog original post we are commenting on)
>
> It just miss a summary, but that is not mandatory in Atom either.
>
> IMHO, it should be an individual hatom entry for each comment, The  
> way everything is aggregated and organized has a full feed is  
> another debate. The date and link should help to create a pseudo  
> thread.
> It could be a full thread like in SPIP when the commenter has the  
> possibility to reply to a specific comment in this case the link  
> becomes the URI of the specific comment.
>

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

---

From: Tim Bray <[email-masked]>
Date: Mon, 11 Sep 2006 17:20:48 -0700

> keeping track of the former versions of the items.

Versioning is an issue in almost *every* application.

> What is so bad about it?

In my experience, the semantics of "versioning" are so tightly bound  
to particular applications that it's really hard to find common  
threads.  You saw that happen here when we were arguing about  
atom:updated, Asbjørn had a particular vision of versions that seemed  
obvious to him and unreasonable to others.  When a textbook publisher  
and a medical-instrument embedded-software maker and a wiki  
implementor use the word "version", I guarantee you they mean  
entirely different and wildly incompatible things.

Good luck; you'll need it. -Tim

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 12 Sep 2006 10:51:00 +0200

Karl,

>Are you talking about threading?

I did consider re-using threading, but thought the semantics are really to different. OTH, I did not take an in depth look, so maybe there is an entry-to-entry relationship that can be re-used.

>Why not putting it outside of Atom and use the power of links for  

I really did not have a modification to atom in mind (maybe I used the name 'extension' improperly). I was only looking for a relatively standardized way to link items to derived items or vice versa.

BTW: Can the cotent of an atom enry contain or link to an atom feed document?

Thanks.

Jan

>> becomes the URI of the specific comment.

------------------------------------------------------------
Jan Algermissen                                               http://jalgermissen.com
Software Architect                                            http://www.tugboat.de

---

From: Andreas Sewe <[email-masked]>
Date: Tue, 12 Sep 2006 11:52:02 +0200

Jan Algermissen wrote:
> projects that require versioning and would be happy to join forces and 
> contribute real (enterprise-)world use cases. (Note: not 'enterprisey' 
> use cases :-)

Maybe dcterms:isVersionOf and dcterms:hasVersion fit your bill [1]. 
Granted, their definition is rather loose (as most of Dublincore's 
definition are -- by design), but that only means that those terms might 
work in both of your use cases. If so, using an established metadata 
vocabulary like Dublincore is definitely worth considering.

I hope that helps,

Andreas Sewe

[1] <http://dublincore.org/documents/dcmi-terms/#H3>

---

From: "Thomas Broyer" <[email-masked]>
Date: Tue, 12 Sep 2006 11:44:58 +0200

> 'enterprisey' use cases :-)

Have you looked at this?
http://tools.ietf.org/wg/atompub/draft-snell-atompub-revision-00.txt

-- 
Thomas Broyer

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 12 Sep 2006 22:25:07 +0200

> http://tools.ietf.org/wg/atompub/draft-snell-atompub-revision-00.txt

James

quick question about your draft:

You write:

------------------------------------------------------------------------ 
-------------------------
13.  The 'next-revision' Link Relation

    Atom entry elements MAY contain an atom:link element with a rel
    attribute value of 'next-revision' whose href attribute specifies  
the
    URI of an Atom Entry Document representing the subsequent version of
    the entry.
------------------------------------------------------------------------ 
-------------------------

Is there an intention behind the use of the phrase '*the* subsequent  
version' to rule out version trees (where next-revision would point  
to *a* subsequent revision of potentially many)?

Thanks,
Jan

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Sep 2006 14:52:17 -0700

Hey Jan,

No, the text should read "a subsequent version".

Also, keep in mind that this draft was put out there for purely
experimental purposes.  It hasn't been updated and likely won't be
unless there is significant interest.

- James

Jan Algermissen wrote:
> [snip]
> -------------------------------------------------------------------------------------------------
> 
>    attribute value of 'next-revision' whose href attribute specifies the
> -------------------------------------------------------------------------------------------------
> 
> 
> version' to rule out version trees (where next-revision would point to
> *a* subsequent revision of potentially many)?
> 
> Thanks,
> Jan
> 
> 
> 
> 
> 
>>
>> --Thomas Broyer
>>
> 
>

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 13 Sep 2006 13:13:55 -0700

On Sep 11, 2006, at 5:20 PM, Tim Bray wrote:

> In my experience, the semantics of "versioning" are so tightly  
> bound to particular applications that it's really hard to find  
> common threads.  You saw that happen here when we were arguing  
> about atom:updated, Asbjørn had a particular vision of versions  
> that seemed obvious to him and unreasonable to others.  When a  
> textbook publisher and a medical-instrument embedded-software maker  
> and a wiki implementor use the word "version", I guarantee you they  
> mean entirely different and wildly incompatible things.
>

I concur with the word of warning (which shouldn't be construed as  
anything more than an individual offering up their experience for  
what that's worth).  Check out RFC3253, DeltaV -- in order to get  
anything published, it had to have a ton of optional features which  
makes it difficult to write general DeltaV clients that interoperate  
against multiple servers.  I haven't heard of any such clients yet!

Lisa

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 13 Sep 2006 23:50:02 +0200

Lisa,

On 13.09.2006, at 22:13, Lisa Dusseault wrote:

> makes it difficult to write general DeltaV clients that  
> interoperate against multiple servers.  I haven't heard of any such  
> clients yet.

Yes, I see. OTH, I am not looking for an extension that is directed  
towards providing a versioning repository to Atom clients, but merely  
for a way for an atom server to communicate that versions exist.

I think from the client interaction POV, versioning should be  
transparent. If the server creates a new version upon an update (or  
redirects the PUT in the first place) should not be of concern to the  
client.

But telling the client that there *are* versions of an entry  
available seems rather straightforward (see James' draft)

Jan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Sep 2006 08:31:14 +0200

Lisa Dusseault schrieb:
> anything more than an individual offering up their experience for what 
> that's worth).  Check out RFC3253, DeltaV -- in order to get anything 
> published, it had to have a ton of optional features which makes it 
> difficult to write general DeltaV clients that interoperate against 
> multiple servers.  I haven't heard of any such clients yet!

Well, DeltaV also defines a simple core module, and, as far as I can 
tell, this is completely interoperable between clients that support it 
(Xythos, SAP KM), and servers that advertise RFC3253 support (again: SAP 
KM and Xythos, and also Slide).

Best regards, Julian