About the status of S1000D

Useful stuff for users and developers of the XML based dynamic publishing system "Arbortext". All information in this wiki came from posts to the Arbortext Adepters mailing list that were identified by members of that list as being extremely useful because the mailing list has moved around over the years. For more information see the group FAQ.

This forum and its sub-forums are open to the public.
Forum rules
Discussion posts to this group should be relevant to Arbortext users. Posts on other products or from vendors are welcome, so long as the post also mentions or includes Arbortext in the subject matter. General posts on dynamic publishing and posts from vendors other than PTC will be subject to higher scrutiny and should generally avoid posting here (especially if the referenced material does not mention Arbortext). Advertisement posts for other products (e.g., "check out my product as an alternative") are not welcome. This forum is for Arbortext users to communicate with other Arbortext users about working with Arbortext products.

All posts to this forum are moderated.

User avatar
Posts: 364
Joined: Sun May 31, 2015 2:34 am

About the status of S1000D

Postby liz » Mon Jun 15, 2015 5:04 pm

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.

Return to “Arbortext Code Archive (adepters.org) (Public)”

Who is online

Users browsing this forum: No registered users and 9 guests