[
Lists Home |
Date Index |
Thread Index
]
Rick Jelliffe wrote:
>From: "Dennis Sosnoski" <dms@sosnoski.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... ;-)
|
