XQuery and all things X
It’s been a while since I’ve posted. I’ve been finally catching up on all the xml-related technologies I’ve ignored for many years.
I won’t embarrass myself too much by talking about how much I had to learn, but I will say that I’ve finally arrived at needing to pick an implementation of XQuery. I’m looking at some of the implementations reviewed here. I happened to have stumbled on the eXist project first, so I may go with it. But it looks like there are some other good options. I’ve worked with BerkeleyDB in the past (using btrees to store timeseries data), so its implementation is intriguing.
At the moment, my project is focused on manipulating artifacts that conform to models that conform to either xsd/dtd or ecore. At the core of my system is a “co-evolutionary environment” which describes how transformations on either kind of artifact relate. Those language-specific transformations are implemented in the appropriate query/update language. For the xml artifacts, it looks like I’m committing to xquery. For the latter, I’m looking at QVT and related languages.
What can I say to defend why it took so long for me to get to this point? I entered grad school in 2002 when much of this stuff was still just a pipe dream. When I lived in SF during the summer of 2004, a friend excitedly told me about xslt, and it sounded good, but I didn’t really have a need to use it, so I left it alone. It wasn’t until some consulting I did in 2005 that I had to start working with xml — and I was already behind the curve by then.
But there was still some reluctance. I didn’t understand what was new. We already had relational databases. And OO languages. And several attempts at OO databases. Various kinds of remote procedure calls. And myriad other enterprise-y technologies, patterns, and architectures. Why muck it up with xml? Or at least — as an academic — why not just ignore this class of language until I solve the more fundamental (in my view a few years ago) problems of software engineering, and then graft those solutions into the xml world when I had them?
Acknowledging this other paradigm has helped me to see those software engineering problems more clearly. The hardest part of software engineering (imho) is exactly the problem of too many languages and paradigms that must work together. Earlier in my career I would have spent more time thinking about how beautiful the world would be if we could pick just one. But now it’s become part of the challenge — and fun — to abstract out the notion of a “language” and think about what kinds of tools and processes we need to make them all work together well.
Hopefully I’ll have more specifics soon on how I’m lashing together xquery and qvt in my “co-evolutionary environment”.
Posted by Adam Pingel @ February 12th, 2008 under Software Engineering.
Comments: none






Write a comment