- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 Dec 2009 16:55:19 +0100
- To: Asbjørn Ulsberg <list@asbjorn.ulsberg.no>
- CC: Sam Johnston <samj@samj.net>, Jan Algermissen <algermissen1971@mac.com>, Atom-syntax Syntax' <atom-syntax@imc.org>, WebDAV <w3c-dist-auth@w3.org>
Asbjørn Ulsberg wrote: > > On Thu, 26 Nov 2009 16:58:37 +0100, Julian Reschke > <julian.reschke@gmx.de> wrote: > >> Sam Johnston wrote: >> >>> * 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. > > As long as the words "previous", "next" and "last" aren't used, there's > no collision. "predecessor" and "successor" are pretty unambiguous and > don't collide with any existing link relations that I'm aware of. Also, They do not collide with link relations, but they aren't unambiguous either. For instance, <http://www.imdb.com/title/tt0071562/> is the successor of <http://www.imdb.com/title/tt0068646/>, but it's not a successor version. > in this context (talking about documents) what else than "an earlier > version" might you refer to when pointing to a "predecessor"? > > In other words; I agree with Sam. I think the shorter and more concise > relations are better. Either use words that don't imply "version" (like > "previous" and "next") and suffix them with "-version" or use words that > unambiguously refer to "versions" and have no suffix, but not a mix of > both. Not convinced. I'll leave this to the expert review and the IESG. >>> 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. > > I think such problems are important to explore, since this I-D is > something these SCM's might want to implement. I agree that it's an interesting problem, but just because something is interesting doesn't mean it needs to be solved in this proposal. At this point, I'd rather take out things than add new things. Best regards, Julian
Received on Wednesday, 2 December 2009 15:56:07 UTC