Xatapult's XML Blog

26/03/2012

XML Database Marketing

Filed under: Opinion — xatapult @ 13:06
Tags:

XML databases are usually marketed as, well, just databases: Applications in which you can store vast amounts of data, combined with mechanisms to index and query the stuff. That sounds logical (given the name of the product category) but is IMHO only half (or even less) the story. After some deep immersion into eXist for several months (and some more shallow experiences with MarkLogic and 28msec), I do think this product category has a much wider application than its name of it implies.

XML Database decomposition

The main cause for XML Databases having a broader application than you might expect is in the way these product are build up. Here is a high-level look at the main components:

  • Data storage and indexing: Of course, all XML Databases have XML data storage and indexing capabilities. That’s the core of the product. Duh…
  • Processing Engine: On top of this data storage is always a processing engine. This engine can run XQuery programs for querying and manipulating the database. Besides XQuery it usually implements other X languages like XSLT, XProc, XInclude, Schema validations and the likes.
  • Libraries: All XML Database vendors add additional libraries to their product. These libraries enable you to do a lot of useful things directly out of the box, like working with different file formats, interfacing with JSON, using the various cloud services, etc.
  • Web server: On top of all this sits a web server that enables easy communication with the world. Not only with your browser but also with other systems through SOAP and REST.

Now, just imagine, forget for a moment that an XML Database has to store XML data. What do we have left? A very, very, useful application engine for running software written in XML aware languages!

Of course you can argue that processing XML can be done in any language. True of course, but if that’s mainly what you do, you’re much better off in an environment where XML is handled natively. Try doing XML querying and manipulation in, for instance, Java as opposed to XQuery and you’ll see what I mean. A matter of the right tool for the right problem.

So any software that processes XML as its main business, with or without the need for large scale storage, is a likely candidate for using an XML Database…

Some use cases for XML Databases

Now if we assume for a moment that large scale XML storage is not a given but an option (albeit of course a very useful one), what would be some likely use cases for XML Databases engines without really needing their storage capabilities:

  • Websites: Yes, “just” websites. Now we of course already have a plague of languages and technologies to deal with this, but really, writing a web application in X languages like XQuery and XSLT is not such a bad idea at all. Why? Because HTML is almost XML (and even better, XHTML is XML). The strength of this approach comes from using the same base technology (XML) on all layers (storage, processing, output generation) on the server. No impedance, no ORB’s, no layering glue code, no nothing. Just XML everywhere (well, almost everywhere: we still have Javascript on the client but even for that there is some XML light at the horizon).For a more thorough explanation of all this, please have a look at Adam Retters’s talk at XML Amsterdam in 2011.
  • Another good example of where an XML Databases will come in handy are XML Publication engines. These engines take narrative XML as input (for instance written in DITA or TEI or Docbook) and produce outputs like e-books, PDF’s (through XSL-FO), HTML pages and the likes. You’ll find this software mostly in the realm of publishers.Again: The storage here is not really needed but you do need to analyze and convert the XML large scale.
  • Conversion and validation engines: There are lots of different, large and small, applications in use that do XML conversion and/or validation. For instance reporting over XML log files, checking incoming data from another system, etc. With an XML Database running, the software for that is easy to do.

Bottom line

I think XML Database vendors are not doing themselves a favor: They miss large parts of the potential market, just by using the word “database” so prominently on their products.

So what would be a better product category name? Hmm… “XML Processors”, “XML Engines”, “XML Enablers”? Since I’m not much of a marketing guy, I think this is the point where the real marketing and brand name exerts should step in. Who dares?

 

Advertisements

2 Comments »

  1. Hi Erik,

    Thanks for an interesting article. So many interesting standards beginning with X, and so little time. I should be practicing my XQuery skills but instead I got inspired and wrote a blog post in reply: http://sgmlguru.blogspot.se/2012/03/query-vs-change.html.

    Cheers,

    Ari

    Comment by Ari Nordström — 26/03/2012 @ 14:33 | Reply

  2. […] friend and fellow XML geek Erik Siegel writes about marketing XML databases in his latest blog post. Basically, Erik says that XML database vendors aren’t doing themselves any favours by […]

    Pingback by Query vs Change | sgmlguru.org — 14/01/2015 @ 18:35 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: