Some questions and answers concerning XML: the real world and structures

Q1. Looking at XML and its progress toward widespread use, what is the issue or problem that concerns you most? What are the implications of this issue/problem?

XML is the successor of SGML. In fact, from the user's perspective it is nothing else than SGML. So we are in a dozen of years tradition and at least some companies have a long experience to separate content, structure and layout.

XML itself is mainly a big marketing thing and pushed by intelligent and honorable people like Bosak, Bray and Clarke who turned the dry structured view on data into a sort of fashion:

1. Suddenly all technical interfaces seem to become definable by one language. This is fine!
2. Suddenly the baroque SGML seems to be clarified and simplified and tools may be conjured up out of nothing. This is partly correct but partly wrong, especially with XML editors. It is easy to see that building a fine editor was only to a little part complicated because SGML was developed in a muddled way. It is complicated to make a good editor, and much more complicated to do it with structural rules in the back plus screen layout. So up to now the old heroes SoftQuad and ArborText are up and running; the rest is far away. But this is (except for license prices) not the user's concern.
3. Suddenly all documentation and information problems, be it web or hardcopy oriented seem to have one solution. This is wrong! And this is where I see the gap

Companies, publishers and institutions are deep in a mess.

Processes and structures to generate and treat information grew over decades. It may be an archeological task to find out why certain things are organized in a certain way and there will be findings of layers which stem from the handwriting, the typewriter, the mainframe and the early PC times. Departments have been split, unified, renamed.

Responsibilities have floated around. Workflows meandered through the company's changing landscapes. Kingdoms evolved and are based on nothing real anymore, but the kings are defending their territories, especially in the management levels. It is chaos, it is a mess, it is a catastrophe.

And suddenly me and my colleagues come around the corner and know the three-letter answer. The answer is very powerful: it is a STANDARD. It is XML (backed by the emperors of the web, the W3C) based on SGML (backed by the popes of all the standards, the ISO). We! The XML saviors! The SGML healers!

Of course we are not. Having this attitude and thinking in this community way causes the following:

• opinions like "SGML / XML is very expensive"
• high project and product prices
• problems remain the same and untouched
• we do not understand the customers (some of us even do not even try to) and they do not understand our (sometimes artificial) goals
• low acceptance
• failures
• horrified customers ("we tried XML, but PDF is so much easier and better")
• great disappointments
• bankruptcies on both sides

XML is needed and there is, except for some minor things, nothing bad with the SGML replacement. DOM, CSS, XSL and advanced linking capabilities are needed as well.

But we need people to build the bridge to the sites of application on the other side, not people throwing tools over the gap.

1. The specific information, documentation and knowledge management problems have to be understood first.
2. Then it has to be made clear that businesses, processes, attitudes, behaviors, territories, skills, perspectives, goals, responsibilities, positions, preferences, culture(s) have to be analyzed and have to be seriously challenged
3. Then first proposals can be made how a smooth, acceptable, feasible migration can be made, how long it will last, which steps have to be made, which decisions have to be made and how people can be won to play along (and what to do with the ones who do not).
4. Then, only then, standards can be chosen and tools operating on them.

This is the sequence.

Many XML people begin and end with item 4.

Item 1 to 3 define the gap I have been talking about for many years now. It is harum-scarum's mentality to skip the analysis and thoughtful planning.

So the danger is not in XML but in its priests.

Technology and standards are pushed fast enough and far enough at least for a time. Now we have the chance to pause a while, to look back into the real world and its problems and to think and to teach how the new tools and maybe others can be applied to solve what is called the information crisis.

And suddenly new problems will occur: the real ones.

1. We will learn that information generation, maintenance and exchange are the arteries in the bodies of many companies. And suddenly the task gets the complexity of re-engineering processes and power structures. The information engineers and architects will see that they need different and additional skills.
2. We will see, that it is a minor technical problem, how to organize links, information modules and topic maps. But we will painfully realize that there is no theory and no concept, how the reader of today and tomorrow can be helped in looking up facts; how she finds the right bit of information at the right place fast and without missing other important facts; how she would like to follow link trails without getting lost; whether non-sequential reading is suited to the human perception; what interactive features of the new dynamic media are useless rubbish and which do really help; how the lawyer gets maximum use of a info-base of laws, comments and cases; how the doctor can be led through differential diagnoses; and how the mechanic can isolate the reason for the fault and be advised for the recovery procedure
3. Even if these questions were answered, our tools still might be XML-based. But then we would know why and what for.

Q2: As far as dealing with clients (or more generally), what do you see as the most common misperception about XML adoption/implementation? What are the repercussions of this misperception?

This answer can be based on the answer above.

As long as XML is used in a technical sense (e.g. in EDIFACT replacements or as a channel definition language) there will be no problem.

But when used as a document definition and control language the misperception is that the standard solves the existing problems. It does not and this makes the results of many IT projects so weak and hopeless. And it strikes back on XML because the standard and the tools claimed to be able to solve the problem. So the feedback is: "XML is expensive, awfully complicated, my staff likes Word better, so let us return to the Bill- Gates-Street."

Q3: Please elaborate on your statement that, "....the bridge is not "technology" but "change of concepts, processes, and culture"

Answered above. Item four in the conclusion is the technology part. Analysis of the real problem and conceptual design of the solution are missing.