[jdom-interest] Use Cases (was: Another Element.setName reque st)

[philip.nelson at omniresources.com]

> 
> <grumble>
> 
> You know, the problem with requiring a "use case" for 
> infrastructure development
> is that you often end up with a system that can only (easily) 
> do the things you
> had already invisioned ahead of time. At some point, you hav 
> to just say "I don't
> know of a use case, but XYZ makes the system more generla and 
> flexible" and
> then later on  someone can do something cool with it. If we 
> always demand a
> use case before doing something, we have to think of 
> everything now... maybe
> that is legit in the business world, but some people just 
> like to do something 
> cool :-)
> 
> </grumble>

Because of your many insightful posts, I am going to risk an out 'n out war
;^)

Please note that these comments have nothing to do with setName.  There was
a reason it was done that way originally, though I don't remember it so now
I suppose we need a better reason to change it.  And, an xml editor may well
be a valid use case.

Requiring valid use cases should be legit in the business world but sadly it
usually isn't done that way.  DOM was probably done with more of the general
use in mind and didn't produce something that many people want to use.  And,
what I want is:

- an api that makes xml easier to use than csv, fixed length record or other
flat file formats
- an api that can fully participate in the standard xml infrastructure
- an api that I almost never have to go to the docs to remember how to use
- an api that if I have to go to the docs, doesn't kill me with scroll
blindness
- an api that is fast enough that I'm not afraid to put in high volume
situations
- an api that is flexible enough and at a low enough level that if I really
do need
some feature that isn't provided, I can write it and implement it without
heavy compromises

With an api that meets these criteria, I can do cool, I can do big and I can
and may do it often.  JDOM still has room for improvement in most of these
areas but I really think it's better than other alternatives I've worked
with so far.  Since putting in features that *may be useful* can affect more
than one of my criteria, I'm inclined to resist a little.

Where people (including myself) are struggling with xml is understanding
exactly how it fits in their programs.  XML comes along and programmers
instantly see that here is a way of representing information that actually
looks like the way information our classes is modeled.  It's very tempting
to think that XML, with all it's associated standards, vocabularies, apis et
al could replace how programmers represent internal state in their classes.
But that is not what XML was concieved for and I think as these xml efforts
progress on thier own lines, there will be an even greater disconnect
between what a programmer specifically needs to accomplish in a class and
what the xml infrastructure provides.  To participate with xml, JDOM will
have to follow the xml world so the disconnect will apply to JDOM as well.  

Nobody struggles to extend a JDBC ResultSet and use them in a is-a
relationship with their business classes.  JDBC has a disconnected ResultSet
variant but it doesn't matter, that's not how people think of using JDBC.
Perhaps what this xml experience has really told us is that two dimensional
persistence and collection mechanisms in rows and columns such as databases
and flat files and vectors stink.  We want a tree based mechanism for
representing internal state.  Unfortunately, JDOM and XML with it's all
string representation of data, namespaces, schemas, yada yada yada, is
probably not that mechanism, at least in the common case.  XML is a great as
a Momento but is not going to replace large sections of my code anytime
soon.