Agreed. I hope that the debate made some sense to you and that, at least I, made an argument that at least piqued you to further investigation.

Despite my apparent resistance to DITA, I don’t write it off. If it is to flourish though, it needs to be able to stand up to robust debate – if it doesn’t, no amount of marketing will save it.

DITA separates topic-level content from higher-level containment. So in your S1000D example, with each section as a separate topic, the reusers could have achieved their goals by writing new DITA maps, without touching the content. This is a difference in reuse modularity between DITA and S1000D.

You also mention that as people specialize they lose interoperability. While this is true to a degree, it is much less true of DITA than it is of predecessor architectures. Given a set of arbitrarily specialized DITA topics and arbitrarily (differently) specialized DITA processes, they should interoperate at the level of their common semantic denomenator without any special work. And complete integration should be possible simply by assembling new shell processors, with minimal new actual code.

The three things that DITA does that are relatively unique to it are:

- the insistence on the topic as a basic level of reuse, across any project

- the ability to reuse and repurpose any topic from any document into new maps without editing or refactoring the original document

- the ability to specialize new content types without breaking existing processes

Each of these capabilities buys value on its own, but combined they enable sometimes astonishing levels of flexibility, usability, and reuse.

I’ll also refer you to the DITA Maturity Model, if you haven’t seen it already – it grounds each of the major DITA features in the context of increasingly sophisticated adoption scenarios.

http://dita.xml.org/wiki/the-dita-maturity-model

Specialization can restrict the types more or present a model that is more familiar to a user. This is not at odds with the architecture but gives an organization the ability to give their writers a more familiar structure than the base, so if, for example, they want to present the steps element of a task as a procedure element, they can. Specialization still embraces consistency and predictability just gives a different face to the language to the users.

Whether using the base or a specialization, the XML parser is the final decision maker in your coding. If you place a section within a section (in the base language) you will get a parsing error and no output is produced. The model is strictly enforced. All the better editors enforce the structure by presenting only elements allowable at an insertion point. The fact that you can hand-edit the files later and create something that would be incorrect is irrelevant; nothing can protect against that sort of thing. The error is still caught before output and you pay the price then.

I suggest that you use a free trial of one of the editors and play for a few weeks with the language. Maybe some of your questions may be resolved as it appears I’m not doing that great of a job addressing them. I know it works as I’ve been using it for years.

I hope I’ve been of some help, Marcus but I haven’t done sales in a while and find myself quite rusty at providing the compelling benefit to the customer presentation I had learned (guess I’ll have to go back to some of my sales training books). I do know that I’m glad that I’m working in a relatively simple structured environment that helps me focus my writing. Now if I can only get this English thing down; I’d be awesome. LOL.

Have a good weekend.

Consistency and predictability vs specialization – these two concepts are surely at odds with each other, yet you offer them up two sentences apart, as though they were two sides of the same coin. They are in a sense – they’re diametrically opposed.

Altering the output using XSLT – this is a characteristic of any XML document, so implying that it is somehow more powerful in DITA is simply not the case.

Arbitrary nature of XML is its weakness – DITA only standardizes down to the topic, which can contain anything. The complexity is in the topic, not in the higher structure. Converting a “sect1 containing sect2 containing sect3” type of structure to topics is trivial – the difficulty is in what to do when sect3 contains a set of specialized elements.

The only way to enforce structure is to dictate it – you can use forms and templates to suggest structure and Schematron to warn when it’s not being followed. This can produce structured data that is better written than it might have been with a guided syntax editor.

DITA facilitates reuse better than other XML – as per the arbitrary nature point, the higher level structure is not the problem. Reuse depends on the *information* being applicable in two places, but the variability of the information is in no way influenced by the structure that it exists in.

I have watched DITA from the start and have read plenty about it and asked plenty of questions, yet I still have these concerns. If DITA is to be marketed, I (and many others in their sheltered little worlds) will need quantitative answers as to how DITA is better. I’m not trying to be difficult, but I know this industry well enough to be cynical.

You’re correct that ease of use is important and that is a driver that can’t be ignored, which is why there are so many vendors producing parsing editors. What’s more important, when talking about information, is consistency and predictability. Those factors, and the ability to reuse topics and elements is what makes DITA so strong. The other key to the benefits of the language is the fact that DITA can be specialized relatively easily. This allows any organization to develop a set of tags that makes sense to their authors and still inherit a base set of processing to go along with that specialization. You can also alter the output by overriding the base processing using XSLT. This sort of power is difficult to ignore.

You’re correct that XML has been around longer than DITA but the vary arbitrary nature of XML is its weakness when it comes to developing and delivering information. It is difficult to predict how to handle the incoming information without having either a schema or examining the entire document. I suppose that’s why XML didn’t take off as an information development language, though it’s used as the basis of many programming standards and products.

Sure wikis are easy to use and hide some of the language under the covers. The inherent problem is that it relies on the writer to follow some sort of structure on their own and doesn’t even describe an optimum structure. Guidelines are a help towards achieving structure but, especially at my age, you still rely on the human memory to enforce and enact those standards. DITA (or any other structure-based authoring language) removes human frailty from the equation.

All that said, nothing replaces the writer from the equation. The old GIGO adage still holds true when it comes to content. You can provide any environment to make the structure and final presentation adhere to best practices or any standard you want but if you don’t have quality control in terms of the content you still lose.

Your S1000D example is a prime indication of that sort of problem. However, I would expect that someone missed a translation step along the way before delivering the product to the customer and that was the actual failure, not the standard itself.

I wouldn’t write a novel in DITA but that’s not the purpose of the language. The main thrust is help focus highly technical information into a consistent paradigm that enables both author and reader to set expectations and to help reduce costs through reuse.

Hope this helps.

http://www.youtube.com/watch?v=5F1E-2LkhW8

Take a look at this video about XBRL to get a better understanding. It’s only a matter of time before DITA becomes a requirement, not an option.

<object width=”425″ height=”344″></param><embed src=”http://www.youtube.com/v/5F1E-2LkhW8&hl=en” type=”application/x-shockwave-flash” width=”425″ height=”344″></embed></object>

XML is older than DITA and it hasn’t caught on either – not in the “XML is the new ASCII” sense at least. I worked for many years in SGML before that and it was the same story – good idea, but poor reception.

Yet there are niches where XML has huge numbers of users – take Wikipedia for example. Something like 2-5 million authors (depending on how you count them) versus the DITA user base of… dunno, but it’s not those kinds of numbers. So what’s the difference? Ease of use. Telling people how better to use DITA won’t make them use it, whereas getting them to use it without knowing it will. This is one reason why I don’t think marketing DITA will help.

Another is that I’m not convinced that standardizing down to a certain point solves that many problems. Making topics portable and easily snapped together is useful, but you still need to make sure that content is what you think it is.

An S1000D project here in Australia comes to mind – the DoD purchased 22 Tiger helicopters from Eurocopter. (http://en.wikipedia.org/wiki/Eurocopter_Tiger. Yes, the link to Wikipedia is intentional… As the data was S1000D, there was an expectation that “everything was going to be fine”. When the data arrived, there were two main problems – the first was that the data had been authored using three levels of depth in the modules whereas the DoD needed two, so the data was all going to have to be reworked. The second? A substantial portion of the data had been authored in French.

Delivery of this dataset in properly structured S1000D meant nothing. Standardized containers weren’t really any use. The data was all cross-referenced and arguably accurate, but it was only of notional use. The changes to the module levels was going to break the cross references anyway, so despite their correctness at the time of delivery, they weren’t going to be much use in the long term…

How can DITA overcome these sorts of issues? As soon as you start to customize your topics, you start to lose interoperability. As soon as you require a variation to a topic, you start to lose interoperability, and so on. For my mind, all of this occurs because the shape of the dataset is decided before you know what the data will actually look like – how it should look based on natural content, not on predetermined design.

Maybe there are answers to all these things – I certainly don’t claim any expertise in DITA so I’m completely prepared to be proven wrong. On the other hand, I’ve been in this industry for nearly 20 years and DITA didn’t resonate with me from the start. Maybe it’s just me… but I think that marketing DITA is going to be a real uphill battle.