Re: DAV locking question

Ben Collins-Sussman wrote:
> ...
> That just doesn't make sense to me or cmpilato.

I agree that it doesn't make sense to design a feature that way.
However, RFC2518 has been vague about it, and clients *do* expect
servers to behave that way, simply for the reason that Microsoft IIS and
Apache/moddav *do* behave like that. There's little we can do about that
today.

> It seems totally wrong for a client to use the <DAV:owner> as a place to
> store attributes and private namespaces that apply to the tag's
> contents. Clients that do this are placing a ridiculous burden on DAV
> servers, no? If the client demands that the server preserve these
> namespaces outside of the content, then the server should be able to
> "push" the namespaces down into the content when convenient. But then
> on the other hand, the server is supposed to treat the content
> opaquely... so it can't assume the content is XML.

The content *by definition* is XML (or more precisely an XML fragment).

> What if the <DAV:owner> content is using namespaces defined 2 levels
> up? Does the server have to preserve those namespaces too? Where do we
> draw the line?

You need to preserve everything that's needed to round-trip the value;
just like when storing arbitrary XML in property values. How the server
is doing that of course is an implementation detail.

> Does MS Office really behave this way and make these demands?

I think yes, but I may confuse it with another early client (Adobe comes
to mind). Fact is, the WebDAV WG is aware of clients making this
assumption and thus has clarified it.

> Does RFC2518 really allow clients to attach arbitrary junk to <DAV:owner>?

Depends on what you call "junk". RFC2518 has both examples for plain
text and "structured" XML in it's examples, and DAV:owner is defined as:

<http://greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_owner>

so the spec definitively allows anything that can be marshalled as XML
content.

Anyway: the DAV:owner field is defined to be something to be supplied
with the LOCK request which has *only* significance for the client who
supplied the lock. There's no need for any other client to understand
it, thus serializing the XML into an opaque string should be completely
reasonable...

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org