[
Lists Home |
Date Index |
Thread Index
]
On Sunday, October 27, 2002, at 05:32 AM, Amelia A Lewis wrote:
> Since I was rude enough
Quite. But you weren't alone. The best way to handle a troll is to not
feed it.
So I'll just maybe wrap this little fact finding expedition up and lay
my cards on the table.
I dislike XML.
I tried to like it. I really did. I read the specs. I spent time
trying to develop schemas and DTDs. I worked on schemes to provide
additional internationalization information in XML documents (when I
was chief architect of eTranslate). I did experiments with XML
formatted requests over HTTP before XMLRPC or SOAP (which I view as an
abomination) and I basically invented what Microsoft now calls SOAP
messages with attachments (using multipart MIME to send additional
documents) after experiments inlining HTML documents into XML
Processing Descriptors produced horrendous performance problems with
excessive escaping and unescaping. I proposed the MIME thing on Don
Box's discussion list. After much derision on the mailing list from
people just like you, MS published their draft spec for attachments
about 3 weeks later. It looked almost exactly like my proposal.
I also did the Objective C wrapper for expat that a lot of Mac Cocoa
programmers use.
Lately, I'm working for a company that is exchanging HR information
with job boards (like monster and hot jobs) - which has its own working
groups trying to define HRXML.
So far, I'm finding:
1) XML Tools suck - they're little more than syntax coloring editors.
2) The Hype is at the same level as the hype was for AI and it can't
possibly live up to it. It should be written <genuflect>XML</genuflect>
3) The weight of the processing model is really really heavy. As an
example, using URLs to reference DTD's causes all sorts of problems for
computers when they're off the network. XML parsing simply halts.
This is especially annoying when running something like BEA WebLogic on
your machine because you're doing a web app. BEA stores config info in
XML which references some DTD at BEA and the server simply won't start
if that server isn't available. You can argue this is a misuse of XML
- I think so - but its one of those things thats going to hurt people's
impressions of XML.
4) Schema is really an insane spec. I mentioned just the data types -
too many too complicated. Do we have to specify the number of bytes
for the ints? Thats a physical issue and for this Smalltalker it
doesn't even make sense (Smalltalk handles arbitrary sized numbers).
5) Like C++, the average developer can't cope with the excessive
complexity XML introduces relative to its value. The average
programmer doesn't really know the difference between nonnegative int
and positive int. In fact, the schemas I'm getting from biz partners
(the couple that want to use XML because everyone is using it - and its
less than half) are AWFUL.
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.
I used to be a C++ guru - zealot in the extreme. Language lawyer level
guy. I worked in it a few years. I walked away from it one day and
never looked back because I just got tired of working around its odd
corner cases. I then spent some time trying to figure out why the
people who pushed C++ liked it. I concluded that they were all very
smart people. Too smart. Because I figured out that they loved
working in C++ not because it was more productive (its not). They
loved it because the thing itself is the damnedest puzzle. It
entertained and challenged their intellect to work with it. I'm
beginning to suspect the same about XML.
6) From the stand point of business process and enterprise architecture
- XML is an evolutionary step backwards. Hierarchical databases were
abandoned for relational models long ago and systems made out of lots
of little scripts gave way to more centralized object model
architectures because centralization of business logic is more
manageable. Model View Controller architectures were created
explicitly to move the processing knowledge closer to the center. XML
"transformations" puts us right back into the same position we were in
when all the business rules were encoded in the UI and batch scripts.
It disperses knowledge without any underlying organizing principle
other than "a bunch of files".
http://ventedspleen.weblogger.com/discuss/msgReader$21?mode=day
I need to write the follow on to this piece but it will focus on point
6 above plus the assertion that XML fails as both a markup language
(markup shouldn't require well-formedness) and as a serialization
format (too hierarchically oriented, verbose, and weirdly structured
relative to ER models).
7) While there is lots of heavyweight support for reading XML, there
isn't any help for writing it from various other data structures.
So there's my viewpoint. Take it for what its worth. Am I trolling?
Maybe just a bit - but I'm trying to gain a viewpoint on why people
think this is moving forward. I really don't "get it".
Because it runs against what I've found to be true in my own work.
Centralize business logic and ER/OO modeling to model your business
entities and processes. This works well when the company has the
discipline to pick an implementation language and stick with it and
focuses all developers on this goal.
But of course, XML philosophy says the opposite. Where is the business
rule repository in XML? Its just carpentry, not architecture. I'm an
enterprise architect with many years of telco, cable, and ecommerce
experience and I see it as harmful to the practice of my craft.
Have you considered that you're breathing your own exhaust? You don't
even agree amongst yourselves on what its good for. Thats the
impression you've left me with. That and some of you have built
reputations on pushing snake oil for a long time and dare not back down
now.
Maybe its time for some fresh air.
|
