Preliminary Remarks
At the second-to-last and again at this year’s tekom Fall conference (the largest event on this topic), there were an increasing number of lectures that were critical of DITA. My colleague Marcus Kesseler himself held such a lecture. You can find it here.

There were some emotional reactions in various blogs and on Twitter. Although DERCOM, of which I am chairman, has published a nuanced view of the DITA discussion in cooperation with Prof. Dr. Ziegler, the following comments represent my personal opinion of this discussion. These comments were also made from our perspective as product manufacturer.

Looking Back
20 years ago, when we at SCHEMA presented our first product at the tekom conference, the appreciation for this product was not exactly strong. Why would you split documents into reusable modules (topics) and then connect them with links for different delivery scenarios (maps)? Why would you use this strange XML format?

Even 10 years ago, parts of the DACH market was still convinced that they needed to create an individual DTD for each project. This often had quite costly consequences.

In other words: Nobody questioned ‘the idea of XML’, but the realization had not asserted itself yet that the main advantage does NOT lie primarily in the information model, but is created rather through the functionality of a Component Content Management System (CCMS).

Current Situation
It may have taken another 10 years, but today we are only requested to implement a special DTD if it is really necessary. These type of request is still made, but is then well thought through by the customer. Even though most customers use SCHEMA ST4 out of the box, we still perform comprehensive customizations if a customer deems it necessary. This may include an exchange of the DTD.

This experience allowed us to gain extensive and comprehensive knowledge in the use of DITA. Occasionally you’ll hear that “we” – but this probably means anybody critical of DITA – are lacking DITA know-how. I’d like to question that.

For the last 10 years, around 30 developers at SCHEMA have been working full-time on the development of SCHEMA ST4. I ask myself: What have they been doing the whole time, if everything is supposedly contained in the DITA DTD?

My theory is that our development team has created functionality which customers have requested. This is a lot and has almost nothing to do with the information model for content creation…

Of course we at SCHEMA, just as any manufacturer, have developed our own information model for content. This is the product of 20 years of evolution in the marketplace and was never the reason a customer decided against SCHEMA. Customers today can make extensive changes to the information model via a user interface.

If I look at DITA today, I am in a way a DITA fan. I think the idea of XML, topics, reuse etc. are quite simply fascinating. There are many people that like DITA because of these central ideas. These are the DITA conceptionalists. The DITA syntacticians, on the other hand, are of the opinion that these ideas can only be implemented with ‘precisely the DITA syntax’. I don’t think this has to be the case.

And that this clearly isn’t the case has been proven by objective economic facts from the DACH market. The DACH market proves the conceptionalist to be right: The member companies of DERCOM alone, which probably represent about 70% of the DACH market, serve around 1300 customers, who have been doing professional technical content management with proven success and largely without DITA syntax. The idea is good, the implementation can be varied.

Proprietary vs. Open Standard
The DITA syntacticians say:

“The manufacturers only want to sell a (proprietary) product so that a customer is ‘locked in’, i.e. the customer is then dependent on the manufacturer, whereas he would be independent with the open standard.”

Let’s address these charges one by one. What does this really mean? “The manufacturers ‘only’ want to sell” means:

  1. The manufacturers ‘want to sell‘, ‘come hell or high water‘, even against the customer’s best interests.
  2. Data exchange is made difficult or impossible just because the system is a proprietary product.

Is that really the case? And is ‘proprietary’ (which simply means ‘to be owned’) actually something bad?

Let me address the ‘charge’ that all we want to do is ‘sell something’: On the one hand, this sounds as if ‘selling’ by itself is something offensive. A DITA consultant wants to sell something as well, such as DITA training, workshops, DITA specialization, etc.

Our company principles state: “We have satisfied customers.” Whether this is successful in every case is open to debate, but we at least strive to do so. And whether you believe it or not: No, we do NOT sell our system against our own better judgment to a customer for which our system is not the right solution. Why not? Because we are focused on a long-term cooperation, and we can’t afford to sell to ‘unsuitable customers’ in a systematic way. We’d have ‘dissatisfied customers,’ and this would get around. It’s that simple.

We work with customers on the basis of ‘decade-long’ relationships. We systematically improve the product, and if something doesn’t work, customers can call us and we’ll do everything to help them. This costs money, of course. But this is why we’re not ‘just’ about selling something.

Data Exchange
Are our customers really dependent on us because data can’t be exchanged or exported? And this because one of our own content DTDs is being used? And would our customers be freer if they used the DITA DTD instead?

Let’s have a closer look: If a customer really wants to get away from SCHEMA ST4, because there is something better, what are his options?

  1. He can export his existing information in one of the following page-oriented formats: FrameMaker, Word, InDesign. He can create the necessary layouts via a really cool graphical interface – the Page Layout Designer. If desired, a native PDF can be created without the help of any additional products.
  2. It’s also possible – as of just recently – to create almost unlimited tagged exports such as HTML, ePub, XML etc. via an equally cool graphical interface with the Online Media Designer.

If somebody says:

“Yes, but that’s not what was meant. This is not about the generated formats, but about the source information.”

I can answer:

  1. Each ArchitectClient contains – openly accessible – a menu to export XML content including all management information from the system as XML.
  2. You can also directly export individual pieces of content as needed via the open API.
  3. And, finally, whoever wants to, can simply export the data via the DITA export module.

You could say to these arguments:

“Yes, but that’s not what was meant, either. Of course you can export net data. You’re dependent on all the system-specific management functionality such as version management, variant management, language management, etc. All this information is not transportable, and you might be able to transfer the net data from one system to another, but not really the entire data pool with all links.”

To which I can only say: That’s true. There isn’t at the moment (and I believe will never be) a possibility to transfer such highly specialized data structures without loss and at the touch of a button from one system to another. The reason for this is the necessary functionality ‘above the DTD’ which must be linked with the usage data in order for the entire system to work. And this functionality is the reason why there are manufacturers such as SCHEMA: This functionality presents the actual benefit. And this benefit is the reason why our 400 customers have bought our product.

Put a different way: If anybody has the impression that he was able to transfer DITA data from one system to another and that ‘everything was there,’ then only due to the fact that both systems have practically none of the functionality that WE have implemented for OUR customers over the last years, as this functionality is definitely NOT in DITA – we looked! 😉 – and it will never be possible to represent this on a (purely declarative) XML level. Simply because this “functionality level” has nothing to do with XML (and DITA, DocBook etc.).

If a DITA CCMS manufacturer implements all this functionality – and he will need to do this if the customers want all this functionality – then he will program it on just the same proprietary level as any other manufacturer.

Our assumption is that a content information model is accountable for only 5%-10% of the overall benefit. A DITA CCMS offering functionality on the same level as the manufacturers in the DACH market do today is just as proprietary, simply because 90% of the functionality has nothing to do with XML.

Now you could ask:

“But if your system is so great, why don’t you just work with a DITA DTD? Then you wouldn’t have to argue ‘against’ it.”

Many years ago we evaluated whether to choose a standard DTD such as Docbook as content information model for SCHEMA ST4. Today I’m glad we didn’t do that. We wouldn’t have been able to offer our customers this level of ease of use, innovation and speed.

We would have been constantly dependent on a standardization committee which potentially would have defined unnecessary and complicating things into the standard, while customer requirements would not have been implemented, because everything takes too long or finally comes to a standstill altogether.

Our customers have many options to import and export data at any time. Even in DITA. The options to model data in ST4 are so comprehensive and the functionality’s benefit so large that the additional benefit of writing the content into a DITA DTD can be questioned. The idea of DITA is good. I am a DITA conceptionalist, after all. But:

  • The DITA syntax, or rather, a DITA DTD is not necessary to achieve the goals of the DITA idea. This is proven by the DACH market, which I consider to be in the lead on an international level.
  • DITA is, on the one hand, quite complex as creation DTD (which has been recognized in the DITA community as well, and which is why a DITA Light is allegedly being created…) and too specific for software documentation
  • on the other hand, DITA is too unspecific, and this cannot be alleviated completely with the good concept of specialization. Customers often use completely different DTDs than DITA…

But apart from that, and to emphasize the point again: The advantage of a CCMS only depends to 5%-10% on an information model and therefore has nothing to do with ‘DITA or no DITA’. 90%-95% of the ROI is realized by product functionality that is completely independent of XML. The ‘comprehensive problem’ – how to support a professional Technical Documentation department with a functioning system – is not a problem that can be reduced to XML tags and DTDs and is not primarily dependent on that. The discussion about DITA (and about other DTDs) distracts from the the essentials, and seen in this light, I am not arguing against DITA but beyond DITA.

PS: We also have a DITA import filter in our system… 😉