[
Lists Home |
Date Index |
Thread Index
]
> > I eschew all the other stuff heaped in there from the SGML days
> > where possible.
>
>Such as?
> macroprocessing - as you yourself highleghted.
> I'd really love to know about the best alternatives
>to DTDs. Many thanks.
> I think we differ over the semantics of the word "eschew".
Not really. I just thought that you may know about some
SGML alternatives to DTD, because you know more about
SGML than I do, so I asked ... just in case.
For example, I don't understand what in DTDs is
'from SGML days' and what is not. I thought that
everything in DTDs is 'from SGML days'.
> > DTDs are not perfect, there are multiple alternatives, some better than
> > others for document-oriented XML applications.
>
>Well, I don't understand your point then.
> Likewise, I do not understand yours. Sorry.
My point is simple. DTDs should die. Their syntax
is ugly and inconvenient for processing, their functionality
is not enough for the real-life cases. They are almost useless.
Some time ago I've written a program, which took
a DTD and generated the YACC grammar from it.
Just reading the DTD into the memory was a challenge,
because there was no reasonable API to work with
DTDs.
So it starts from the simple question: "Why do DTDs use
non-XML-ish syntax" ? The next question could be :
"OK, the syntax should be changed... but if changing
the syntax - why not replace macroprocessing with
something better?"
Rgds.Paul.
|
