RE: How to use DTDs, or not to (was: 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, October 08, 2003 2:32 AM
> To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org
> Subject: 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.

I can be *made* normative. That's what I'm trying to do.

> An appendix can't be normative.  The DTD fragments in subsections

Yes it can. Quoting from RFC223bis (07):

      4.7e Appendixes

         Many RFC documents have appendices, some of which may be very
         extensive.  Common practice is to position Appendixes at the
         very end of a document, after the references.  However, a
         significant set of RFCs have large and dense Appendix sections
         for technical details, which are actually an integral part of
         the document.  In this case, it can be difficult to locate the
         references.  We therefore recommend that, in general,
         references follow the Appendixes in an RFC.

I agree that informative parts are usually in the appendix, but that doesn't
mean that any appendix is automatically non-normative.

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

That's what we should fix.

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

That sounds like a good idea.

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

We could, but I'm not sure why we would want to do that. The DTD fragments
define allowable *syntax*. The allowable content model for PROP *is* ANY.

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

Yes. IMHO the basis should be a formal description that is normative, and in
those cases where we feel that people may not "get it", add additional
English language.

Julian

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

Received on Wednesday, 8 October 2003 04:01:39 UTC