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

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

Got any suggestions?  I'll try to come up with something here.

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

I'll do that, then.

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

Sure, but you could also say the allowable content model for 
'response' element is ANY.  I will attempt to make this clearer
with English alongside the regular DTD although I still think 
the spec could be clearer without something else formal or 
semi-formal that worked better for us than DTDs.

lisa

Received on Wednesday, 8 October 2003 12:27:52 UTC