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

Re: Comments on bind-08

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 30 Nov 2004 11:15:58 -0800
Message-Id: <4446EDB0-4304-11D9-B57F-000A95B2BB72@osafoundation.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, WebDAV (WebDAV WG) <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

I would say that the absence of text more often causes problems than 
additional text.  We shouldn't let one example scare us.  In fact one 
could argue that we needed *more* text to explain what MOVE was about 
so that people understood what the authors had in mind.


On Nov 30, 2004, at 10:35 AM, Geoffrey M Clemm wrote:

> I agree with Julian.  A new section of text or example can do more
> harm than good (a classic being the "MOVE is logically a COPY/DELETE"
> section from 2518).
> So I think it is a reasonable criteria to require that any proposed
> addition be motivated by at least one example of a misunderstanding
> that may arise with the current text.
> Cheers,
> Geoff
> Julian wrote on 11/30/2004 01:17:15 PM:
>> Lisa Dusseault wrote:
>>>> Jim: I'm OK with adding the paragraph, but what was the possible
>>>> misunderstanding
>>>> that this additional text was intended to clear up?  How else could 
>>>> a
>>>> Depth=infinity
>>>> COPY work?
>>> I agree with Jim that we should add clearer wording here.  The
> ingenuity of
>>> implementors is great, and that includes a surprising ability to come
> to
>>> different conclusions than the writers of a specification.
>> I'd still like to know how it is clearer...
>>>> I agree with Julian.  A version is a new resource created by the
>>>> CHECKIN method.
>>>> According to section 2.6, a new resource must be assigned a new
>>>> resource-id,
>>>> so each new version needs to be assigned a new, distinct 
>>>> resource-id.
>>> Great -- so we agree on what should happen.  As Jim suggests,
>>> let's put it in the spec.
>> Again, before we put additional spec into the spec, it should be clear
>> what problem it solves. I understand that you lean to "more is 
>> better",
>> but please acknowledge that many people writing specs disagree.
>>>>>> * Section 6.2. I think it would be helpful to have an example
> including
>>>>>> REBIND and locks, showing submission of one or more lock tokens in
>>>>>> the If
>>>>>> header.
>>>>> Such as one involving locked source and destination collections?
> That
>>>>> may be useful. What do others think?
>>>> I continue to believe that the right place for locking examples is 
>>>> in
> a
>>>> locking spec, and that the binding spec just needs to make clear
> which
>>>> resources
>>>> and which URL mappings are being modified by an operation, since 
>>>> this
>>>> is all
>>>> you need to know which locks are required.  I believe this
> information is
>>>> well-defined in the pre-conditions of the methods introduced by the
>>>> binding
>>>> spec.  So I'd vote not to add such an example, but I could live with
> it,
>>>> if a majority is for it.
>>> An example with locks and REBIND would be great.  Other examples with
> locks
>>> and bound resources (and requirements about what URL must be
> used/supported
>>> in the requests) would also be great.
>> I'm not sure how locking examples for REBIND are going to help much.
>> REBIND is just like MOVE, except for slightly different marshalling. 
>> I'm
>> not against adding an example per se, but if we do it it should really
>> contain something that's not available elsewhere.
>> Julian
>> -- 
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 30 November 2004 19:18:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC