RE: XML is _post_ OO

[Eric Bohlman <ebohlman@earthlink.net>]

5/22/01 3:19:49 PM, Michael Brennan <Michael_Brennan@allegis.com> wrote:

>The success of XML does point to one fact that more sensible developers have
>known all along: OO is not a panacea, and does not solve every problem. OO
>just happens to be the best paradigm for software development that anyone
>has come up with, so far. XML hasn't changed that. But OO does not address
>the situation very well in which information needs to be external to an
>application and shared with other applications (which may run on a different
>platform, use a different programming language, have different runtime
>libraries available, etc.). It also does not deal, very well, with more
>dynamic information models that are not very explicitly defined at
>development time. XML is very useful for these sorts of thing. OO is still
>very useful as a programming paradigm for dealing with XML, but when
>information needs to be shared, it is important to factor out that
>information model from the OO model that is specific to your own use of that
>information.

Or, inspired by a "paper" published in the _Journal of Irreproducible Results_ some years back, you 
could say that building a better mousetrap is such a hard problem because you don't get to define 
the specs for the mouse.  The situation you're talking about is one where you have to engineer 
*parts* of a system that is not engineered as a whole, especially not by you.  Engineering 
methodologies that are intended to create self-contained systems won't work very well in such a 
case, and trying to shoehorn the design of the parts into a methodology that assumes that you're 
designing the whole will dissipate much of your effort into heat.

XML is actually (as Mr. Snell pointed out a while back) an extremely cumbersome and inefficient way 
of representating data *if* (and I'm inclined to say "only if") you have complete control over 
everything that generates and processses that data, and you can reasonably expect to maintain such 
control over the useful life of the data.  But in the Real World, that's the rare exception, not 
the rule.  There's an Outside World, and it runs the way it does, not the way it "should."  Even 
purely automated computer-to-computer interaction shares a fundamental feature of human-to-human 
social interaction: no party can expect to get their own way all the time (at least not for long).  
Methodologies for the design of self-contained systems, OTOH, operate on the assumption that the 
designer *is* getting his own way.