RE: more bugs in the v5 spec

[Note to quick readers: I make a couple of controversial points below so you
should probably read all the points.]

>8.1.1 example retrieving named properties.  Shouldn't the properties in the
>Propfind header be written as empty tags?

Fixed

>8.1.2  example of allprop.  Shouldn't this return code 207 multistatus, not
>200?

Fixed

>8.13.11 - example of multi-resource lock

>the XML document in the request body is an <d:href> , but it should be
><d:owner>

Fixed.

>in the Addlocks header, the hrefs of the second additional resource should
>be written as an empty tag.  Also, the Addlock header is malformed, it
>should have a colon not an equal sign.

Addlocks have been moved to the body. It had an unbounded size and was
likely to need that space.

>The Timeout header here uses a comma to delimit list elements, but the
>description of timeout header in 9.15 says to use a SP.  The example in
>8.13.10 uses a semi-colon.  Let's pick one.

It says "1#TimeType" which means use a "," not a SP, so 8.13.11 is correct.
However 8.13.10 is wrong and has been fixed.

>9.9 Lock Info request header syntax says that additional locks are passed
>in the header, but this is not what 8.13.11 (multi-resource lock) shows.

>Likewise, is Lock-Tree part of the Lock-Info header?

Actually, addlocks lists two resources to be locked in addition to the
resource in the request-uri. Oh and Lock-Tree is now part of a deep dark pit
of debate. 

In fact I propose we remove addlocks all together, drop lock-tree, and use
the depth header. I don't think we understand the issues of multi-server
locking well enough to implement it. For example, what if I want to lock
resource A and all its children, resource B and all of its children, and
resource C but none of its children? What if I only want resource B locked
if it has a certain entity tag but resource A with a different entity tag?
You can't do any of that currently. You can only test for a single tag and
if it fails so does the whole lock! I think we are out of our depth (all
puns intended), I think we should just drop addlocks.

>13.1 creationdate property.  This says the date and time must be given in
>ISO 8601, and cites it, but it does not appear in the References.  (But
>also, why use ISO 8601 instead of RFC 1123)

The question of RFC 1123 vs ISO 8601 has been addressed recently on the
list, I refer you to those posts. As for the reference, good point. How does
one reference an ISO standard anyway?

>13.13: typo: "he have" should be "he has"

Fixed.

>13.16.  supportedlock property: The Values description has "LockEntry" XML,
>should be "lockentry"

Fixed.

>13.16.4 Example of Propfind should use the Propfind header not the propfind
>XML element, and hence there should be no Content-Length or Content-Type
>headers either.

Actually propfind is back in the body because it has an unlimited size and
is likely to use it.

	As always, we are in your debt,

			Yaron



> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	Tuesday, December 16, 1997 1:19 PM
> To:	w3c-dist-auth@w3.org
> Subject:	more bugs in the v5 spec
> 
> These are all typos and nits.
> 
> 8.1.1 example retrieving named properties.  Shouldn't the properties in
> the
> Propfind header be written as empty tags?
> 
> 8.1.2  example of allprop.  Shouldn't this return code 207 multistatus,
> not
> 200?
> 
> 8.13.11 - example of multi-resource lock
> 
> the XML document in the request body is an <d:href> , but it should be
> <d:owner>
> 
> in the Addlocks header, the hrefs of the second additional resource should
> be written as an empty tag.  Also, the Addlock header is malformed, it
> should have a colon not an equal sign.
> 
> The Timeout header here uses a comma to delimit list elements, but the
> description of timeout header in 9.15 says to use a SP.  The example in
> 8.13.10 uses a semi-colon.  Let's pick one.
> 
> 9.9 Lock Info request header syntax says that additional locks are passed
> in the header, but this is not what 8.13.11 (multi-resource lock) shows.
> 
> Likewise, is Lock-Tree part of the Lock-Info header?
> 
> 13.1 creationdate property.  This says the date and time must be given in
> ISO 8601, and cites it, but it does not appear in the References.  (But
> also, why use ISO 8601 instead of RFC 1123)
> 
> 13.13: typo: "he have" should be "he has"
> 
> 13.16.  supportedlock property: The Values description has "LockEntry"
> XML,
> should be "lockentry"
> 
> 13.16.4 Example of Propfind should use the Propfind header not the
> propfind
> XML element, and hence there should be no Content-Length or Content-Type
> headers either.

Received on Tuesday, 30 December 1997 01:01:05 UTC