XML Content Management: Where to Start?
So I have a lot to say and every time I think about how I'm going to say it I get tangled up in the question of where to start and how long will it take me to get to a coherent explanation of my ideas. I recently finished reading Jared Diamond's Guns, Germs, and Steel, and before that, Collapse. Both of these books present fundamentally simple ideas but Diamond takes great care (and time) to build a solid foundation for his conclusions. I fear I have the same problem: my approach to XML content management is fundamentally simple and in fact leads to fundamentally simple solutions (in the sense that they are easy to describe and understand and no more difficult to implement than they need to be).
In the case of Guns, Germs, and Steel, Diamond contends that all of the current differences in terms of wealth, population density, technological sophistication, and political sophistication between different human populations can ultimately be traced to differences in geography. Having read the book this conclusion seems both obvious and unassailable, but it flies in the face of thousands of years of essentially racist thinking about why, for example, Europeans conquered the New World and not visa versa. Collapse says essentially "Where human populations have risen and then crashed the crash has come just as those populations reached the heights of their progress because, in reaching those heights, they overburdened and ultimately destroyed their environments [Easter Island, Greenland Norse, Haiti]. At the same time, some populations have made the conscious choice to adopt a sustainable life style and have not crashed [Japan, Iceland Norse]. The Earth, like Easter Island, is a closed system that we can choose to destroy or sustain." There, I've saved you reading 1000 pages. Of course, there are a lot of details and not everyone agrees with his reasoning or facts.
In the realm of content management I have similarly simple ideas and principles that I think are both obvious, once presented, and sound. But they to some degree go against at least 20 years of practice and marketing and not everyone agrees with my reasoning or facts. But I don't really have the time or energy to write the Guns, Germs, and Steel of XML content management, which is what I fear I must do to not come off as a naysaying crank.
Excuse me: bitter, naysaying crank.
Another problem is that the scope of the discussion is broad enough that it would take a lot of effort simply to develop a coherent outline of the discussion in order to drive the writing. I do not at this moment have in my head a well-defined sequence of topics that, when presented will lead inexorably to my unassailable conclusions. Rather, I have a lot of thoughts that all connect back to the subject in one way or another and they are all clammoring to be presented first.
So I'm going to try using this forum as a way to do a first draft attempt at writing these things down. Having done that, maybe I can then organize them more formally and carefully into something approaching a coherent book.
So I appologize in advance for what will almost certainly be a wide ranging, often rambling, but hopefully informative exploration of XML content management in all its glory. During this process I encourage you to ask questions, present counter arguments, provide comments (hopefully constructive).
Some of the core ideas I'll talk about here have been presented in various papers at various conferences over the years, especially "SnapCM" (Snap-shot based Content Management). A Google search on my name and on John Heintz should bring you to them fairly quickly. Unfortunately I don't have a reliably persistent online archive of these papers but they are out there.
Another caveat: the company I work for, Innodata Isogen, is partners with most, if not all, commercial vendors of XML content management systems. Most of these systems fail to meet my personal criteria for what a "proper" XML content management system is and does. It is not my intent to impune or criticize any particular tool or company. Rather I want to communicate my considered opinions about how XML content management should be done. To the degree that those opinions are not reflected in a given tool it may come off as criticism of that tool. That is unavoidable in any comparative discussion of technological solutions to complex problems. These are my opinions, not necessarily those of Innodata Isogen.
By the same token, in my professional role as an XML Systems Integrator, if you ask me for my professional opinion about what XML content management tool to choose, you can be assured that that opinion will reflect the ideas to be presented here.
One further note: Innodata Isogen (and ISOGEN before it in its various corporate forms) has always prided itself on being vendor neutral. That is, we do not, as a matter of policy, have exclusive or preferential agreements with any of our partners. This is because we value our ability to make tool recommendations that are based solely on a particular client's requirements and the relative strengths and weaknesses of the tools available at the moment. So if you ask us for a tool recommendation we should, per our policy and practice, make that recommendation based solely on the technical aspects of the case.
Unfortunately, many of our clients come to use having already chosen a system. This is usually where the pain part of our jobs comes in....
So enough prolog and preamble (or is that preramble?). Next up: diving right in to XML content management the Dr. Macro way.
Labels: XCMTDMW "xml content management"