[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Goodbye to textual applications?


advantages of dtds

----- Original Message ----- 
From: "Joe English" <jenglish@f...>


> 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 
thrown up.
 
> (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 
feedback ).

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 
*only*. 

Honest.

 > > 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
> grammars.

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 
ago.

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 
mapping ). 

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 
DTDs APIs. 

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. 

Rgds.Paul.



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.