RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)

Hi Julian,

I'm surprised once again.  OK, there are several topics here:

1.	Having a generic DTD for WebDAV, or at least one that is generic as possible considering that actual documents can introduce ad hoc elements and attributes in various places.

There was a question about how to do it and sources on the technique.  I have addressed that question.  I have only addressed the question in the context of section 24.2 of bis-04, because I saw immediate application there.  It is also an useful cross-check on the specification and it provides an operable DTD that people can use in working with the specification, creating DAV protocol elements manually, etc., under the understanding that it is non-normative.

2.	Having a way that someone could develop a quasi-generic DTD for a family of WebDAV XML documents of interest.  

I think that comes out of (1).  Since this is a restricted-use situation, a precise DTD might actually be possible for many situations in practice, and I demonstrated a way to have that.  It is also possible in many places where ad hoc properties and attributes are either not provided for or don't happen to be used.

3.	Using XML DTD Fragments (markup declarations) to illustrate/explicate (not specify) the structures that apply for specific elements of WebDAV.  

Since that can't be "normative" as a DTD anywhere that allows ad hoc elements in the content model, or ad hoc attributes of an element, I would think  it is a nit whether you use a convention of supposing a representative (explicit) namespace prefix for QNames in the specification, as many XML-family specifications do, or you show the use of parameters in the specimen markup declarations.  It's the difference between

	<!ELEMENT dav:error ...> 
	<!ATTLIST dav:error 
                xmlns:dav (DAV:) #REQUIRED
	          ... >
and	<!ELEMENT %dp;error ...>
	<!ATTLIST %dp;error 
                xmlns%ds; (DAV:) #REQUIRED
	          ... >

where the second parameterizes the use of namespace prefix, but which might not be so appealing in the flow of the exposition.  Either way, I would not show the <!ATTLIST ...> everywhere.  The assumption of such an <!ATTLIST ...> would be explained in the documentation of fragment usage in the specification.

I am not addressing the question of DTD fragments with my proposal for section 24.2.  One can do 24.2 independent of whether markup declarations are used elsewhere in the specification, and whether they are of the same literal form.  

4.	Concerning the question of whether or not Document Type Declarations (<!DOCTYPE ...>) should be allowed in the XML document prolog of DAV request and response bodies, I see my recommendation for 24.2 as orthogonal to that.  

Also, I don't believe there is agreement to disallow Document Type Declarations at this time.  (I will keep repeating that presence of a Document Type Declaration and using a non-validating processor are separate but interacting matters.)

It is valuable to have a DTD that is crafted in such a way that it can be used to establish validity of a document in proper form (e.g., no defaulted attribute values for required attributes) for use with or without validation, with or without a Document Type Declaration.  I think one can come close to that as a practical matter.  I find it valuable.

I find interactions with the requirement for use of a non-validating XML processor to be problematic.  A way to assure a predictable, interoperable non-validating process case is to omit Document Type Declarations in requests (as a practice, even if not a requirement of 2518).  There is absolutely no doubt about validation in that case. So omission of a Document Type Declaration is a good practice for obtaining clearly-predictable behavior in DAV requests (and appropriate safety, regarding any concern for reference to external parameters and external XML entities as identified in section 18.6 of bis-04).  

Dealing with a server that provides Document Type Declarations in responses is something I don't want to think about.  In practice, that borders on a hostile act, since it imposes processing on the client and has the interpretation of the response be unpredictable in some cases.  It raises the bar for universal client processors.

5.	Why do I consider (4) and some of the other items when we are "only" talking about HTTP extensions and what happens in that narrow band of what the DAV functioning is all about -- the exchange of protocol elements?  

I answer with a question: Why is it important to use XML in that narrow setting? I am considering the setting and the desire people have to be able to understand the rules, apply tools that are available and supported in the industry, and also be able to check their work (or the work of their software) as well as trouble-shoot.  That strikes me as valuable.  

6.	Is it worth it?  I don't know.  I demonstrated the degree to which it could be done.  Developers of other XML-family specifications have found it worthwhile.  Does it hurt?  How can it?
Would I do it?  Yes.

This can clearly be done.  Whether it is included in the specification or not seems to be the question.  We need some other countries to be heard from.

-- Dennis


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, October 14, 2003 07:43
To: dennis.hamilton@acm.org; w3c-dist-auth@w3.org
Subject: RE: rfc2518bis DAV DTD (was Re: How to use DTDs, or not ...)


Dennis,

I'm not sure what you're trying to achieve.

On the one hand, we're trying to clarify that WebDAV messages MUST not be
validated using DTDs. On the other hand, you're trying to come up with a
clever way to enable DTD validation. As far as I understand, it will never
work for arbitrary now legal WebDAV messages, so why bother?

After all, the initial question was about whether we want to continue using
DTD fragments to specify some constraints on WebDAV messages -- after all,
this is what all published and soon-to-be published WebDAV-related specs do.
So if there's an issue with that notation, we should fix just that, nothing
more... In particular, if "fixing" the DTD notation essentially means to
make it extremely complicated to read, this will be in fact
contra-productive.

[ ... ]

Julian

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

Received on Tuesday, 14 October 2003 15:32:55 UTC