headers
Julian Reschke | 1 Dec 2009 14:27
Picon
Picon

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

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?
>>
>> Along the lines: "Client needs to find a working-copy" => link rel 
>> 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>.
> ...

To make things cleared, I have added a short pointer to the Introduction:

"These link relations are used in the AtomPub ([RFC5023]) bindings of 
the "Content Management Interoperability Services" (CMIS). See Section 
3.4.3.1 of [CMIS] for further information." -- 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#introduction>

Best regards, Julian
Permalink | Reply | 0 comments |
headers
Julian Reschke | 1 Dec 2009 15:07
Picon
Picon

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

Jan Algermissen wrote:
> ...
> 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."
> ...

So, substituting "modified" by "used". I'm ok with that.

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

The issue here is that in some systems, checkout will not create a new 
resource, just flip a bit on the versioned resource.

Also, (I think) there are systems where checking in does not create a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jan Algermissen | 2 Dec 2009 07:41
Picon

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

Julian,

On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:

> Jan Algermissen wrote:
>> ...
>> 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."
>> ...
>
> So, substituting "modified" by "used". I'm ok with that.

Fine.

>
>> 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.
>
> The issue here is that in some systems, checkout will not create a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Algermissen | 2 Dec 2009 11:56
Picon

(Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-03

Julian,

what is your opinion regarding the introduction of a link relation  
that is the opposite of working-copy in order to being able to find  
the versioned resource that the working copy I have is a working copy  
of?

I am undecided regarding the necessity, but without a working-copy-of  
relation it seems the client would need to maintain that information  
(the relationship or the fact that a given resource is a working copy)  
across requests.

I do not think this is really I-D publication relevant right now,  
please understand it only as a side comment.

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  
> 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,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Julian Reschke | 2 Dec 2009 16:55
Picon
Picon

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

Asbjørn Ulsberg wrote:
> 
> On Thu, 26 Nov 2009 16:58:37 +0100, Julian Reschke 
> <julian.reschke <at> 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"?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 2 Dec 2009 17:58
Picon
Picon

Re: (Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-03

Jan Algermissen wrote:
> Julian,
> 
> what is your opinion regarding the introduction of a link relation that 
> is the opposite of working-copy in order to being able to find the 
> versioned resource that the working copy I have is a working copy of?
> 
> I am undecided regarding the necessity, but without a working-copy-of 
> relation it seems the client would need to maintain that information 
> (the relationship or the fact that a given resource is a working copy) 
> across requests.
> 
> I do not think this is really I-D publication relevant right now, please 
> understand it only as a side comment.
> ...

I have no problems adding this; the reason it hasn't been proposed was 
that apparently CMIS didn't have a use case for it.

Al, any opinion on this from a CMIS point of view?

Best regards, Julian
Permalink | Reply | 2 comments |
headers
Julian Reschke | 2 Dec 2009 18:59
Picon
Picon

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

Jan Algermissen wrote:
> Julian,
> 
> On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:
> 
>> Jan Algermissen wrote:
>>> ...
>>> 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."
>>> ...
>>
>> So, substituting "modified" by "used". I'm ok with that.
> 
> Fine.
> 
>>
>>> 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.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bakshi | 3 Dec 2009 06:15
Picon

.htaccess prevent right access from webdav

Hello list,

I am facing a strange problem with webdav.  I am running debian lenny
server with apache2

` ` `
Server version: Apache/2.2.9 (Debian)
Server built:   Jul 14 2009 20:44:04
` ` `

with  dav and dav_fs enabled.  webdav is running well and it also
creates and deletes file/folder with out any problem. The problem starts
as soon as I place .htaccess file. webdav can't create/delete
anything!!! It generates error as below from client pc

` ` '
touch 123
touch: cannot touch `123': Input/output error

mkdir 123
mkdir: cannot create directory `123': No such file or directory
 ` ` `

windows client simply throws error as permission denied. My webdav
configuration is

 ` ` `
## webdav access

Alias /webdav/kaushik /var/personal_work_area/kaushik
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Dec 2009 15:17
Picon
Picon

Re: (Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-03

Julian Reschke wrote:
> Jan Algermissen wrote:
>> Julian,
>>
>> what is your opinion regarding the introduction of a link relation 
>> that is the opposite of working-copy in order to being able to find 
>> the versioned resource that the working copy I have is a working copy of?
>>
>> I am undecided regarding the necessity, but without a working-copy-of 
>> relation it seems the client would need to maintain that information 
>> (the relationship or the fact that a given resource is a working copy) 
>> across requests.
>>
>> I do not think this is really I-D publication relevant right now, 
>> please understand it only as a side comment.
>> ...
> 
> I have no problems adding this; the reason it hasn't been proposed was 
> that apparently CMIS didn't have a use case for it.
> 
> Al, any opinion on this from a CMIS point of view?
> ...

OK, I have added working-copy-of, and plan to submit the current draft 
(also including the other changes we discussed) as 
draft-brown-versioning-link-relations-04 later today.

A marked up version with diffs is available at
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>, 
feedback appreciated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Dec 2009 23:03
Picon
Picon

Re: I-D Action:draft-brown-versioning-link-relations-04.txt

(FYI)

Internet-Drafts <at> ietf.org 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-04.txt
> 	Pages           : 14
> 	Date            : 2009-12-04
> 
> 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-04.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
> I-D-Announce <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |

Gmane