[
Lists Home |
Date Index |
Thread Index
]
As someone who works closely with people in the trenches who actually
have to work with this stuff, rather than someone who can or will argue
high level computer theory (I'm not a computer scientist), I think you
have some very interesting and valid points, but you've done what you
hate most about XML -- you've taken a simple language (XML) and created
a very complex argument against it.
XML at its core level is simple. It's *supposed* to be a network based
language. Specifically, it's intent is to, in the words of the spec:
"...to enable generic SGML to be served, received, and processed on the
Web in the way that is now possible with HTML"
Anything that lets me create an easily repurposed web site for a client
without digging through thousands of pages of HTML when it's time for
the client to make an update is worthy of a genuflect or two, as long as
we don't deify the people behind it. That gets scary.
Regarding DTD problems on BEA, the mistake may simply be running BEA
WebLogic. When using DTDs tied to some vendor's web site, well, use at
your own risk.
I'm an average developer, and I can cope just fine with XML. In fact,
XML is simple, it's consistent, and a pleasure to work with. And it's
great for OOP folks. I remember showing XML for the first time to a Java
developer for a site I was building some new architecture for, and she
said, "Oooh, objects!" The truth is, we ended up just using it for some
configuration stuff (this was before J2EE made that easier/harder). But
it served its limited purpose at that time perfectly.
> XSLT files are maintainable with the same level of ease as densely
> written perl. Developers asked to modify them routinely rewrite them
> because they can't figure out what the last guy was doing.
Best practice is only now coming into XSLT. Unfortunately, documentation
has not taken root as a big part of best practice yet, and I wish it
would. But a lot of code gets rewritten because there's a lot of bad
XSLT out there. I sure wrote my share of it early on. It's a very
different language for a lot of people who work at the production level
and aren't used to seeing it and don't have the time to study it. IT
departments are throwing XSLT at their staff and saying "do this" and
they are, but they're really winging it and learning it on the fly. It
seems to take most places about a year to start getting it right. I
mean, look at your average C++ developer who's building some app server
stuff and then consider his or her reaction when handed an XSLT project
for the first time. They'll hack their way through it, but they'll
usually write some pretty funky code to do it, and nine times out of ten
they'll drop in side effect scripting of some kind to get around
perceived limitations in XSLT that often don't actually exist. I've seen
it happen often enough to know that it's now what I expect to see when
visiting someone else's source tree. But that really has more to do with
bad IT management than the capabilities of XSLT. IT managers shouldn't
force their current staff to crank out XSLT if their staff knows nothing
about it. At least get them some kind of training.
XML is not a panacea and I'm sure it's misused by managers who try to
force it into situations it doesn't belong. But for my specific
purposes, creating re-usable content for web and print, it works pretty
nicely.
Chuck White
-------------------------
http://www.tumeric.net
Author, Mastering XSLT, Sybex Books
Co-Author, Mastering XML Premium Edition, Sybex Books
http://www.javertising.com/webtech/
|
