Thursday, September 14, 2006

S1000D - approach with caution!

S1000D is apparantly going to rock the technical publications world, and according to one commentator "has gained noteriety in the USA.." not sure if this is what the commentator meant, or he was simply using a big word that he didn't fully understand.

But frankly it is gaining some noteriety in my home office - as I have had it up to here with S1000D, and what it does or does not mean.

I am assuming those of you who have no idea what S1000D is, will have left the page by now, but in the interests of courtesy let me quickly explain:

S1000D is a European technical specification that has been in development since the mid 80's. It is common in Europe particularly in Military and Aerospace, and is just now starting to catch on here in the US. Its a well meaning specification, that tries to give guidance as to how to modularize technical publications. How to construct and create large technical manuals, into small components that can be re-used. That at least is what it tries to do, but from my limited exposure is also capable of causing more trouble than its worth.

Take for example the concept around these data modules, that they should be 'self contained'. Its the sort of thing that appears on the surface to be logical and obvious, but fall's apart when viewed from different perspectives in the process. You can technically manage data in a database down to a period or colon, but can you manage the business processes that are by default attached to all these items? Oh yes, particularly in engineering circles, everything needs to have a process attached to it and to go through a proper comment and approval cycle.

S1000D appears to be written by well meaning data architects, who have never spent time to consider the differences between structured data and unstructured content. In supporting software products that are spinning off in support of S1000D is emerges as configuration management (ala Merant or Serena) for content. Yet the worlds of engineering and manufacturing should have learned painful lessons already about the limitations of PLM in process or detailed compound documents in Pharma for example - the lesson being it only works up to a point.

I am the first to declare that it's all data at the end of the day - but text needs to be in context, just as a diagram on an engineering drawing is meaningless if not seen in context with supporting data sheets.

Its probably too big a topic to rant about on a blog - but like many specifications before it, S1000D needs to be seen in context (just like the content it addresses) - it will allow you to fragment content items to a tiny degree, however it does not suggest that you actually do that. Simply, it suggests that content re-use is a good thing (agreed) modularization of content (to reduce duplication and redundancy) is a good thing (agreed). It also provides a structure for you to manage that resuable modular situation.

But to what level you section content is a decision you (or your industry) needs to make, its a decision that will take into account all the business processes and dynamics surrounding compliancy, authoring processes, usage models etc first.

S1000D in its drive to apply consistent metadata to content, to push for greater efficiency and the ability to share is a good thing. But like many good things, it needs to be taken in moderation.

As this is a bit of an obscure area I though the following might be of some use. A list of software firms with products supporting S1000D (just a list not a recommendation!)



G. Parapadakis said...

Hi Alan,

I recently came across DITA ( which I must admit I was not aware of. Apparently it started life in IBM, but has since grown to an open standard. As far as I can see, it appears to be doing something very similar to S1000D. I can see the logic behind DITA, especially when you combine it with other XML based tools like translation memories. How do these standards sit against each other?


alan pelz-sharpe said...

Good question George :-) I might not know the answer myself, but I know somebody who does....

Give me a day or two and will come back on this one.

alan pelz-sharpe said...

From what I understand DITA appears to be an Open Standard (well if is from OASIS!) that indeed follows much the same path. I think though that they can be used in parrallel as DITA seems to be provide simply and open approach to standards such as s1000D.
They key appears to be ensuring that content is interoperable and re-usable.
In short it is a framework for ensuring consistency between XML doc types (and S1000D would containg several of these).

Where both of these appear to falter from what I can see is that they are very Web Content centric, rather than document centric. That all the focus is given to the rendering out demands, and frankly too little to the practicality of approval cycles and authoring processes.

Not sure this makes any sense other than to me :-)

Scott Abel said...


DITA and S1000D are indeed being used together -- and the upcoming Documentation and Training Conference (April 18-21, 2007) in beautiful Vancouver, BC will offer up a presentation on this subject using one of the world's largest aerospace manufacturers as a case study. The theme of the event is "The User Experience".

There also appears to be some interest in using both DITA and S1000D together. A small group of technical communicators have asked OASIS to set up a listserv to allow them to discuss this topic with others with similar interests.

Additionally, Adobe System has created what they call "application packs" - downloadable plug-ins to their popular technical content authoring tool, Adobe FrameMaker. The software vendor has announced release of application packs that support DITA and S1000D (two separate tools) that empower FrameMaker users to use these standards with some guidance and understanding from the tool.

Of course, I'm not advocating the use of either standard, just sharing some information with your readers.


Scott Abel (aka pigment-challenged Randy a la Wiki Idol)

alan pelz-sharpe said...

thanks Scott!

Engineering Data/Document Management forms the basis of my own background in this industy, but it really is a dizzying array of on the one hand sensible and highly regulated conditions, on the other a confusing mess...

After my last run in with DITA and S1000D I am happy to keep my head low in this sector for now :-)


Dan Young said...

I work with the SCORM standard, which has a similar focus on segmentation and reusability (but for training content rather than documentation). I agree that developing content in self-contained units is easier in theory than in practice. There are always going to be content pieces that just aren't reusable; they have content that specifically relates to that document and none other.

What seems to be working in the SCORM community is developing some content elements (80%) for reusability and developing others (20%) for non-reusable context. In other words, if there will be content that is too context-dependent to be practically reused, group that context into an element that won't be reused, and then group or segment the rest of the content into reusable pieces.

This approach allows you to support the CSDB concept while making some concessions to the reality that not everything can be written in a context-independent format (which I think is the point of this article).

Dan Young said...

BTW, you can also add this product to your list:

They have an integrated SCORM & S1000D product suite.