Lists Home |
Date Index |
----- Original Message -----
From: "Joe English" <email@example.com>
> Paul T wrote:
> > 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.
> Maybe for you. For me and many others, DTDs are very useful,
> suitable for many real-life cases, and more legible than
> schemas encoded in XML instance syntax.
Of course it is 'for me'. I think it is implied that all the oppinions on
this list are subjective. However, DTDs fail not only for me.
DTDs failed for W3C XSL FO WG as well.
Look, I have a clear case: XSL FO W3C standard can not be
expressed with the DTDs. You can keep ignoring this fact, but
it is still a fact. If you and many others are very happy with DTDs
in the real-life, let us see what's the situation with your cases,
because I never seen a single DTD-based solution without
a problem. I'd say that DTDs work good only for hello-world kind
of applications. I may be wrong, of course.
I tried using DTDs, I found that all the time it ends with writing
yet another validating layer. Or it implies giving up the quality
of validation, but I just don't like when application ignores the
bad data silently. Or when some uncaptured exception gets
> (Although I'm probably going to switch to Relax-NG "unofficial
> syntax" in the future; it has all of these advantages and more.)
What are 'these advantages' ?
1. DTDs are powerful ( comparing to? )
2. DTDs are intuitive ( that's why people are sending me
bunch of love letters after using the dtdgenerator frontend, because
they just *can not* write the DTDs. You may be suprised *how*
popular is DTD generator frontend. Sometimes I have an impression
that nobody writes these DTDs by hand, thanks to Michael Kay),
3. DTDs work well for many people ( and every time I talked to
somebody who tried using DTDs in the real life - I got only negative
We live on different planets. I think that on your planet the weather is
always nice and people write DTDs for their XML projects. Could be.
For last years I never seen a single XML-related project ( and I've seen
about 10 of them ) using DTDs for the purposes other than documentation
> > Some time ago I've written a program, which took
> > a DTD and generated the YACC grammar from it.
> Naturally, this is not going to work very well.
> LR parsing is a lousy way to process tree-local
What do you mean by 'not very well' ? It worked just fine
for my task for that moment. At that moment there was
no validating parser in perl ( maybe there is still no such,
I don't know ), so I've written some kind of it
in 3 days or so. There were some funny things with the
whitespace and mixed content, but other than that YACC
can validate XML pretty well. And because YACC has
binding, not only you can see if XML file matches
the pattern, but you can also access the part that you need.
I think it worked *much* better than DTDs. I don't know
what's wrong with those LR and 'tree-local' words, but if
you look at DTDs and YACC you may see that there is
not too much difference ( and for some subset of XML
there is no difference *at*all* ) so you *can* map a significant
part of DTDs into YACC. Again, Mixed content and whitespace
processing is a real problem, but one can make some brutal
decision ( my favorite is 'if it is an empty string - do not report
it as a token' ) so it is kinda solvable. Also, you may find that
the next step after YACC ( metamata Java CC) has some things,
like 'lookahead', so it is actually not all as simple as it was 10 years
Maybe some day I'l wrap that mapper into a demo, so that
you'd see yourself, that it works (so does PXDB, that maps
some broad subset of XML into 5 SQL tables and I have
mixed content on the way ... ).
However, I agree that using 30 years old machinery (YACC)
is not really interesting and there should be better ways.
(That's why I have not spent more than 3 days with that
At the moment, I don't see a really nice solution out there.
Relax NG is of course the most interesting and it is also
better than TREX, but still ... not ideal. And I'm not sure if
it is a correct 'direction'. I have no solution yet.
'Use YACC' was not a really general solution - it was
an example, explaining why I become not happy with
As to non-XML-ish syntaxes.
Being the person who've implemented XSLScript
(XSLScript is non-XML-ish syntax for XSLT and has been
implemented long time ago, when non-XMLish syntaxes were
considered politically incorrect ), so being such a person I sure
don't like XML-ish syntaxes at all, but elaborating on terse-xml
e t.c. would open another can of SML-dev, so I'd really hate to
discuss it here. I just got an impression that it may look like I'm
defending XML-ish syntax of XSD - I don't.