Subject: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt)

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 21 Jun 2003 16:55:56 -0700

Are there any more opinions on the use of DTDs?  Has the consensus reversed?
I thought the consensus was clear way back when I made the change to move
from a specific list of children to the definition form of ANY (where
appropriate) plus a list of possible children in English rather than DTD.  

Originally, there was a lot of discussion that overall seemed to favour DTDs
that allowed both extensibility and validation.  FOr example:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0242.html -
Juergen Reuter
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0055.html - Jim
Amsden
http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0082.html -
James Hunt
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0201.html -
Julian Reschke
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0060.html -
Lauren Wood
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0061.html   ^

Are we back to the idea of throwing out the DTDs altogether?  That would be
OK by me. Sometimes English can be more accurate than a limited formal
language.

Say, why do so many names on this list begin with 'J'?  Clearly Geoff should
spell his name Jeoff & I should change my name to Jelisa or something.

Lisa

> I agree with all of his points.  The only one I was tempted 
> to question was "Section 13: XML element definitions", where 
> he suggested going back to the old syntax for DTD's.  But 
> upon further reflection, although I believe the new more 
> flexible notation should be used when defining all new 
> elements, for compatibility with old servers, we should 
> probably maintain the element order defined by 2518, so I 
> actually agree with that point as well (:-).
> 
> Cheers,
> Geoff
> 
> 
> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2003 7:52 AM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt
> 
> 
...
> 
> 03-C34:
> 
> Section 13: XML element definitions
> 
> I don't like the syntax change in the DTDs. For instance, 
> activelock now is defined as:
> 
>    <!ELEMENT activelock ANY>
>    ANY value: Any number of elements, including one of each of
>    (lockscope, locktype, depth, owner, timeout, locktoken, lockroot)
> 
> It used to be:
> 
>    <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
>    locktoken?) >
> 
> For consistency with RFC2518, RFC3253 and the ACL spec we 
> really should stay with the old notation.
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Jun 2003 12:29:23 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, June 22, 2003 1:56 AM
> To: [email-masked]
> Subject: Reconsidering DTDs and validity (was RE: I-D
> ACTION:draft-ietf-webdav-rfc2518bis-03.txt)
>
>
>
>

Can you point to where this was discussed?

> Are we back to the idea of throwing out the DTDs altogether?

Well. DTDs can *not* be used for validating WebDAV request/response bodies
(hopefully we agree on that?). Thus new specs must make sure that they are
clear about the fact that the role of DTD fragments.

Usage of DTD fragments in RFC2518, RFC3253, ACL and the ordering spec *is*
consistent. In the Ordering Spec I am trying to summarize how the DTD
fragments need to be read [1]:
.
--

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:

1. element names use the "DAV:" namespace,
2. element ordering is irrelevant,
3. extension elements (elements not already defined as valid child elements)
may be added anywhere, except when explicitly stated otherwise,
4. extension attributes (attributes not already defined as valid for this
element) may be added anywhere, except when explicitly stated otherwise.

--

Again, this is consistent with all WebDAV specs that are RFCs (or hopefully
will be soon).

> >    <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,

The "old" syntax in theory allows programmatic checking of XML bodies (with
the caveats listed above), while the "new" syntax just uses prose. However,
the main problem is it's inconsistency with all the other specs that we
have. I would find it very confusing if the way DTD fragments in WebDAV
specs need to be read depend on which spec (or which revision of a spec)
you're looking at.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-08.htm
l#rfc.section.1>

---

From: Joe Orton <[email-masked]>
Date: Sun, 22 Jun 2003 12:07:50 +0100

I think it's important to retain some of the ordering constraints given
by the DTD fragments in 2518 - specifically it is useful that a client
can assume that in the response element, a propstat MUST be preceded by
an href.

Since a propstat cannot be interpreted without knowing which URI it
applies to, if this constraint is missing, the client is required to be
able to batch propstats in memory until the href arrives.  With this
constaint, propstats can always be processed on the fly.

joe

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 22 Jun 2003 16:22:19 +0200

> [mailto:[email-masked]]On Behalf Of Joe Orton
> Sent: Sunday, June 22, 2003 1:08 PM
> To: [email-masked]
> Subject: Re: Reconsidering DTDs and validity (was RE: I-D

I really don't care much about the issue. However, we really really need to
decide this, and then stay consistent. The current situation obviously is
problematic.

*If* we decide that ordering *is* relevant, we should clarify that both
servers and clients must reject messages that do not comply. I don't want to
end up in a situation where some clients work with non-compliant servers,
while others don't.

However, my feeling is that *currently* almost everybody ignores the
ordering, and that server behaviour is *not* consistent. Thus from a
standards progress point of view, it would make sense for RFC2518bis just to
state that the ordering is irrelevant.

> constaint, propstats can always be processed on the fly.

Stream processing of response bodies is a very interesting problem. However,
I think even if you can rely on ordering, it is still hard. For instance,
how do you process:

   <D:multistatus xmlns:D="DAV:">
     <D:response>
          <D:href>http://www.foo.bar/file</D:href>
          <D:propstat>
               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                    <R:bigbox>
                         <R:BoxType>Box type A</R:BoxType>
                    </R:bigbox>
                    <R:author>
                         <R:Name>J.J. Johnson</R:Name>
                    </R:author>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
          <D:propstat>
               <D:prop><R:DingALing/><R:Random/></D:prop>
               <D:status>HTTP/1.1 403 Forbidden</D:status>
               <D:responsedescription> The user does not have access to
   the DingALing property.
               </D:responsedescription>
          </D:propstat>
     </D:response>
    This is malformed: &
   </D:multistatus>

A compliant client must reject this reponse, because the body is malformed.

BTW: you will need to batch the propstat element until you've reached the
DAV:status element (confirming it's a "200") anyway. I don't see a big
difference to waiting for the closing response tag.

Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 23 Jun 2003 07:58:16 -0400

I'd suggest that we start with a generic statement that DTD implied
ordering is to be ignored, but that the definition of a particular
element can explicitly declare that ordering matters. 

WRT this particular case, I don't think that the amount of memory/time
required on the client to read in the propstat before knowing what
URL it is for is significant enough to matter (but like Julian,
I don't care strongly either way, so I wouldn't object if the consensus
is to make ordering matter in this particular element).

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 23 Jun 2003 09:04:04 -0400

Actually, for maximizing interoperability, I'll modify my
suggestion to state:

A server SHOULD adhere to the ordering implied by the DTD, but
a client SHOULD accept an arbitrary ordering.

This is just what I would do when implementing a client and a server,
but I don't have a strong opinion about what the spec should say in
this regard.

Cheers,
Geoff