One of the simple sounding, yet complex, bifurcations in software architectures is between static and dynamic typing of both code and data. The split is most commonly recognized in programming languages.

Languages such as Pascal, Java, and Ada lean heavily towards a statically typed view of the world. All variables are declared before they are used. All variables have one, and only one, type associated with them, which is allocated at design time and never changed at run- time. Data objects persisted onto disk or on the Web must be of a known "type" in order to be readable by statically typed languages. Apart from some fundamental types like strings, integers and so on, type information must be compiled into applications prior to execution.

Languages like Python, Scheme, and Basic lean heavily the other way -- toward a dynamic view of the concept of "type". Variables come into existence as required; they don't have to be etched in stone at compile time (indeed they may be no "compile time" at all). Variables can change type dynamically in a running program. New types can come into existence completely on the fly without even shutting down the applications.

As is the case with all simple sounding bifurcations, this one is not that simple -- not by a long shot. So-called static languages often provide dynamic features. Java's Bean architectures, for example, are based on dynamic discovery of type information (introspection). The "reference to arbitrary object" facility in most statically typed languages allows you to subvert static typing where required. Conversely, so-called dynamic languages often provide static typing features. Some, for example, let developers promise not to change the type of a variable at run-time and thus allow the compiler/interpreter to be cleverer in its dealings with the variable both at compile time and at run time.

Switching now from code to data, both static and dynamic approaches are to be seen in data as well. SGML, XML and HTML all exhibit leanings one- way or the other, but the differences between the three big "MLs" on this topic are interesting.

SGML is quintessentially static in its philosophy towards typing. Everything has a declared type, every object (entity, element, attribute) must be declared before it is used. SGML tools pride themselves on their ability to catch problems before they occur by forcing everything to be just so before proceeding.

HTML, and the Web in general, is quintessentially dynamic in its philosophy. Resources (referenced by URIs) come and go. To link to a resource from, say, a Web page, just name it. The very existence of the resource linked to is not determined until run-time -- when you click the link. If the resource exists, then you see it. If it doesn't, then you get a 404 -- the Web equivalent of a software run-time error.

XML fall sin-between SGML and HTML when it comes to typing. The DTD enforced requirement to declare all elements and all entities clearly comes from the SGML static typing heritage. Well formedness, open content models, XInclude, and Namespaces are all clearly from the dynamic school of thought.

Both approaches have pros and cons but if I could only choose one, I would definitely choose dynamic typing. Programming languages are becoming more and more dynamically typed over time. Static languages (such as Java) are developing dynamic features much faster than dynamic languages (such as Python) are developing static features.

The Web itself is an excellent example of a system that trades off more run-time errors (i.e., 404s) in return for greater architectural flexibility. (Can you imagine having to "declare" every resource your Web pages will link to?).

The opposing static versus dynamic view of the world is swinging into full view in the Web Services arena at the moment. WSDL is an excellent example of a static approach to typing. The REST architecture discussed in an earlier article is an example of a more dynamic approach to typing. At this stage, an overwhelming emphasis appears to be on the static approach to architecting Web Services. The situation is made more interesting by the fact that static entry points to Web Services can and will exchange dynamically typed XML data.

The collision between the static and dynamic worldviews within the Web services field is guaranteed to generate some interesting fireworks in the years ahead. My money is on the dynamic view prevailing in the longer term but a re-run of the PASCAL/SGML -- thou shalt declare everything FIRST -- days seems inevitable in the short term.