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: Tuesday, October 07, 2003 8:49 PM
> To: 'Julian Reschke'; 'Geoffrey M Clemm'; w3c-dist-auth@w3.org
> Subject: How to use DTDs, or not to (was: RE: ACL and lockdiscovery)
>
>
>
>
> > > What if we ditched the DTD entirely and simply use English?
> >
> > I'd prefer to keep them and continue to use them the same way
> > as currently done in RFC2518, RFC3253 and the various drafts
> > closing completion.
>
> Does that mean we go back to what was in RFC2518 before the 'bis'
> changes started?  Then we've failed to address the issue where
> we had interoperability problems because implementations did not
> allow extension elements in places where the spec ought to allow
> them.

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.

> I know this is a failure of the implementors to follow the text
> in the spec to its logical conclusion, but as we've seen a clear
> spec is crucial to easing the way to interoperability.
>
> I can't tell what the consensus is here.  I thought originally
> there was a consensus to clarify which elements could be extended
> and in what way.  I attempted to do this by altering the DTD,
> and I also proposed doing this by replacing DTDs with English.
> The third option is to go back to RFC2518 DTDs and ignore the
> problem.  I haven't seen a fourth concrete option.

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

In fact, you're quoting that fourth option below :-).

> > All that's needed is the following general clarification:
> >
> > "This document uses XML DTD fragments as a purely notational
> > convention. WebDAV request and response bodies can not be
> > validated due to the specific extensibility rules defined in
> > section 23 of [RFC2518] and due to the fact that all XML
> > elements defined by this specification use the XML namespace
> > name "DAV:". In particular:
> >
> > - element names use the "DAV:" namespace,
> > - element ordering is irrelevant,
> > - extension elements (elements not already defined as valid
> > child elements) may be added anywhere, except when explicitly
> > stated otherwise,
> > - extension attributes (attributes not already defined as
> > valid for this
> > element) may be added anywhere, except when explicitly stated
> > otherwise."
>
> This doesn't seem sufficient to me unless we simply decide not
> to address the problem.  RFC2518 already had general language of
> this sort to say that generally extensibility should be allowed.
> 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.

> > If this is the main issue, clarifying that an "ANY" content model
> > indicates that the element is *not* extensible (contrary to the
> > default case) may suffice (note that this would apply to the
> > content of the DAV:prop element in PROPFIND marshalling).
>
> This seems opposite to what I'd expect "ANY" would mean.  The prop
> element is the *most* extensible because all implementations know
> you can put any element child in here, as long as it is a property name.

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.

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.

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

Julian


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

Received on Tuesday, 7 October 2003 15:14:18 UTC