S1000D and DITA

Do You Remember?

I don't know if you remember, was it earlier this year or last(?), that there was a flurry of activity around the topic of S1000D and DITA. A group of people had decided that the way to go was to create a DITA which conformed to S1000D.

The presentation was very interesting and, no doubt for some, it was the next exciting thing coming along for the Publications Industry. But for some of us it just didn't have it - and no this is not sour grapes. This topic has come to mind because of training courses that I have run for some clients of ours this year, both face to face and remotely via the internet.

I am not unfamiliar with DITA because:

• Our company has a core of DITA specialists
• Adobe FrameMaker can be used to handle DITA projects
• Adobe FrameMaker comes ready for DITA out of the box.

So given the above why is it that I am not sure that DITA S1000D (or S1000D DITA?) is the way to go.

Why not?

Well, it is my observation that certainly the newbies (sorry but it is not meant to be a derogatory term) to S1000D Authoring have enough to cope with using all the features out of the box. This also applies to those who have been involved in S1000D for some time and who are experienced in that area. Quite often we get questions like:

• Do we have to use all these different types of Data Modules?
• Do we have to use this new Technical Information Repository stuff?
• Do we have to use all these elements?

Of course the answer to all of the above is a resounding NO unless, that is, you are unfortunate to be a Technical Publications Contractor working for one or two of the companies that are insisting on using all the bells and whistles. The majority of users and main contractors/design authorities are not using a number of the extra and most recent features.

So when it comes to DITA and the ability to extend the functionality using specialisms it just leaves them cold. They have no notion or need to learn all sorts of extra stuff. The basic S1000D is quite good enough.

Listening to the guys in the presentation they were clearly very enthusiastic about it. They had be nurturing this arm of S1000D and were very familiar with all the nuances.

It is not just the newbies that don't want to go down that route. My chats with experienced S1000D Authors reflect the same attitude as those not very familiar with S1000D.

In one thread that I read there was the admission that "Both S1000D and DITA can be intellectually challenging to deploy and authoring S1000D data modules by assembling DITA chunks could add an additional layer of unnecessary complexity to your project." I think that this is probably an understatement.

So where are we?

A recent search of published material on the subject produced a very interesting result. There was a lot of information prior to 2010 and not so much post 2010.

Internally within Mekon we came to the conclusion some time ago that if a project was based on part numbers and had a long life then S1000D was the solution and we have seen nothing to change our view on that. If the project is software based (and other sort of related areas of work) then DITA may be the answer.

This was also the view of a presentation given in 2014 (DITA and S1000D Different verses to the same song?) where there was a flowchart included in the presentation. This is the last bit of the flowchart is shown here and I think that it shows that the Mekon view is, on balance, still right.

Overall there is the problem of having something that is well documented to work with. S1000D fills that criteria (well almost - having just spent some time trying to find something specific in the spec and failing) and all who use it know what is required of them. Some of the more recent additions are not really necessary and you can tailor the specification to meet your need - and this is allowed within the rules.

I'm NOT a Luddite

I am not a Luddite - honest!. I will (and am happy to), and have embraced new features, technologies etc. when and where they enhance the working environment of those people who have to document a whole range of projects and deliver the information to the end user in the best way for them. After all the maintenance and technical guys are our customers - the guys who use the information we write to do their work.

As evidence to my remark about not being a Luddite - I was the innovator who designed and delivered a touch screen handbook system for a complete train to a large London Based transport organisation in the early 1990's. Navigation was by means of graphics and this was before the days of Windows - so much easier now. (As an aside I met someone last year who knew what we were doing who commented "They are still not doing what we did then are they?")

So, I do ask the 'Innovators' to have pity on the technical authors who just want to do their job by using easy to use software configured to work with S1000D and not have to invent extra bits when they think that something extra is needed. S1000D works well, it has been around for a number of years now and has become reasonably robust (excluding the odd hiccough of course). Technical Authors (or Communication Operatives as I saw the occupation advertised) in the S1000D arena, even those just embarking on the journey do find most of S1000D Logical and relatively easy to employ in their day to day work.

Of course you may not agree. Bet you that there are a number that don't - always the way!