Subject: last-calling I-D Action:draft-brown-versioning-link-relations-03

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 15:13:46 +0100

(FYI)

This update to yesterday's draft is purely editorial, moving each link 
relation into a proper subsection, and using the correct IANA 
registration template as defined per RFC 4287.

At this point we'd like to ask the community for final feedback; we are 
planning to request publication in two weeks from now (Dec 04).

Best regards,

Julian

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Link Relations for Simple Version Navigation
> 	Author(s)       : A. Brown, et al.
> 	Filename        : draft-brown-versioning-link-relations-03.txt
> 	Pages           : 11
> 	Date            : 2009-11-20
> 
> This specification defines Atom link relations for navigation between
> a resource and its versions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 15:13:46 +0100

(FYI)

Best regards,

Julian

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 24 Nov 2009 09:04:57 +0100

Julian,

some comments on the link relation draft:

2. Terminology

It is not clear to me, what the meaning of 'check out' and 'check in'.  
Also, the text (IMO) creates the impression that versioning can only  
take place when 'check out' and 'check in' are applied. However, a  
resource could also be versioned by the server upon any modification  
made by a client regardless of any 'checking out' or 'checking in'.  
The link relations specified would still make sense.

Assuming that 'checking out' and 'checking in' are operations on  
resources, I think the draft should address how clients achieve these  
operations. This would at least involve another link relation and  
specification how to use the linked resource to perform a checkout.

Or am I misunderstanding what the draft is trying to do?

Appendix A

It should be 'working-copy' instead of 'working-resource'.

I am glad to see this happening. Covers a lot of stuff that comes up  
in almost every project. Thanks.

Jan

On Nov 20, 2009, at 3:13 PM, Julian Reschke wrote:

>
> (FYI)
>
> This update to yesterday's draft is purely editorial, moving each  
> link relation into a proper subsection, and using the correct IANA  
> At this point we'd like to ask the community for final feedback; we  
> are planning to request publication in two weeks from now (Dec 04).
>
> Best regards,
>
> Julian
>
>

--------------------------------------
Jan Algermissen

Mail: [email-masked]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Nov 2009 11:54:42 +0100

Hi Jan,

first of all thanks for the feedback!

> It is not clear to me, what the meaning of 'check out' and 'check in'. 

Yes, we need to add text here. We originally started with the 
definitions with RFC 3253 (WebDAV versioning), but later on decided 
later on to just rely on generic definitions to make this work better 
with CMIS and JCR.

> made by a client regardless of any 'checking out' or 'checking in'. The 
> link relations specified would still make sense.

Indeed; and that's something that can even happen in WebDAV versioning 
(through the various modes of auto-versioning).

> specification how to use the linked resource to perform a checkout.

These kinds of operations are specific to the protocol in which they are 
used, while the link relations are meant to be generic; thus I'd avoid 
to go that way.

For now, I've added this to the issues list: 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out>. 
I'll try to make a change proposal soonish.

> It should be 'working-copy' instead of 'working-resource'.

Indeed. Thanks for catching this.

> I am glad to see this happening. Covers a lot of stuff that comes up in 
> almost every project. Thanks.

That's good to hear, because defining generic link relations doesn't 
make sense unless there are generic use cases for them :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Nov 2009 11:54:42 +0100

Hi Jan,

Best regards, Julian

---

From: Sam Johnston <[email-masked]>
Date: Tue, 24 Nov 2009 16:14:53 +0100

Julian et al,

It's probably worth taking a look at
draft-johnston-addressing-link-relations<http://tools.ietf.org/html/draft-johnston-addressing-link-relations-00>as
well as it defines both "current" and "latest" as well as "canonical",
"immutable", "mirror", "permalink" and my favourite, "shortlink". This has
been adopted by Wordpress, Drupal & others with a view to bringing an end to
third-party URL shortening services (the rust of the Internet).

While I support link relations for versioning, I'd prefer to see relations
for generic addressing requirements consolidated in one draft.

Sam

A New Internet-Draft is available from the on-line Internet-Drafts
> directories.

>         Title           : Link Relations for Addressing

        Author(s)       : S. Johnston

        Filename        : draft-johnston-addressing-link-relations-00.txt

        Pages           : 7

        Date            : 2009-09-20

> This specification defines link relations for a number of common

styles of resource addressing (for example, linking to the latest vs

a specific version of a resource).

> A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-johnston-addressing-link-relations-00.txt

Internet-Draft.

<
> ftp://ftp.ietf.org/internet-drafts/draft-johnston-addressing-link-relations-00.txt
> >

canonical  Designates the preferred or standard way of writing the
    URL, or the "canonical form" (also known as "standard form" or
    "normal form").  While there can be an infinite number of
    references to identical or vastly similar resources (for example
    with different sort orders, highlighting or category information),
    specifying which one is "canonical" allows automated agents to
    avoid treating every such URL as unique.  Search engines may use
    this to consolidate properties such as link popularity and display
    the preferred URL in search results, while other clients may
    identify, save and share the preferred version rather than the one
    they originally retrieved.

 current  Identifies resource(s) which are occuring in or belonging to
    the present time, but may not necessarily be the single most
    recent or "latest" version specifically.  For example an entry or
    page of a feed may identify the most recent entries in that feed
    using the "current" relation.

 immutable  Refers to an immutable version of the link's context that
    is not subject or susceptible to change or variation.  This may
    refer to a read-only resource, an archived copy of an otherwise
    dynamic resource, a specific version in a version control system,
    etc.  This is in contrast to links which return the latest version
    of the resource at any given time.

 latest  Refers to the single most recent version of the link's
    context, which may be updated at any time.  As most URLs return
    the most recent version of the resource this relation is most
    useful with version control systems.  For example, older versions
    of the resource may refer to the latest version.

mirror  Provides a rudimentary facility to specify one or more
   identical mirrors from which clients can obtain a resource.  For
   example a large enclosure may be available for download from a
   number of different servers in different geographical locations in
   order to distribute server load, reduce network load and improve
   availability and performance.  Link extensions for indicating
   geographical location, slots, bandwidth, preference, etc. may be
   defined in a future Internet-Draft.

permalink  Designates an immutable URL which is not subject or
   susceptible to change or variation even if the resource itself is
   updated.  A portmanteau of "permanent" and "link", the relation
   allows clients to save and share a URL with the guarantee that it
   will resolve to that resource so long as it still exists.
   Typically the more information that is included in a link the more
   volatile it is likely to be.  For example a link to a blog post
   that includes the title may change whenever the title is updated.
   Where "permalink" is specified such changes must not cause the
   designated URL to stop resolving or to resolve to another
   resource.

   Note: It is inappropriate to use the "bookmark" relation for this
   as it is "used to provide direct links to key entry points into an
   extended document" rather than as a reference to the resource
   itself.

shortlink  Designates one or more short link(s) which may be used in
   artificially (e.g. microblogging) or technically (e.g. short
   message service) constrained channels, or anywhere humans are
   required to transcribe a link (e.g. print, television and radio).
   This obviates the need to resort to third-party URL shortening
   services by allowing webmasters to centrally specify preferred
   short link(s) for use by all clients.  For performance and
   security reasons the domain should match that of the canonical
   URL, unless a shorter domain is required/desired.  Where more than
   one is specified the client may select one at random, offer the
   choice to the user, select the first, last or shortest one at
   random, or intelligently determine which is the most suitable for
   the purpose (for example, one with an alphabetical rather than
   numerical path).

On Tue, Nov 24, 2009 at 11:54 AM, Julian Reschke <[email-masked]>wrote:

> Yes, we need to add text here. We originally started with the definitions
> with RFC 3253 (WebDAV versioning), but later on decided later on to just
> rely on generic definitions to make this work better with CMIS and JCR.
>
>
>  Also, the text (IMO) creates the impression that versioning can only take
>> place when 'check out' and 'check in' are applied. However, a resource could
>> also be versioned by the server upon any modification made by a client
>> regardless of any 'checking out' or 'checking in'. The link relations
>> specified would still make sense.
>>
>
> used, while the link relations are meant to be generic; thus I'd avoid to go
> that way.
>
> For now, I've added this to the issues list: <
> http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out>.
> That's good to hear, because defining generic link relations doesn't make
> sense unless there are generic use cases for them :-)
>
> Best regards, Julian
>
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 14:29:40 +0100

Jan,

here's my proposal for the checkin/checkout issue you raised (see 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out>):

1) Do not specify *how* to checkin/checkout; this really depends on the 
protocol, and might not be the same for different AtomPub stacks (and 
definitively not for WebDAV). However, the link relations that we do 
defined are supposed to be general-purpose, and to be usable outside the 
Atom space (in-line with Mark's "Web Linking" proposal).

2) For the definition of checkin/checkout and the point you raised, how 
about changing the explanation of "versioned resource" from:

"When a resource is put under version control, it becomes a "versioned 
resource". A versioned resource can be "checked out" to allow modification."

to

"When a resource is put under version control, it becomes a "versioned 
resource". Many servers protect versioned resources from modifications 
by considering them "checked in", and by requiring a "checkout" 
operation before modification, and a "checkin" operation to go back to 
the "checked-in" state. Other servers allow modification, in which case 
the checkout/checkin operation may happen implicitly."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 14:29:40 +0100

Jan,

to

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 16:23:36 +0100

On Nov 26, 2009, at 2:29 PM, Julian Reschke wrote:

> Jan,
>
> here's my proposal for the checkin/checkout issue you raised (see <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out 
> >):
>
> 1) Do not specify *how* to checkin/checkout; this really depends on  
> the protocol, and might not be the same for different AtomPub stacks  
> (and definitively not for WebDAV). However, the link relations that  
> we do defined are supposed to be general-purpose, and to be usable  
> outside the Atom space (in-line with Mark's "Web Linking" proposal).
>
> 2) For the definition of checkin/checkout and the point you raised,  
> how about changing the explanation of "versioned resource" from:
>
> "When a resource is put under version control, it becomes a  
> "versioned resource". A versioned resource can be "checked out" to  
> allow modification."
>
> to
>
> "When a resource is put under version control, it becomes a  
> "versioned resource". Many servers protect versioned resources from  
> modifications by considering them "checked in", and by requiring a  
> "checkout" operation before modification, and a "checkin" operation  
> to go back to the "checked-in" state. Other servers allow  
> modification, in which case the checkout/checkin operation may  
> happen implicitly."
>

(Sorry if this is confusing matters, but...)
I am not sure that the notion of a 'versioned resource' is necessary  
at all. If the draft defined 'version' instead the whole checkin/ 
checkout notion could be dropped.

'Working Copy' could be defined separately as a resource that is an  
'private copy' of a resource, one whose URI is not made available to  
any client except upon initial creation (sorry that this is so  
imprecise - I hope you get the idea).

IWO, the draft somehow circles around the checkin/checkout operations  
and I am not sure that is necessary.

(But if this sounds completely insane, just ignore it)

Jan

>> later on to just rely on generic definitions to make this work  
>> better with CMIS and JCR.
>>> Also, the text (IMO) creates the impression that versioning can  
>>> only take place when 'check out' and 'check in' are applied.  
>>> However, a resource could also be versioned by the server upon any  
>>> modification made by a client regardless of any 'checking out' or  
>>> 'checking in'. The link relations specified would still make sense.
>> Indeed; and that's something that can even happen in WebDAV  
>> versioning (through the various modes of auto-versioning).
>>> resources, I think the draft should address how clients achieve  
>>> these operations. This would at least involve another link  
>>> relation and specification how to use the linked resource to  
>>> perform a checkout.
>> These kinds of operations are specific to the protocol in which  
>> they are used, while the link relations are meant to be generic;  
>> thus I'd avoid to go that way.
>> For now, I've added this to the issues list: <http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out 
>> >. I'll try to make a change proposal soonish.
>>> I am glad to see this happening. Covers a lot of stuff that comes  
>>> up in almost every project. Thanks.
>> That's good to hear, because defining generic link relations  
>> doesn't make sense unless there are generic use cases for them :-)
>> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:26:51 +0100

Jan Algermissen wrote:
> I am not sure that the notion of a 'versioned resource' is necessary at 
> all. If the draft defined 'version' instead the whole checkin/checkout 
> notion could be dropped.

The reason for making the distinction is that in many systems, versions 
and versionable resources are different things (for instance, in JCR and 
WebDAV).

> 'private copy' of a resource, one whose URI is not made available to any 
> client except upon initial creation (sorry that this is so imprecise - I 
> hope you get the idea).

The URI of a working copy may not be private at all.

...it's really to hard to come up with terminology that is compatible 
with many different system.

> (But if this sounds completely insane, just ignore it)

No, I'm listening; and hoping for more feedback...

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:30:28 +0100

Sam Johnston wrote:
> draft-johnston-addressing-link-relations 
> <http://tools.ietf.org/html/draft-johnston-addressing-link-relations-00> 
> as well as it defines both "current" and "latest" as well as 
> "canonical", "immutable", "mirror", "permalink" and my favourite, 
> "shortlink". This has been adopted by Wordpress, Drupal & others with a 
> view to bringing an end to third-party URL shortening services (the rust 
> of the Internet).
> 
> While I support link relations for versioning, I'd prefer to see 
> relations for generic addressing requirements consolidated in one draft.
> 
> Sam
> ...

Hi Sam,

I'm not convinced that throwing everything into a single document will 
be helpful; draft-brown-versioning-link-relations tries to focus on a 
small set of things, and, as Jan's feedback shows, it's non-trivial to 
get even those things right.

Do you have any *specific* comments with respect to the relations that 
it proposes?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:30:28 +0100

Hi Sam,

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:26:51 +0100

BR, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 16:43:23 +0100

On Nov 26, 2009, at 4:26 PM, Julian Reschke wrote:

>> I am not sure that the notion of a 'versioned resource' is  
>> necessary at all. If the draft defined 'version' instead the whole  
>> checkin/checkout notion could be dropped.
>
> The reason for making the distinction is that in many systems,  
> versions and versionable resources are different things (for  
> instance, in JCR and WebDAV).
>
>> 'private copy' of a resource, one whose URI is not made available  
>> to any client except upon initial creation (sorry that this is so  
> ...it's really to hard to come up with terminology that is  
> compatible with many different system.

Do you have a (rough) set of use cases (IOW: client goals) that are to  
be enabled by the link relations?

Along the lines: "Client needs to find a working-copy" => link rel  
working-copy enables that

I have come to approach "hypermedia semantics" (media types, link  
relations, etc.) in terms of the goals they enable. Turning this  
around would mean: if something does not support a specific (probably  
very tiny) goal it should not be there.

Yes, versions and versionable resources can be different but is the  
distinction necessary for enabling the goals of the draft?

Stressing the point for analysis purposes:

"There is nothing a client cannot do when it does not understand the  
notion of 'versioned resource'".

Jan

>
>> IWO, the draft somehow circles around the checkin/checkout  
>> operations and I am not sure that is necessary.

---

From: Sam Johnston <[email-masked]>
Date: Thu, 26 Nov 2009 16:38:14 +0100

On Thu, Nov 26, 2009 at 4:30 PM, Julian Reschke <[email-masked]>wrote:

> Hi Sam,
>
> I'm not convinced that throwing everything into a single document will be
> helpful; draft-brown-versioning-link-relations tries to focus on a small set
> of things, and, as Jan's feedback shows, it's non-trivial to get even those
> things right.
>

I'm not suggesting throwing everything in one document - just keeping
addressing (permalinks, shortlinks, etc.) separate from versioning. It may
well make more sense to drop relations from
draft-johnston-addressing-link-relations if they are more about versioning
than addressing.

> Do you have any *specific* comments with respect to the relations that it
> proposes?

My first thoughts were that the relations themselves could be more concise:

   - version-history -> versions, history or revisions
   - latest-version -> latest
   - working-copy -> ok
   - predecessor-version -> predecessor or previous-version or prev-version
   (which is it, prev or previous - I think there's some ambiguity here)
   - successor-version -> successor or next-version

I also wonder whether it makes sense to offer links to "native" revision
control (e.g. hg, git, svn, etc.) and/or web interfaces to them - and then
specifics like branches and tags, and what a URI/URL to a branch/tag would
even look like.

Sam

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 16:43:23 +0100

Jan

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:51:19 +0100

> working-copy enables that

These use cases mainly come from CMIS (content management over AtomPub); 
and the main reason these aren't mentioned in the spec is that we wanted 
to avoid a circular spec reference.

See <http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html>.

An alternative would be not to use the terminology around 
checkin/checkout at all. I'll give that a try.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:58:37 +0100

Sam Johnston wrote:
> On Thu, Nov 26, 2009 at 4:30 PM, Julian Reschke <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Sam,
> 
>     I'm not convinced that throwing everything into a single document
>     will be helpful; draft-brown-versioning-link-relations tries to
>     focus on a small set of things, and, as Jan's feedback shows, it's
>     non-trivial to get even those things right.
> 
> 
> addressing (permalinks, shortlinks, etc.) separate from versioning. It 
> may well make more sense to drop relations from 
> draft-johnston-addressing-link-relations if they are more about 
> versioning than addressing.

OK, thanks for clarifying.

>     Do you have any *specific* comments with respect to the relations
>     that it proposes?
> 
> 

I don't think that it's essential to make these short names even 
shorter. The terms we currently use are in sync with some specs related 
to versioning.

>     * version-history -> versions, history or revisions
>     * latest-version -> latest
>     * working-copy -> ok
>     * predecessor-version -> predecessor or previous-version or
>       prev-version (which is it, prev or previous - I think there's some
>       ambiguity here)
>     * successor-version -> successor or next-version

I think the suffix "-version" is important because there can be many 
other similar relations providing "prex/next/last", which have nothing 
to do with versioning.

> control (e.g. hg, git, svn, etc.) and/or web interfaces to them - and 
> then specifics like branches and tags, and what a URI/URL to a 
> branch/tag would even look like.

That's an interesting thought, but appears to be a much more complex 
problem that the one we wanted to solve here.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:51:19 +0100

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 16:58:37 +0100

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:08:14 +0100

On Nov 26, 2009, at 4:51 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> Do you have a (rough) set of use cases (IOW: client goals) that are  
>> to be enabled by the link relations?
> These use cases mainly come from CMIS (content management over  
> AtomPub); and the main reason these aren't mentioned in the spec is  
> that we wanted to avoid a circular spec reference.
>
> See <http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html 
> >.
>
>> ...
>
> An alternative would be not to use the terminology around checkin/ 
> checkout at all. I'll give that a try.

Reading your reference, I think that the important semantic is that  
updating a working-copy does not produce a version, IOW, that, in  
order to create a new version from a working-draft the draft must be  
checked in. Hence, the notion of check-in is definitely necessary.

The actual operation is othogonal (could be a CHECK-IN method or a  
standard HTTP 1.1 request to a resource that has the appropriate  
semantics) but the general notion is fundamental to the idea of a  
working-copy.

check-out I think could be dropped because when I know that something  
is a working-copy it is by definition checked out.
... well then, the notion of check-in implies the notion of check-out,  
so both are a vital part in the end.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:08:14 +0100

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:21:46 +0100

> When a resource is put under version control, it becomes a  
> modification and perfrom versioning without requiring an explicit  
> checkout operation.

I feel there should be the notion of 'modification of checked-out  
working copy' in there but I don't mean to say that your above wording  
isn't suitable also.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:25:06 +0100

>> modification, in which case the checkout/checkin operation may  

Forgot to insert:

What about:

> working copy' in there but I don't mean to say that your above  
> wording isn't suitable also.
>
> Jan
>

Sorry,
Jan

>>> definitions with RFC 3253 (WebDAV versioning), but later on  
>>> decided later on to just rely on generic definitions to make this  
>>> work better with CMIS and JCR.
>>>> However, a resource could also be versioned by the server upon  
>>>> any modification made by a client regardless of any 'checking  
>>>> out' or 'checking in'. The link relations specified would still  
>>>> make sense.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 17:30:59 +0100

Jan Algermissen wrote:
>> the "checked-in" state. Other servers allow modification, in which 
>> case the checkout/checkin operation may happen implicitly."
>>
> 
>> When a resource is put under version control, it becomes a "versioned 
>> the "checked-in" state. Other servers allow modification and perfrom 
>> versioning without requiring an explicit checkout operation.
> 
> 

For now I have applied my change proposal in 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#rfc.section.2>, 
but that doesn't mean we can't spend some more time with wordsmithing :-)

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Nov 2009 17:30:59 +0100

BR, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:21:46 +0100

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Nov 2009 17:25:06 +0100

Forgot to insert:

Sorry,
Jan

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Nov 2009 15:56:14 +0100

Jan Algermissen wrote:
>>> resource". Many servers protect versioned resources from 

Hi Jan,

if I understand you correctly you say that the proposed text explaining 
checkin/checkout should mention that it applies to modifying the working 
copy. I believe that's correct, but would require a forward reference to 
the term "working copy" that I'd like to avoid. (If you meant to say 
something else, please clarify).

With respect to replacing

"Other servers allow modification, in which case the checkout/checkin 
operation may happen implicitly."

by

"Other servers allow modification and perform versioning without 
requiring an explicit checkout operation."

...: this really seems to be equivalent; any particular reason why you 
feel your text is clearer?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Nov 2009 15:56:14 +0100

Hi Jan,

by

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 27 Nov 2009 18:13:27 +0100

Julian,

On Nov 27, 2009, at 3:56 PM, Julian Reschke wrote:

>>>> "versioned resource". Many servers protect versioned resources  
>>>> from modifications by considering them "checked in", and by  
>>>> requiring a "checkout" operation before modification, and a  
>>>> "checkin" operation to go back to the "checked-in" state. Other  
>>>> servers allow modification and perfrom versioning without  
>>>> requiring an explicit checkout operation.
>>>
>>>
> if I understand you correctly you say that the proposed text  
> explaining checkin/checkout should mention that it applies to  
> modifying the working copy.

What I tried to say is that the notion of working-copy goes hand in  
hand with the notion of checking out. Or, to view it from a different  
angle: when a server is versioning, it can do so either implicitly (on  
its own) upon a modification of the resource that is being versioned  
by the server or it can require the user to do it explicitly by  
cheking out->working copy->update working copy->check-in. Without a  
notion of check-in the working-copy notion is useless because it will  
never lead to a new version.

> I believe that's correct, but would require a forward reference to  

I think the notion of versioning is orthogonal to the notion of  
checkout/checkin and the draft seems to be centered around it. If a  
resource is being versioned by the server, all relations make sense,  
except working-copy. Only for working-copy you need to introduce  
checkin/checkout. It is just another means putting the versioning  
'action' in the hands of the client.

(But please takte this only as input - the draft just triggered an  
analysis process and that keeps going :-)
I cannot judge if it is significant enough to justify work on the  
draft or even this exchange...

> "Other servers allow modification, in which case the checkout/ 
> checkin operation may happen implicitly."
>
> by
>
> ...: this really seems to be equivalent; any particular reason why  
> you feel your text is clearer?
>

The latter IMHO takes the focus away from checkin/checkout which I see  
as an absolute edge-case (being non DAV and
non CMIS biased :-)

But then....word smithing I guess.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 27 Nov 2009 18:13:27 +0100

Julian,

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 28 Nov 2009 09:29:26 +0100

On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:

>
> Note that versioning servers without working copies often still  
> require a checkout/checkin protocol.
> The "checkout" method is used as a notification to other users that  
> this client is working on that resource.
> The "checkin" method is used to tell the server "I want you to  
> create a new version with the current content" (while a PUT just  
> updates the current content without creating a new version).

In this case, checkout/checkin is also orthogonal to the notion of  
versioning and would not need to be mentioned in the spec. IOW, the  
only reason mentioning checkin/checkout in the spec is because the  
definition of working copy depends on it.

Jan

>
> Cheers,
> Geoff
>
> Jan Algermissen wrote on 11/27/2009 12:13:27 PM:
>
> ...

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 28 Nov 2009 09:29:26 +0100

Jan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Nov 2009 13:02:53 +0100

Jan Algermissen wrote:
>> The "checkin" method is used to tell the server "I want you to create 
>> a new version with the current content" (while a PUT just updates the 
>> current content without creating a new version).
> 
> versioning and would not need to be mentioned in the spec. IOW, the only 
> reason mentioning checkin/checkout in the spec is because the definition 
> of working copy depends on it.
> ...

Does it?

"A "working copy" is a resource at a server-defined URL that can be 
modified to create a new version of a versioned resource."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Nov 2009 13:02:53 +0100

Does it?

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 30 Nov 2009 13:56:57 +0100

On Nov 30, 2009, at 1:02 PM, Julian Reschke wrote:

>>> The "checkout" method is used as a notification to other users  
>>> that this client is working on that resource.

So it might be enough to:

PUT /working-copies/667

<foo/>

to create a new version of /main/667 ?? (assuming that /main/667 -- 
working-copy--> /working-copies/667)

What would be the reason to have a working copy that needs not be  
checked-in?

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 30 Nov 2009 13:56:57 +0100

PUT /working-copies/667

<foo/>

Jan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Nov 2009 17:06:44 +0100

Jan Algermissen wrote:
> to create a new version of /main/667 ?? (assuming that /main/667 
> --working-copy--> /working-copies/667)
> 

That's not what I intended to say; I was just pointing out that the 
current definition in the spec does not refer to checkin/checkout (maybe 
it should?).

BR, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 30 Nov 2009 11:19:16 -0500

Many (possibly, most) versioning servers provide the ability for a client 
to store on the server working drafts of the working resource, before 
committing it as a publicly visible next version.  So a PUT to the working 
resource just updates the content of the (private) working resource.  A 
separate operation (checkin) commits the current content (or the content 
included with the CHECKIN operation).

Cheers,
Geoff

Jan Algermissen <[email-masked]> wrote on 11/30/2009 07:56:57 AM:
> Geoffrey M Clemm, "Atom-syntax Syntax'", WebDAV, w3c-dist-auth-request
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Nov 2009 17:06:44 +0100

BR, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 30 Nov 2009 17:28:12 +0100

On Nov 30, 2009, at 5:06 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>>> Does it?
>>>
>>> "A "working copy" is a resource at a server-defined URL that can  
>>> be modified to create a new version of a versioned resource."
>>>
> current definition in the spec does not refer to checkin/checkout  
> (maybe it should?).

Hmm, I think so. The definition in a sense implies that the version is  
created as a result of the modification. Which is IMHO *never* the  
case for working copies.

Surely the draft must define 'working copy'. What is the nature of a  
working copy? What is its true nature? I think: being *used* for  
creating new versions. So, what about:

>>> "A "working copy" is a resource at a server-defined URL that can  
>>> be *used* to create a new version of a versioned resource."

and remove checkout/checkin completely. ('use' instead of 'modify'  
sounds less like "The modification cause the versioning" (which it  
never does by nature of a working copy (IMHO - s.a.))

If the draft wanted to define it, then it woud be something like:

checkout: an operation on a resource that creates a working copy
checkin: an operation on a working copy that creates a new version of  
its corresponding versioned resource.

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 30 Nov 2009 17:28:12 +0100

Jan

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 30 Nov 2009 11:19:16 -0500

Cheers,
Geoff