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

> Both. The DTD should be normative and just say "ANY" (like it 
> did in RFC2518). We also should clearly state what "ANY" 
> means regarding extensibility (it means that the 
> extensibility rules from section 14 do NOT apply). In 
> addition, it won't hurt to restate it in plain english -- but 
> I think the DTDs should stay (unless we can replace them with a better
> *formal* definition).

The DTD cannot be normative - it doesn't give the whole picture.
An appendix can't be normative.  The DTD fragments in subsections
of section 12 could be normative in combination with the XML
extension rules *and* the specific element value rules, but 
the spec doesn't specifically say this.

What if we omitted the summary DTD in appendix 1 (23.1), 
and instead had only DTD fragments with each property?  THen the 
reader of the spec would be more likley to read the whole
definition, rather than the shortcut of going to the appendix and
only seeing part of the whole picture.


Another idea.  As long as we're stating what ANY means, why limit 
ourslves.  Eg. we could use pseudo-DTD syntax -- extending the definitions
to say more of what we want them to say. We could call it a WebDAV-DTD
if it offends people to redefine XML DTD.

E.g. 
   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?, *) >

   <!ELEMENT prop ANY_PROP >


I don't know how we'd go about formally extending DTDs to do this 
or if that's important, but since the DTD in appendix 23.1 isn't 
normative presumably that would not be illegal.

In my opinion the important thing to keep our eyes on here is to 
make the spec as readable, as implementable, and as conducive to
interoperability, as we can.  "Rules" about DTDs or definitions are
there as our tools, to reshape into better tools if we can, to 
achieve our main goals in this spec.

Lisa

Received on Tuesday, 7 October 2003 20:32:11 UTC