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

> Nobody suggested not doing anything at all. However, I also 
> don't remember any agreement about removing all formal 
> definitions (be it DTD or a different syntax) in favor of 
> just using plain English. In fact, there doesn't seem to be 
> an issue on the RFC2518 issues list related to this at all.

That's not what I said - I also don't recall any agreement about
removing all formal definitions.  Instead, I believe we decided to 
address a certain problem, which was interoperability problems due
to implementations having trouble accepting extensions in some 
elements.  Assuming we still have consensus about addressing this
problem, I'm trying to determine consensus about *how* to address
this problem.

> Then you've missed it :-). I've been trying to come up with 
> language that absolutely clarifies what the DTD fragments 
> say. It's in the ordering draft that we all discussed just 3 
> months ago. I think the very same language should be used in 
> all WebDAV specs (this may be somthing we want to sneak into 
> the ACL spec during the AUTH period...).

I'm sorry, I don't see how the ordering draft does anything 
signficantly different here. For example, this is from the 
ordering draft: 

   <!ELEMENT orderpatch (ordering-type?, order-member*) >

This is exactly like RFC2518, and I couldn't find additional text 
to specify whether orderpatch can have custom child elements.


> 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.
> 
> Again: no, we don't need to specify that, and we can't. If an 
> element is extensible, there's no point in discussing what an 
> extension could mean. It could mean anything, that's the 
> point of an extension. On the other hand, if an element can't 
> be extended (in RFC2518, that seems to be just <prop> and 
> <resourcetype>), then that's all we need to say as well.

Yes, we can do that.  For example, the text for RFC2518bis says:

		The prop XML element is a generic container for 
            properties defined on resources.  All elements inside a 
            prop XML element MUST define properties related to the 
            resource.  No other elements may be used inside of a prop 
            element. 

That's an example of a "negative" restriction, where the element 
being defined can't be extended in just any way.  The opposite example
might be to define the element as extensible in the DTD:

   <!ELEMENT resourcetype ANY > 

And we could add more text for example (made up on the spot:

	it is expected that resourcetype will be extended with new 
	standard or custom child elements when new resourcetypes are 
	defined.  Resources types that are unrecognized should
	be treated as regular resources.  Resource type values that 
	contain DAV:collection as well as additional unrecognized 
	elements or child elements within DAV:collection should be 
	treated as collections.

Yes, it's a lot of work to do this thinking, but I think we ought to do 
it -- and perhaps throw away the DTD if it gets in our way or confuses
readers.

> Sorry, Lisa, but this is just plain wrong. <prop> is not extensible
> *because* it already has a defined semantics for each 
> possible child element. That's *why* the content model say's 
> "ANY". It means: you could put any element here, and the spec 
> defines what that means.

We must have different meanings of the word extensible.  I'm 
trying to adapt DTDs to our XML usage here.  Since the list of 
elements you can put in the 'prop' element is not limited, I call
it extensible.  Would you like me to use a different word for this?
I use this word in this way to distinguish from the <href> element
which is not extensible because it can only contain URIs.

> On the other hand, elements with closed content models (such 
> as <propfind>) are the elements that *can* be extended. 
> Looking at the DTD in RFC2518, "ANY" is used exactly three times:
> 
> prop: whatever child element you put here, it identifies a property
> resourcetype: whatever child element you put here, it 
> identifies a resource type
> owner: content model is completely by definition
> 
> So, with the exception of DAV:owner, "ANY" is used exactly in 
> those cases, where the element can *not* be extended, and I'd 
> be really surprised to hear that this wasn't on purpose.

Would it have been any different if the <prop> element had been
defined in a DTD like this:

   <!ELEMENT prop (creationdate?, displayname?, getcontentlength?,
			getcontentlanguage?, getcontentlength?, 
			getcontenttype?, getetag?, getlastmodified?,
			lockdiscovery?)> 

This would be very much in spirit with the rest of RFC2518, 
because it defines the known elements from the rest of the spec
that can appear in the 'prop' element.  Because of the general
extensibility rules it doesn't change the way it can be used.
Does that change the 'prop' element from what you call unextensible
to what you call extensible?  I think you're making a distinction
without a difference here.

> Hmm. Maybe the issue is that there's a disagreement about 
> what "extensible" mean. When I say "extensible", I'm talking 
> about the thing described in RFC2518, Appendix "Example - 
> Unknown XML Element"...

Heh heh- I said the same thing before I read so far.  

So perhaps we can agree on some more helpful terminology: 

 - *fully extensible* elements like 'response' can contain any
elements not defined in RFC2518 and their meaning is not pre-defined.
 - *partially extensible* elements like 'prop' aren't limited to
a known set of child elements but the meaning of child elements is
strictly defined.  
 - *unextensible* elements (possibly lockscope should be?) have a known and
limited set of child elements allowed.

Given that elements like 'response' and 'prop' are extended (by adding
currently unknown child elements) in different ways - one has a
known meaning, and one has an unknown meaning - surely we can say more
about this in RFC2518bis.  Because otherwise, implementors tend to
assume that the 'resourcetype' element can only contain 'collection' 
or nothing.

Back to the question I'm trying to ask: how should we make it clearer
to implementors that an element like 'resourcetype' can have more than
just 'collection' sub-element or nothing?  Should we attempt to do this
in the DTD (if so how) or in English?  If we do so in English, does the
DTD become misleading, drawing the reader away from the important parts
of the element's definition?

Lisa

Received on Tuesday, 7 October 2003 17:11:43 UTC