Newbie questions

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