- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Tue, 19 Jun 2001 14:13:43 +1000 (EST)
- To: w3c-dist-auth@w3.org
Hi. I am new to this list so I appologise if these are ignorant questions. I have been reading all the WebDAV (and DeltaV) documents I can get my hands on, but have a few issues that I do not understand. Q1: When are null resources created? You can "lock a null resource in order to lock the name". Is it that if you do a lock on a name that does not exist as a resource, a null resource is created? Are there other ways that null resources can be created? The text says you lock a null resource to create a lock-null resource. A lock-null resource has properties and appears under its parent container. A null resource does not appear under its parent. The definition of null resource is that it is a resource that responds to requests, which implies that it exists. My guess is that any URI that is not bound to a resource is implicitly bound to a null resource which has no properties or any other state. When you lock a null resource, a lock-null resource is created allowing it to be placed under its parent container and have properties. Is this correct? Q2: Are locks on resources or URIs identifying resources? The DeltaV documentation I have read I think said that locks are applied to the resources identified by a URL. Q3: The MOVE documentation says that a successful MOVE on a write locked resource must not move the write lock. (It then talks about collections and locks.) If the resource being moved is locked (that is, the resource itself, not the collection it is in), why is the lock removed when the resource is moved? If the lock is applied to a URI, does this mean a lock-null is left for the old URI? If the lock is applied to a resource, why does not the lock stay with the resource that is locked? Or is the text in sectino 7.7 only relating to parent collections that have been locked and has nothing to do with locks directly on resources? Q4: PROPFIND in section 8.1 talks about responses and errors and multistatus XML elements. I have read the text several times but is confusing. It says servers must support returning a multistatus element. (It does not say that it must *always* return one, just that it must support it.) It then says errors must be returned as 404 *if* a multistatus element is returned. etc. It was not clear when a multistatus element must be returned - is it optional or mandatory? Related, how to know when to return multistatus elements in general? Examples of packet communications are given, but no formal request/response packet grammar is given. Q5: MKCOL behaviour with message bodies is not defined in the standard (section 8.3.1) but may be "defined elsewhere". Is there any such defintion around? Or is the body of MKCOL not important for interoperability. Q6: Is there any clear definitative list of which properties are "live" properties? My understanding that any property that is not a live property is a dead property, therefore if I used a property name such as DAV:xyz which is currently not defined, its dead, but later if DAV defines xyz, then it would suddenly become live. I assume the protection here is that I should never use DAV: because its a DAV namespace. Q7: DELETE is defined to delete a non-collection resource, removing all URIs to that resource, not just the URI passed to the DELETE command (section 8.6.1). Other sections such as MOVE and COPY talk about deleting the destination. To me this therefore means that if /foo/a and /bar/a are bound to resource R1, then a COPY with overwrite to /foo/a will delete the URIs /foo/a and /bar/a and resource R1 then create a new resource R2 and only bind /foo/a to the new resource R2. Or should /foo/a and /bar/a both bind to R2? I noticed that DeltaV changes the DELETE semantics relating to versioning. Q8: In DeltaV, versions are given stable URLs such as /his/73/vr/1. Should these URLs be made visible via containers? Ie: should /his be a container, and /his/73, and /his/73/vr? Or are these URLs hidden from containers? My understanding that there is no standard for "/his", its whatever the system chooses. It just seemed a potentially very expensive operation to get a listing of the contents of "/his" as a container since it would contain a child container for *every* versioned resource history resource. A short background - we have a document management system are trying to work out how hard it is to support first DAV and then DeltaV. The document management system uses the DMA versioning model, hence any experiences of relating DeltaV to DMA would also be appreciated - although this is probably the wrong list for DeltaV questions. Thanks for any help people can provide. I relise mail with lots of questions can be a pain, but it was either that or send in lots of separate ones (which I find worse)! Hopefully there are simple answers to the above. Alan Kent
Received on Tuesday, 19 June 2001 00:42:49 UTC