[jdom-interest] Internal DTD subset verification

[Philip Nelson]

--- Elliotte Rusty Harold <elharo at metalab.unc.edu> wrote:
> At 11:04 AM -0400 5/7/02, Alex Rosen wrote:
> 
> >The line with most APIs is, protect users from
> >themselves when it's cheap but not when it's expensive, because otherwise
> >they'll use a different API. That's the line I would draw.
> 
> We are not merely protecting the developers from themselves. We are 
> protecting  all of the developers' clients and customers and users 
> from that developer by not allowing that developer to make certain 
> mistakes. We are helping to keep the XML environment pure by 
> enforcing the deliberately and rightfully draconian rules of XML.

No, you are saying that in no case should a programmer have any say in how to
enforce the "deliberately and rightfully draconian rules of XML". It doesn't
matter that the characters may have been thourougly screened elsewhere.  Never
mind that the parser at the other end would do exactly what it is supposed to
do and reject a document that isn't well formed. In fact, the xml aplication
model seems to be one where primary responsibility for checking documents is
given to the parser.  The client's system is protected by their parser, the
dtd, the schema and this is done when the document is loaded.  Producing
documents has been an afterthought in many apis, often left as string
manipulation exercises for the programmer.  It simply doesn't make sense to
define an architecture where you have to verify every single character going in
and out.

Here is the jdom mission statement ...

There is no compelling reason for a Java API to manipulate XML to be complex,
tricky, unintuitive, or a pain in the neck. JDOM is both Java-centric and
Java-optimized. It behaves like Java, it uses Java collections, it is
completely natural API for current Java developers, and it provides a low-cost
entry point for using XML.

While JDOM interoperates well with existing standards such as the Simple API
for XML (SAX) and the Document Object Model (DOM), it is not an abstraction
layer or enhancement to those APIs. Rather, it seeks to provide a robust,
light-weight means of reading and writing XML data without the complex and
memory-consumptive options that current API offerings provide.

...

Not much doubt about where the original goals were. Light weight and memory
consumption are mentioned prominently. Java centric. These goals are what first
attracted me to JDOM along with the hope for a simpler api to XML, something I
didn't understand well at all.  XML seemed at the time to offer real help in
the kinds of applications I have made my career doing.  DOM was clunky AND
untenably slow.  For those kinds of applications where you type the command and
can wait while your cpu pegs at 100% for 5-10-30 seconds and you get the
desired result, the performance is no big deal.  For the kinds of things I
typically have to deal with, this is not even close to good enough.  If JDOM
can't live up to the light-weight goal, nothing else will matter.  While the
DOM api may be clunky to use, most developers can manage it, more tools support
it, there are more books about it, etc etc etc..  If JDOM doesn't beat DOM in
memory use and performance, it will have failed in it's most important goals.