Re: Newbie questions

ajk@mds.rmit.edu.au (Alan Kent) wrote:
> 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?

When you do a LOCK on a null resource then a lock-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.

I also find this confusing, and I posted a message in response to Jim
Whitehead's explanation which explains my confusion.  If I get a reply it
may answer both our questions :-)
(see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0285.html)

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

Not _any_ URI, but any URI where the immediate parent collection already
exists.

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

You are as close to understanding it as I am :-)

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

Essentially both.  The lock applies to the resource (you cannot change its
content or dead properties) and to the internal members along the URI path
(you cannot remove or rebind those members i.e. by DELETE or MOVE or COPY)
so that the resource cannot disappear out from under you.

Caveat: I've built my own mental model of how this works because, IMHO,
RFC2518 does a poor job of describing it.  I stand to be corrected ...
better still I'd sit to have it explained clearly to me.

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

See http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html

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

I agree that this text is confusing.  FWIW my rule of thumb is that if the
status code applies _only_ to the resource at the request-URI then 207
Multi Status is not used (i.e. 404 Not Found, 301 Moved Permanently, and so
on).  207 Multi Status is returned when the result applies to the resource
identified by the request-URI and other resources (i.e. depth > 0) *or* the
response applies to any number of properties.

For a discussion of this topic see
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000AprJun/0042.html

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

There is no such definition around to my knowledge.  I also haven't heard
of anyone using a body for MKCOL for their own devious means -- did you
have a plan?

> Q6: Is there any clear definitative list of which properties are "live"
>     properties?

Do you mean in the spec. or in the world in general?
In the spec. it is those properties whose syntax and semantics are enforced
by the server, i.e. all those in Section 13.  In the world there is no such
registry.

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

You are expected not to use the DAV namespace (despite what you might see
in some implementations).

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

Strange isn't it?!  BTW this is explicitly overruled by the bindings
protocol.

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

I believe this is the issue OVERWRITE_DELETE_ALL_TOO_STRONG on the WebDAV
issues list http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

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

That is your choice as a server implementer.  These URLs to a version are
server generated and servers are not obliged to expose "/his/" as a
resource.

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

Agreed.

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

Check out http://www.webdav.org/deltav/ for instructions on subscribing to
the DeltaV list.

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

The questions were clearly written and beautifully formatted :-)
Shame about the answers.


Tim

Received on Tuesday, 19 June 2001 11:54:58 UTC