The Pace of Innovation
February 19, 2003
In last week's column I suggested, only half-jokingly, that one motivation for new XML developments was to give techie journalists like me something new to write about. In making this silly claim, I was primarily reacting to what is widely seen as a kind of monotonous redundancy on the XML-DEV mailing list, an important part of the XML development community. If XML-DEV is any indication, the development community believes there are innovations remaining to be achieved with XML, but since the pace of innovation has slowed, returning to core, essentially contested issues seems to relieve some of the psychological burden of expecting new things and not getting them.
It was and remains an ideal time for this sort of reflection about XML, since -- as Edd Dumbill pointed out last week in "XML at Five" -- the XML specification recently passed its five year anniversary. It is testament, both to the importance of XML to several technical constituencies and to the Web itself, that people talk about a technical specification having things like "birthdays" and "anniversaries", to say nothing of celebrating such things. Perhaps another reason why so many people are disappointed with the slackening pace of XML innovation is that they are keenly over invested -- and I don't mean financially -- in the image of XML as the site and the engine of a particular kind of technical innovation?
My reading of the recent history of technology, but especially computer technology, is that a decrease in the rate of innovation in a core area, such as XML, can be interpreted in one of two ways: either as a failure or as precisely the mark of success. Things inevitably slow down, either because the technology wasn't as deep or as rich or as central as its earliest adopters believed and suggested, and so it has played itself out; or because it was, and thus it has reached, more rapidly than anyone expected, a threshold past which further innovation is very difficult to achieve. Given the scope of XML's use -- particularly the range of kinds of XML application, from documents to data -- it's hard to draw any other conclusion but that it has been exceedingly successful and has reached a kind of natural threshold.
Documents and Data, Again
But for all of XML's undeniable success, there remain significant problems. The most conspicuous of these, if we take an historical view, is surely the state of tools meant to aid in the creation of XML by humans. Every programming language has one, if not many ways to create XML programmatically, many of them clever indeed. But the "XML editor for humans" area remains underdeveloped, particularly if we judge maturity by reference to more than five years of complaints about and claims for more tool support, by both vendors and advocates alike. Have we all simply misjudged how hard it is to build XML tools, including editors, with which ordinary people can create XML content naturally and simply?
Rick Jelliffe suggested that the state of tool support has left at least one class of XML users, those in publishing, unsatisfied: "By making it easy for developers, we have a lot of software which is good for data transmission but still very little that is an advance for data capture". To which Jonathan Robie responded by offering a rundown of available, relevant tools, including "XML editors for writing structured documents, XForms for entering data in web browsers, and software for publishing XML...from databases". Robie also mentioned the XML facilities in the forthcoming major release of Microsoft Office. So why are publishing users unhappy? Is their unhappiness, Robie asked, a "matter of getting the tools written, as opposed to issues with XML per se?"
There may be something wrong with XML per se in this regard. Or, more accurately, there may be something wrong with the way XML developers tend to think about XML and about creating it which doesn't mesh well with the ways in which ordinary people think about content and its creation. Simon St. Laurent expanded on this theme:
A lot of developers see XML editing as filling structured containers with appropriate content, and the containers should more or less guide you as to the content. This can mean that a huge amount of detail needs to be dealt with at one pass, and it often has meant that developers create interfaces which are actually more difficult to use than paper forms. Leaving markup for later lets people focus on the information as they see it rather than forcing them from the outset into someone else's preferred boxes.
I worry that too much of "XML development" has focused on approaches that are convenient for computers and programmers and not nearly enough has focused on how people want to work. Tree-based interfaces and expectations that authors want to work with metadata both seem oddly disconnected.
If St. Laurent is right, we may be facing a kind of XML variant of C.P Snow's famous (or infamous, if you prefer F.R. Leavis's demolition of Snow's claims) "two cultures" idea: XML developers do not understand what it means to not be a developer, to think about content creation and the like in ways which are unaware of hard technical issues; and, on the other side, non-developers do not understand the hard technical issues involved in creating tools and technical infrastructures within which everyone can be productive. Of course, it may also be the case that the usability people -- as they are wont to complain -- haven't been attended to carefully enough. They tend to be the cog in the machine that is supposed to help the developers understand and build precisely what the non-developers want and need. In other words, there may not be two cultures but merely two different groups, each with its own needs, goals, and interests, which have not yet found enough common, practical ground upon which to reach a mutually beneficial arrangement.
|
|
|
Also in XML-Deviant |
|
Maybe we need to take a more cold-minded, materialist point of view? Norm Walsh, perhaps inadvertently, suggested just such a perspective when he commented that "the tool/development focus is...intensely focused on applications that involve slurping content out of databases, coding it up in messages, firing it across the web, and then slamming it back into databases" -- to, one supposes, the detriment of human-focused tool development. "But, hey," Walsh hastened to add, "everyone has to make a living". Insofar as Walsh's implication is correct, that there simply is more money to be made building tools for the "data" side of XML than for the "documents" side, it seems reasonable to assume that human-centered tools, which are intended to ease the creation of XML content by humans, are going to lag behind the data tools.
This economic perspective also implies a rather unsettling fact -- unsettling if you are, like me, a long time critic of Microsoft. It implies that the XML facilities in the next major release of Office are the very best, realistic hope for the future of the documents side of XML, at least in terms of mass market success. No other entity in the industry (in any industry, for that matter) is as able to swing mass numbers of computers users toward or away from specific technological solutions. That Microsoft has gained such an ability by virtue of its position as an adjudicated monopolist is in some very real sense beside the point. If you keep a flame burning for the XML-as-document position, outside of Microsoft and a few other notables like Topologi, it is and will likely remain slim pickings for some time.