RE: Application Design

[Mike.Champion@SoftwareAG-USA.com]

> -----Original Message-----
> From: Al Snell [mailto:alaric@alaric-snell.com]
> Sent: Thursday, August 09, 2001 8:53 PM
> To: fpgomez@rockwellcollins.com
> Cc: xml-dev@lists.xml.org
> Subject: Re: Application Design

> 
> One neat feature of PHP/ASP/whatever over XSLT is that:
> 
> 1) It's a real programming language. It can access databases, the
> filesystem, various networking APIs, .dbm files, etc
> 
> 2) It's imperative, which means that it can not only format 
> data into an
> output, but it can update the database too.

OK, this sounds like an interesting challenge ... why DO XML advocates think
that it is good for problems such as this.  I'd start with:

1) It's not a programming language, just data.  You don't need to care
whether PHP (or whatever) programming environment is supported on your
platform of choice.  Instead of writing procedural code that directly calls
the database, use a "virtual database", XML server, or the XML mapping tools
from the RDBMS vendor to pull out an XML view of the underlying data. You
can then use a vast array of tools, techniques, and products to manipulate
it from pretty much any development environment.

2) It's declarative (well, sortof anyway ... XSLT has certainly got lots of
procedural aspects to it), which means that you specify "what, not how".
You can focus on what you do best (which for most of us is *not* designing
optimized, scalable, multithreaded, robust system software).  You then
select an implementation of an XML parser, XSLT engine, schema validator,
DOM interface, XML database, etc. that meets your needs ... and switch to
another as your needs change.

3) XSLT in particular has a good story (on paper, and increasingly in
reality) for supporting changing output requirements.  You need to support
some HTML subset or WML for wireless?  Write another stylesheet. You need to
put out the data in your industry's new XML schema?  Write another
stylesheet.  In a programming/imperative architecture, you get to write the
same code over and over again; OK, maybe you can modularize your code well
enough to do this cleanly (after a few trips around the spiral model or
after a few Extreme Programming refactorizations), but you still need a
programmer skilled in your specific environment to do each new output
format.  XSLT editing tools are getting good enough so that it's not a big
stretch to think that a person with ordinary web design skills will be able
to do the stylesheets in the near future.

4) Portability. If the new boss comes in, decrees a move to a different
server, development environment, whatever ... and you mention that all that
PHP code you were responsible for creating will now have to be re-written in
C# (or whatever), you are NOT going to be first on the list when the bonuses
are distributed. If I say that maybe some stylesheets that I was responsible
for creating will have to be debugged in the new environment, but everything
should work in principle, I'm going to be his/her best buddy. It may not be
long before "nobody gets fired for choosing XML" becomes a cliche :~) 

5) Interoperability. Let's say you are asked to support some additional
system (within your enterprise or from a partner company), that provides
data for your website, or that your web application must update.  If you
build the original system on XML, the chances are awfully good that the
other system will have some sort of XML-enablement story, and you can
rewrite the stylesheets to incorporate the additional input source.  If you
built the original system with procedural code, you're going to have to
figure out the remote system's APIs, protocols, data formats, etc. and
either shamelessly hack or spiral around/refactor the code once again to
handle them.

X) What else?  Or what disadvantages of XML did Al forget to mention (other
than its verbosity, which I think he has reminded us of once or twice in the
past <grin>).


[Strange karma ... after a couple of years mostly bitching about XML on this
list, I find myself defending it against the RDBMS purists on one hand, and
now the "just write some code" position on another <grin> ]