About the status of S1000D

Lynn Hales gives advice about the document type S1000D (a registered trademark, owned by ASD) Last Updated: 2006-08-26

I am not trying to downplay any of the work done by any of the companies that have implemented an S1000D "solution". However, having been fairly actively involved in the evolution of the S1000D standard the past three or so years, I would be hesitant to jump onto the S1000D bandwagon at this time. Because of the increased interest world wide, S1000D is going through some growing pains and reaching a point where some difficult decisions will have to be made.

S1000D offers a great deal, but it is still evolving fairly rapidly and despite the attempts to maintain backwards compatibility, S1000D may not be the desired approach.

If you want to implement S1000D, be ready to do a long and involved analysis of your current requirements. Are your 'requirements' really a true requirement, something that is needed or are they just a collection of the "that's the way we've always done it" syndrome.

S1000D, like Docbook and DITA, is very flexible, but designed primarily to support technical data. The learning curve could be fairly long, at least for the folks who have to support the tools and understand the way S1000D works. One thing to keep in mind though, S1000D is written using the data module approach (and starting with the next release, it will be written using the S1000D schema), so you do have a good example of what an S1000D document can look like in the standard itself.

If you are looking for a more functional IETM or diagnostics capability, right now, it is not in S1000D. It is being worked and is recognized as needed, but it is not ready for prime time just yet.