RE: ACL and lockdiscovery

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, September 24, 2003 6:32 PM
> To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org
> Subject: RE: ACL and lockdiscovery
>
>
>
> Yeah, it is a quandary.  On the one hand, if we include a DTD  with
elements
> listed, implementors tend to barf when extra elements are sent.  On the
other
> hand, if we don't list the required elements, implementors tend not to
send
> them.
>
> What if we ditched the DTD entirely and simply use English?

I'd prefer to keep them and continue to use them the same way as currently
done in RFC2518, RFC3253 and the various drafts closing completion.

All that's needed is the following general clarification:

"This document uses XML DTD fragments as a purely notational convention.
WebDAV request and response bodies can not be validated due to the specific
extensibility rules defined in section 23 of [RFC2518] and due to the fact
that all XML elements defined by this specification use the XML namespace
name "DAV:". In particular:

- element names use the "DAV:" namespace,
- element ordering is irrelevant,
- extension elements (elements not already defined as valid child elements)
may be added anywhere, except when explicitly stated otherwise,
- extension attributes (attributes not already defined as valid for this
element) may be added anywhere, except when explicitly stated otherwise."

(see
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-10.htm
l#rfc.section.1>).

This reduces changes to existing and currently last-called documents to a
minimum, clarifies (hopefully all) issue and keeps the readability of DTDs.

> Something like
> this:
>
>   'lockdiscovery' property (in 'DAV:' namespace):
> 	MUST contain one 'activelock' elements for each lock on the resource
> 	MUST be empty if no locks exist on the resource
>
>   'activelock' element (in 'DAV:' namespace):
> 	MUST contain one 'locktype' element
> 	MUST contain one 'lockscope' element
> 	MUST contain one 'depth' element
> 	MAY contain one 'owner' element (MUST contain the value provided by
> the client if one was provided)
> 		(MUST NOT contain more than one 'owner' element)
> 	MAY contain one 'timeout' element
> 		if omitted, timeout value MUST be infinite
> 	MUST contain one 'locktoken' element
> 	MAY contain additional elements which can be ignored
>
>
> This would tend to drive us, the spec writers, to include more
> information,
> more
> guidance, rather than less.  That's because the DTDs don't provide an easy
> place to say whether an element may be extended with new
> elements, or under
> what conditions an element is required.

If this is the main issue, clarifying that an "ANY" content model indicates
that the element is *not* extensible (contrary to the default case) may
suffice (note that this would apply to the content of the DAV:prop element
in PROPFIND marshalling).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 24 September 2003 12:58:12 UTC