Lan Barnes wrote:
Am I to surmise that XML like email or port 80 has been seized upon as the
one way we're going to express everything, from jpegs to pi?
That's quite a lot of it. Two abuses of XML:
1) The "ant" build tool
"ant" is a replacement for make for Java projects. It uses XML for its
build file. It captures dependencies quite well. It's okay.
The problem occurs when you need to express something like "collect the
files in this directory, do action X to them, depending upon action X,
put them into directory Y or X." You can fudge this inside the
"antfile", but what you really want to be able to do is express a
program. At that point, you are in bondage. There is no programming
language that uses XML as its underlying representation (thank god), so
you begin writing external "tasks" and you start pushing your build
logic into those.
In my opinion, things like SCons are the way to go. Add some extensions
for common build tasks to a programming language rather than trying to
graft programming language extensions onto a build system.
2) XQuery, XPath, etc.
These are mini-languages *in XML* that attempt to create a mechanism for
pulling data out of the XML. Ugly, nasty, dumb. Everybody hates them
and the smart people just suck the XML into their favorite programming
language and do the processing there with less fuss and confusion.
Agreed, but data driven programs can be way-cool when done by someone who
knows how.
I consider all programs to be data dirven, but I'll let you clarify.
My take on XML based on what little I know of it is that it's a nice way
to record a small body of relatively static data that you don't need much
history on (unless putting it in SCM is planned), but that it really pales
beside the power of a data base server, relational, hierarchical, or of
just about any design.
XML should be used when you need to read the data once at file open and
write the data once on file close. Surprisingly, that's actually a
*lot* of cases. For example, OpenOffice using XML is *good*. I use XML
as the on-disk format when I write CAD tools until performance starts to
suck. Using XML for configuration files is okay although I really
prefer code in configuration files. Low performance persistence is
okay, too.
The problem occurs when people try to shoehorn XML into places it should
not be. It should not be used as an active database. It should not be
used to store high-density numerical data for manipulation. However,
all of those should be *exportable* to an XML format.
My general rule is: if I'm about to write a file to disk that you will
later parse, no matter how "simple" it is--its time for XML. Switching
off of XML falls under the optimizations phase.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
