W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003

How to use DTDs, or not to (was: RE: ACL and lockdiscovery)

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 7 Oct 2003 11:48:51 -0700
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Geoffrey M Clemm'" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3.org>
Message-ID: <011d01c38d03$a6ecf030$f8cb90c6@lisalap>

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

Does that mean we go back to what was in RFC2518 before the 'bis'
changes started?  Then we've failed to address the issue where
we had interoperability problems because implementations did not
allow extension elements in places where the spec ought to allow

I know this is a failure of the implementors to follow the text 
in the spec to its logical conclusion, but as we've seen a clear
spec is crucial to easing the way to interoperability.

I can't tell what the consensus is here.  I thought originally
there was a consensus to clarify which elements could be extended
and in what way.  I attempted to do this by altering the DTD, 
and I also proposed doing this by replacing DTDs with English.
The third option is to go back to RFC2518 DTDs and ignore the 
problem.  I haven't seen a fourth concrete option.

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

This doesn't seem sufficient to me unless we simply decide not
to address the problem.  RFC2518 already had general language of
this sort to say that generally extensibility should be allowed.
To solve the problem, we need to specify for every element how
it may be extended, and what it means to extend it. Or we can 
decide not to solve the problem.

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

This seems opposite to what I'd expect "ANY" would mean.  The prop
element is the *most* extensible because all implementations know
you can put any element child in here, as long as it is a property name.

Received on Tuesday, 7 October 2003 14:48:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC