XML Technologies: Progress via Simplification or Complexification?

["Roger L. Costello" <costello@mitre.org>]

Title: Message

Hi Folks,

 

I observed a few days ago that XML is able to achieve virtually endless complexity through the use of a couple simple building blocks and a couple simple assembly mechanisms.  (I am continuing with the Lego analogy)

 

We all know that XML has its ancestry in SGML and XML is a simplification of SGML.  So, to achieve forward progress a complicated technology was simplified (progress via simplification).

 

There are other technologies which achieve great complexity with simple building blocks and simple rules.  For example, Cellular Automata.  I don't have enough experience to state for certain, but people tell me that the programming languages Lisp and Forth have simple building blocks and simple rules, and are able to achieve tremendous complexity.

 

It is asserted that all the amazing complexity seen is nature is achievable by using simple components and simple rules [1].

 

It occurs to me that in the development of a technology there are 2 approaches:

 

Approach 1 - Progress via Simplification

 

With this approach the attitude is "what are the simplest collection of components needed to achieve all the complexity required?".  Interestingly, this approach strives for greater complexity by removing complexity.

 

I think that typically the right collection of components is not found on the first attempt.  Typically, the first attempt produces a collection of components that are too complicated.  So, successive versions of the technology result in simpler components.  But these simple components can be assembled to produce results that are as complex (or more so) than the earlier components.

 

As noted above, XML is an example of a technology that made forward progress by simplification (of SGML).

 

For the past 6 months I have been putting together a demo.  The first version of my demo was horribly complicated.  Then I realized how to simplify it.  The second version was much simpler (and more powerful) than the first version.  But even the second version was too complicated.  After some time I realized that it could be simplified still further.  I went through 6 versions, each version getting simpler and more powerful.  My current version is astonishingly simple.  This experience humbled me (it's humbling to scrap all my hard work  and complex code in favor of something that is simple; somehow complex code seems more "manly") and it opened my eyes to the value of progress via simplification.

 

Approach 2 - Progress via Complexification

 

With this second approach the attitude is "the existing functionality does not give users all the desired complexity, so let's add more functionality".  Thus, greater complexity is achieved by adding more complexity.

 

As I look at the next-version of some of the XML technologies it appears that this second approach is being taken.  For example, with XSLT 2.0 and XPath 2.0 you are able to accomplish what was extremely difficult (or impossible) in 1.0.  However, this enhanced complexity is achieved by adding more complexity to the language.   I believe that XML Schemas 2.0 is going along the same path - more complexity by adding more complexity.  I am not trying to "knock" any of these technologies.  In fact, as a technology geek, I like the cool stuff that has been put into the 2.0 version of XSLT and XPath. 

 

But I keep thinking about the lessons I learned from my demo, and keep wondering if the 2.0 version of these XML technologies could have achieved the additional complexity by recognizing "the collection of components in 1.0 are wrong; they do not provide the desired complexity; let's scrap those components and find the right collection that's simple yet powerful". 

 

Perhaps for some things progress must come about by adding more complexity.  I don't know.  What do you think?  /Roger

 

[1] A New Kind of Science by Steven Wolfram.