Starting work for Mark Logic

In about a week, I'm going to start working for Mark Logic, who make the MarkLogic Server, which stores and queries XML content.

I've been primarily an "Object Guy" for years now, and am interested to see how systems will evolve that are oriented around transforming XML.

Mark Logic's CEO writes in his blog:

Elimination of three impedance mismatches: Java/XML, XML/relational, and Java/relational. Java is object-oriented, XML is hierarchical, and relational databases are tabular. The mapping between these three different data models generates a lot of zero-value-added work in developing an application. When you’re XML top-to-bottom, poof, that work’s all gone.

Which really makes me think about how to best build systems that are XML-centric. Previously, I'd thought about XML as a data format for data interchange or storage, but not as a true architectural decision.

Actually, XML still isn't an architectural decision -- it's the ubiquity of any data format that changes things, not the use of XML per se. When there are impedance mismatches that have to be dealt with, it's natural to map everything into and out of objects (hub-spoke model) and gain all the advantages of modeling the core of the system as objects. But when there there's an opportunity to drop all the impedance mismatches, objects get dropped as well.

Now I'm considering that the ubiquity of XML suggests that some systems should be fundamentally functional -- operations and transforms that are applied to XML Trees. Objects, in contrast, are all about encapsulating data and functions together.

So the question that I'm excited about answering is what new approaches work in an XML-centric world. Scala comes to mind, since it is object-oriented but also functional, and has native XML support. This paper, Scalable Programming Abstractions for XML Services gives some details about that.

At this point, I'm still not sure, so watch this space....