W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2009

Re: Comments on Action:draft-brown-versioning-link-relations-03

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 26 Nov 2009 16:58:37 +0100
Message-ID: <4B0EA5AD.2090709@gmx.de>
To: Sam Johnston <samj@samj.net>
CC: Jan Algermissen <algermissen1971@mac.com>, Atom-syntax Syntax' <atom-syntax@imc.org>, WebDAV <w3c-dist-auth@w3.org>
Sam Johnston wrote:
> On Thu, Nov 26, 2009 at 4:30 PM, Julian Reschke <julian.reschke@gmx.de 
> <mailto:julian.reschke@gmx.de>> 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.

OK, thanks for clarifying.

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

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.

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

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
Received on Thursday, 26 November 2009 15:59:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:38 UTC