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!)

X-Hive
IBS
MarkLogic
CDG
InMedius
Astoria
WebXSystems
SiberLogic