"So the advantage of DTDs is that they are gibberish to all?"
No. The advantage is almost everything a human needs to read to interpret
them is in one place. XSD may be richer in types and a parser writer's wet
dream, but as a simple human lookup, it sucks.
#IMPLIED means: here is a hole. Fill it or ignore it, I don't care
if you don't and if you do, I still don't care.
In music, it is a something like "poco a poco" followed by a "caesura"
followed by "a tempo". The real-time interpretation is: get your
eyes out of the sheet music and don't take your eyes off the conductor
until you and the choir meet in the next measure.
The pain one endures to learn to do anything is proportional to the
results obtained. As someone who has to be able to read both to
accomplish simple
tasks such as writing FOSIs, DTDs are more appropriate by several orders
of magnitude. I do understand there are other applications for which that
will not be the case. BTW: FOSIs are a good example of why having a
spec that is "Just Syntax" is a good thing and a bad thing. Take a
look at the micro-syntax used for post-validation contributions so the
PDF rendered from multiple small XSDs for different parts of a book
can appear and link as if 1.0 title looks and link exactly the same
despite one being <proceduralStep id="" and another being
<checklistStep id=""... Content naming is good idea until one
realizes that reuse of little bits of data is a lot less than we once
believed, aka, why database thinking and document design CAN result in
bad data design. It isn't the technology: it is the use case reality.
As for music (with nods to Dr. Newcomb), despite the limitations, I
often compose in guitar tablature and render in *piano notation*
because the first is native and the second is more widely spoken. The
best local adaptation I've seen lately was a printed score for a piece
in six flats and a marking saying:
MODERATO (quit bitching about the key signature and just play it).
