- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Tue, 30 Nov 2004 11:15:58 -0800
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, WebDAV (WebDAV WG) <w3c-dist-auth@w3.org>
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. lisa 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