Challenges: Some Ugly Truths
The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition.
Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper.
A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition.
And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5]
But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.
Gary Edwards on 02 Jun 12Nice article from Scott M. Fulton describing Microsoft's iron fisted lock on government desktop productivity systems and the great transition to a Cloud Productivity Platform. Keep in mind that in 2005, Massachusetts tried to do the same thing with their SOA effort. Then Governor Romney put over $1 M into a beta test that produced the now infamous 300 page report written by Sam Hiser. The details of this test resulted in the even more infamous da Vinci ODF plug-in for Microsoft Office desktops. The lessons of Massachusetts are simple enough; it's not the formats or office suite applications. It's the business process! Conversion of documents not only breaks the document. It also breaks the embedded "business process". The mystery here is that Microsoft owns the client side of client/server computing. Compound documents, loaded with intertwined OLE, ODBC, ActiveX, and other embedded protocols and interface dependencies connecting data sources with work flow, are the fuel of these client/server business productivity systems. Break a compound document and you break the business process. Even though Massachusetts workers were wonderfully enthusiastic and supportive of an SOA based infrastructure that would include Linux servers and desktops as well as OSS productivity applications, at the end of the day it's all about getting the work done. Breaking the business process turned out to be a show stopper. Cloud Computing changes all that. The reason is that the Cloud is rapidly replacing client/server as the target architecture for new productivity developments; including data centers and transaction processing systems. There are many reasons for the great transition, but IMHO the most important is that the Web combines communications with content, data, and collaborative computing. Anyone who ever worked with the Microsoft desktop productivity environment knows that the desktop sucks as a communication device. There was
