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

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Tuesday, October 07, 2003 11:12 PM
> 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)
>
>
>
> > 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.

OK, we're in agreement. In particular, one issue I do remember are certain
clients that insist in popping up warning messages when a server extends a
response in an unexpected way. However, I fear that RFC2518 already was very
clear about the extensibility rules, so I'm not sure that any amount of
additional language would have avoided that.

The main issue is that we are (were) using DTD fragments, but we also
state(d) that WebDAV messages can't be validated. Many people seem to be
confused about that. The options here some to be:

- try harder to explain it
- choose a schema language that allows to express RFC2518's extensibility
rules (as far as I understand, that would require Relax NG, XML Schema
*won't* do that)
- do not use any formal language at all (this I think would be a mistake)

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

- The additional language about what DTD fragments mean is in section 1
(Notational Conventions)

- In fact, the standard RFC2518 rules apply, so all of these can have custom
child elements -- just like in RFC3253 and ACL.

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

Yes. It's not extensible. The DTD should state ANY, and probably the
description should state explicitly what this means.

> might be to define the element as extensible in the DTD:
>
>    <!ELEMENT resourcetype ANY >

No no no. This does not mean that the element is extensible. It means that
the DTD already expects "ANY" content, thus meaning already has been
assigned to arbitrary child elements. Thus the element is *not* extensible.
What's extensible here is the set of valid resource types, but whatever you
put into DAV:resourcetype will always identify a resource type.

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

I think we should both keep the DTDs as formal (and normative definition
with the known caveats), *and* explain what it means (when there's a chance
it's not clear).

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

Yes. It is definitively not extensible in the way described by the "RFC2518
extensibility rules", described in the appendix (which state that any
element you don't know must be ignored).

> I use this word in this way to distinguish from the <href> element
> which is not extensible because it can only contain URIs.

Fascinating. I'd say it's extensible. For instance, I client should handle

	<d:href xmlns:d="DAV:">foo</d:href>

the same way as

	<d:href xmlns:d="DAV:">foo<foobar/></d:href>

(I'm not saying that I'd expect many clients to handle this gracefully, but
RFC2518 definitively allows this -- maybe that's a candidate for the issues
list).

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

Yes. That would mean that I could do a PROPFIND/prop/foobar and the server
would be allowed to ignore the foobar element (which would be wrong).

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

Yes it does. A server must respect *all* child elements of prop, whether
known or unknown. Thus <prop> is one of the few protocol elements that are
*not* extensible, because the spec already assigns meaning to all possible
child elements (ANY!).

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

Yes it does, and I just described the difference.

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

(actually, I should have been referring to section 14)

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

Agreed, except I'd prefer something different than "partially extensible",
and I'm not sure that the class of "unextensible" actually exists.

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

OK, so we just need to find a good name.

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

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

Julian

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

Received on Tuesday, 7 October 2003 19:21:17 UTC