RE: DTD Confusion

Well, I personally have had mixed emotions concerning the value of DTDs in
the protocol specification.  When DTDs come up, half of the time I curse
Yaron for pushing DAV into using XML in the first place.  But, then there
are times, such as when editing the ACL specification recently, where the
act of creating the DTD uncovered several errors in the XML aspects of the
specification, and DTDs seem like a good thing.

If someone with deep implementation experience like Hartmut Warncke feels
that appropriate use of DTDs would have saved some interoperability
problems, then it seems like the 3-5 hours to produce these DTDs would be
worthwhile (it didn't take that long to produce the ACL spec. one, even with
fixing the errors I found).

As for the per-method DTD, this seems like a good idea, one worth exploring
in the revision of RFC 2518.

Of course, this is all subject to the caveat that the WebDAV XML rules not
be interfered with (i.e., sibling ordering is not guaranteed, the XML
namespace append rules, and the unknown element ignore rule).  I'm also not
in favor of sending the URL of the DTD in every message -- what a waste of
bandwidth, since clients and servers won't be doing dynamic validation.

- Jim

  Excellent suggestion Geoff! I couldn't agree more. However, this is really
a WebDAV issue too, so the WebDAV working group should get involved. If they
aren't interested in providing DTDs, then there probably isn't much point in
Delta-V doing providing a partial set. Also note that having the DTDs should
never require clients or servers to use them. They won't help formalize the
extensions either. Personally I'm more interested in getting the semantics
understood and formalized. DTDs can't do this, they only do structure. A
good, complete object model, including behavior, state models, and/or
interaction diatrams (or collaboration graphs depending on your preference)
would be much more useful.