Why Markup Languages Matter

by Simon St. Laurent

Related link: http://www.oreillynet.com/pub/wlg/3190



Tim O'Reilly emphasizes Paul Graham's observations on a sketching mode for programming. One of my favorite aspects of XML - and markup, more generally - is that it allows a similar improvisation process for data structures.



Tim notes:



"The reason why dynamic languages like Perl, Python, and PHP are so important is key to understanding the paradigm shift. Unlike applications from the previous paradigm, web applications are not released in one to three year cycles. They are updated every day, sometimes every hour. Rather than being finished paintings, they are sketches, continually being redrawn in response to new data. "


Data structures don't usually have quite the same need for constant flexibility as programs in flux, but far too much effort has been spent describing how XML lets people standardize their information exchange structures without taking note of the flexible process XML provides for getting there.



Perhaps the greatest innovation in XML 1.0 was that it discarded the dictum that all markup structures must conformed to a previously-created design. A large share of XML projects start with XML documents, developers building their structures around existing data to create sample documents rather than working in the abstract to build a set of appropriate structures which are then serialized. There's no need for a DTD or a schema at this stage, and many vocabularies don't even bother with such things when they're mature.



Like programs, markup vocabularies often make a shift from doodles and sketches to something more formal. Prototypes set patterns which are then set into something resembling stone, and rules take over from the joyful improvisation which brought us to that point. That seems to be a common pattern in technology, but it's worth celebrating the freedom available in less formal technologies, freedom which lets us make our own decisions and experiment on real content before choosing how best to solve a problem.



This doesn't mean that XML is easy for everyone to do; taking advantage of the freedom it offers requires skill. Improvisation can seem simpler at first than pre-planned structure, but good improvisation is itself an artform. Sketching comes in all levels of quality.



Perhaps my favorite aspect of XML is that the option of doing your own thing is always available, even after a committee has done its work. If you find a particular language rule-bound and contrary, you can use its rules to tranform its content (with XSLT or equivalent) into your own favorite flavor. Exposing the data and its structures gives everyone a chance to make it their own, and talk back in a language other systems can understand.



Ever want to hear jazz improvisation in the middle of a classical concert?