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

I looked at where this current conversation was going and I thought it best to respond here, where it seems to have started.  I am arriving in the middle of a long-running discussion of DTDs, but I thought these observations might help to calibrate the discussion. (I finally took a course on XML and Web Services and used the occasion to dig into the specifications more than I had up until now.)

1.	ARRANGING FOR DTD VALIDITY OF A WebDAV XML 1.0 "document" 

The key thing to keep in mind is that 

If you intend for a WebDAV "document" to be an XML 1.0 document that is [DTD] valid,

	(a) the ANY case in an element markup declaration means any element that is declared in the DTD, not some undeclared or unspecified element.
	(b) Elements having no markup declaration in the DTD are not permitted in [DTD] valid XML 1.0 documents.  (This is specific technical language around what it means for an XML 1.0 document to be valid as opposed to simply well-formed.)

2.	What that might mean, generally, is that the best external DTD that can be created for WebDAV is one that is a skeleton that must be supplemented by additional markup declarations (perhaps in an internal DTD subset) to account for any extensions. If no extensions are used (e.g., no elements and attributes from any other namespace), the external DTD will work fine by itself. 

3.	When it gets too difficult to handle that, or there is too much variability to deal with, I recommend simply not providing a Document Type Declaration (the <!DOCTYPE ...> structure) and fall back to the WebDAV XML being merely well-formed (and conforming to the WebDAV rules but without asserting [DTD] validity).  

4.	NAMESPACES

I notice that "DAV:" is referred to as the namespace, when, according to the Namespace specification and other specifications since (such as XML Schema), it is technically a prefix.  That is, attribute

	xmlns:DAV="some-URI-for-the-WebDAV-namespace"

establishes the "DAV:" prefix for QNames that refer to local names of the WebDAV namespace.

It is possible to deal with this (a namespace known in advance) and not even require that the prefix be "dav:" in creation of a WebDAV DTD.  This is done, for example, in the DTD that exists for XML Schema documents.  The XML Schema DTD can be used to validate schema documents and provides a way to select alternatives to the exemplar namespace prefixes "xs": and "xsi:".  This is done in a way that requires no modification to the DTD.


5.	RUNNING OUT OF GAS

If a DTD is used for validation of a document, the DTD must account for all of the QNames that can be used for elements and attributes.  That includes all of the namespace declarations and the prefixes that they will declare.  (xmlns:prefix attributes are often declared to be #FIXED and the namespace URI is then regulated too.)

Because of the requirement to rigidly and completely define a document's structural vocabulary, even with the promiscuous allowance of ANY elements, there are times when it doesn't work to have a DTD.  One certainly can't be required if there is meant to be tolerance for arbitrary addition of attributes and elements in any document instance.  The ideas of a fixed, known-in-advance DTD and arbitrary additions of elements and attributes to documents are incompatible.  The alternative, as in the case of RDF, is just too difficult because there basically has to be a custom DTD per RDF document instance, and they have to be maintained together as new versions of the document are created.  (I've actually done that but only for simple cases.)

I find DTDs very useful and often create one simply as a design device when building XML documents.  It is very helpful to have the support of my validating XML editor to let me know when I have something to clean up.  I've even found it useful to use DTDs and XML Schema together.  

Does this shed any light or have I just muddied a situation that you have already struggled through many times?

Regards,

-- Dennis

Dennis E. Hamilton
------------------
AIIM DMware Technical Coordinator
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430
http://DMware.info
   ODMA Support: http://ODMA.info
OpenPGP public key fingerprint BFE5 EFB8 CB51 8781 5274  C056 D80D 0C3F A393 27EC

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
Sent: Tuesday, October 07, 2003 11:49
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.  

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.

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

> > This would tend to drive us, the spec writers, to include more 
> > information, more
> > guidance, rather than less.  That's because the DTDs don't provide an
easy
> > place to say whether an element may be extended with new
> > elements, or under
> > what conditions an element is required.

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

Lisa

Received on Thursday, 9 October 2003 18:02:15 UTC