RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, March 21, 2003 5:30 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt
>
>
>
> I'd like to thank Julian for this excellent and careful review!
>
> I agree with all of his points.  The only one I was tempted to
> question was "Section 13: XML element definitions", where he
> suggested going back to the old syntax for DTD's.  But upon
> further reflection, although I believe the new more flexible
> notation should be used when defining all new elements,
> for compatibility with old servers, we should probably maintain
> the element order defined by 2518, so I actually agree with that
> point as well (:-).

Well.

The issue here is that all of our specs are using DTDs to describe protocol
elements. But for many reasons, DTDs can not accurately describe the content
models we use in WebDAV (namespaces, ordering, special extensibility
rules...).

One way to fix this would be to use a different schema language (XML Schema
won't help a lot, RelaxNG may), or to get rid of the formal notation and
fully describe the structure in prose. I think the latter doesn't fly, as it
makes both reading and writing the specs much harder. Changing the schema
language doesn't seem to solve it as well, unless we can decide to use one
that actually *can* express the constraints in WebDAV (I *think* RelaxNG
could, but I'd be surprised if we'd get consensus to make that change).

That leaves us with DTDs.

Right now, RFC2518, RFC3253, and some other specs which are nearing
completion (ACL, Bind, Ordering) all use the same approach, which is:

Use DTDs with the following additional guidelines:

- elements are in the DAV: namespace
- ordering doesn't matter (I *think* that's what most people assume)
- extensibility rules from RFC2518 appendix apply

This has worked fairly well. In particular, it allows me to write down
things like:

	<!ELEMENT propfind (allprop | propname | prop) >

without adding a lot of prose. Again, that's better both to read *and* to
author.

In addition, making a change now will make RFC2518bis inconsistent with the
other specs that already are published or close to submission. I think this
would be a mistake, because it's guaranteed to confuse implementors.

So my proposal is to keep the old syntax, and add crystal-clear rules how to
read the DTDs (see for instance [1]). In addition, we'll have to fix the
edge cases in RFC2518 (for instance state that extension elements in
DAV:prop MUST NOT be ignored).

> So I vote that all of the changes suggested by Julian be made
> to the next draft of 2518bis.  Note: I have no good idea about
> how to deal with the 5 author limit question (:-).
>
> Cheers,
> Geoff

Regards, Julian


[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.section.1>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 21 March 2003 11:58:31 UTC