Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Note from the Troll
 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
