Rick Jelliffe wrote:

> From: "Dennis Sosnoski" <dms@[...].com>
>   
> 
> >I absolutely prefer using DTDs.
> >    
> >
> 
> What things are nice about DTDs? terseness, 80/20 level of complexity, 
>  familiarity, tools support, feature mix, link-oriented datatypes?
> 
Simplicity and terseness are at the top of my list. The only real 
problem with using DTDs now is Namespaces. The non-XML format is a pain, 
but less so than the verbosity and complexity of Schemas. DTDs are 
simple enough that they don't really require any special tools, in my 
experience; Schemas do.

Familiarity is certainly a part of this. I strongly suspect, though, 
that given equal time spent on both most users would be able to work 
with DTDs far more reliably and confidently than with Schemas.

> Are you saying that as well as supporting the validation model where 
> we allow very specific validation using generic tools as a matter of
> QA and QC, we also need to support document flows where 
> we have only rudimentary point-to-point validation (e.g. just enough to make sure
> that intermediate XSLT programs will work) and the main application
> looks after any complex validation itself?
> 
Rudimentary validation support makes sense to me as a developer using 
XML (basically what's provided by DTDs, element and attribute names, 
nesting, and ordering). Going beyond that is redundant to my application 
code, which means that either I'll ignore the extra validation features 
or will just turn off validation in the parse.

I can see the use of more specific validation in some types of 
applications, but I think these are the exceptions rather than the norm. 
My main argument is just that validation through Schema or any of the 
alternatives does not eliminate the need for a consciencious developer 
to verify the data as received by the application - and if you're doing 
this, why have the parser run a subset of the same checks?

Most of the projects I've worked on have used schema for data 
description rather than validation, and for that purpose readability is 
the most important criteria. It's acceptable to use comments in DTDs to 
say that the content of a particular element is actually a credit card 
number, for instance - trying to format this as a regular expression for 
parser validation would just add complexity (and likely errors, in terms 
of accepting either too much or too little).

Back before XML Schema escaped into the wild, I first heard about it and 
thought it'd be a Really Great Thing - get rid of that ugly DTD format 
and use XML instead, be able to say that an attribute is an integer, 
etc. As time went by and the number of pages in the Schema 
specifications continued to grow I started to find DTDs more and more 
appealing. Now I see Schema as the reincarnation of Ada (my apologies to 
any Ada fans on the list, but I went through much the same experience 
with that initiative at the time it came out) - elegant in a way, but 
far too complex to be appealing.

That said, I'm clearly in the message-oriented middleware camp of XML. I 
rarely have anything to do with XSLT or presentation-oriented 
applications. My views might be different if I were doing that type of work.

  - Dennis

Join the DTD Underground! The Evil Elitist Schema Empire will be Crushed 
by the Indifference of the Uprisen Masses of the Developer Proletariat! 
We Shall Overcome!!!

Or not...  ;-)


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>