[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Application Design

• From: Mike.Champion@S...
• To: xml-dev@l...
• Date: Sat, 11 Aug 2001 10:21:59 -0400

> -----Original Message-----
> From: Al Snell [mailto:alaric@a...]
> Sent: Saturday, August 11, 2001 6:12 AM
> To: Mike.Champion@S...
> Cc: xml-dev@l...
> Subject: RE: Application Design

Thanks for such a thorough response.  I think I need to learn more
about PHP; my response took a more generic "procedural vs. declarative" 
spin.  It sounds like PHP (like XSLT) has a bit of both characteristics.  

The essence of my point is not that XSLT is better than PHP, but that
presenting a unified XML view of a heterogeneous back office" full of
different DBMSs, other applications, and assorted legacy cruft gives you
lots more technology choices, lots more ability to use existing skills, and
generally a lower "total cost of ownership" than gluing it all together with
code to generate Web applications.  If PHP could replace XSLT in that
overall scenario, I'd not complain one bit... but if you take the XML view
out entirely, I think you're losing something very valuable.

> Recently, that company is starting to move over to an 
> XML/XSLT model. When asked why, the person who made this 
> decision said he didn't  know what the
> technical issues were (he was a manager) but he'd read a lot 
> of magazine articles and stuff saying that XML was the wave of the future 
> so they'd better "catch up". 
> Eurgh! What a way to make a technical decision! :-)

Sigh. Worse is Better. But that's the world we live in ... if you know
someone selling passage on the next starship to a better world, let me know!

But seriously, in a world where "nobody gets fired for choosing X" (where X
was IBM in the 1970's-1980's, Microsoft in the 1990's, and maybe XML in the
next decade )... does someone do their clients a service to say "NO! X is a
technically inferior solution!  Use Y (CDC, Mac, OS/2, X, whatever)
instead"?  Maybe, but think of all the little ways it pays to just "come to
the dark side, Luuuke" ... You get more choices of tools, a larger pool of
experienced people, a high likelihood that there is some widget you can
buy/borrow to do little obscure things, etc.  For example, let's accept for
the purposes of this discussion the proposition that PHP is technically
superior (in skilled hands) to XSLT for writing templates for generating web
applications from back-end data sources.  BUT I can buy lots of books to
teach newbies about XSLT, I can get free XLT engines for virtually any
modern development platform, I can bet that community colleges are (or soon
will be) teaching XSLT to most people getting an entry-level IT degree, I
can buy "Visual XSLT" tools from several vendors ... is any of this true of
PHP?  How MUCH better than XSLT would PHP have to be to overcome all these
factors for the Pointy Haired Boss to be making the wrong decision by going
with XML because it is "the wave of the future?"  And how much longer will
PHP be technically superior with all these people competing to make their
XSLT tool the most powerful?

In other words, the manager in your example is NOT making a technical
decision, but a business decision, and the right technical decision might be
the wrong business decision. 

[Disclaimer: Forgive my lack of dedication to "the right thing," but as a
former OS/2 weenie, I got burned by being on the wrong side of the "but Y is
technically superior to X!!!" issue back in the early '90's. Back then, OS/2
was "technically superior" to Windows 3.x ... but Windows had the books, the
components, the people, the vendors, the visual tools, the hype, (the
illegal monopoly, but we won't go there!) ... and time on its side so that
MS sooner or later got the bloody thing to work right.]

• Follow-Ups:
  • RE: Application Design
    • From: Al Snell <alaric@a...>

• Prev by Date: RE: Application Design
• Next by Date: RE: Application Design
• Previous by thread: RE: Application Design
• Next by thread: RE: Application Design
• Index(es):
  • Date
  • Thread