S1000D Blog readers: Welcome to a Happy, Prosperous & Fruitful 2006

S1000D changes afoot?
S1000Ders are, judging by the various items that I have heard about over the previous few months, due for a few changes. Inevitably some will be just clearing up S1000D ambiguities and others will be 'tweaks' to help in the generation of S1000D documents. However, some of the other changes may well enter the range on a scale of 9 out of 10.
S1000D users constantly tell me that they would greatly appreciate prior knowledge of the Specification's changed content at a draft stage before it gets 'published'. They believe that introducing this extra stage of perusal will only serve to enhance the 1000D Specification.
The introduction of this extra stage would need to be accompanied by a short phase of receipt of comments for consideration.
Could S1000D learn from ISO?
There are precedents, of course, for this course of action. The ISO committees work in this way - although I have to say that some of the ISO specifications take a long time to come out of the gestation process.
Or could the S1000D answer be in the W3C Model?
A much slicker method is that which is currently used by W3C. It might be worth having a quick look at the stages which W3C work with and see how they can be adapted for S1000D use. Click here for more details:

• Recommendation-


• Proposed Recommendation


• Proposed Edited Recommendations-


• Candidate Recommendations


• Working Drafts of which there are three varieties.

I won't elaborate on these stages because I am sure you can go to the W3C site and look up the definitions and relate them to what you would perhaps like to see in the S1000D development cycle. Perhaps we could have a debate about what the ideal S1000D Cycle should be.I am not proposing that the S1000D specification is considered in its entirety each time since this would be not be sensible. However, the areas of change (or proposed change) could be submitted to a modified W3C system of updating/modifying. I am certainly not advocating taking away from the TPSMG or the EPWG (and other groups) the control of the specification since it is very important that there is a strong core group to make sure that the overall aim of the specification is not lost. However I do feel that the S1000D Specification could perhaps do with extra pairs of eyes being cast over it during development and I can see that this would, is some way, reduce the workload of the committees. I would particularly welcome this in regard to the Candidate Recommendation which, according to the W3C site has the following purpose (the italics are mine):
"A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience."
Of course introducing any extra stages would slow down the cycle of activity but are we all of one mind on this? If it means that we go a bit slower in the development of S1000D to get a Specification which is more straightforward to implement and which provides more guidance on what is intended by the various functions, structures, etc that we find in its 2000+ pages is that not a good thing?
I hope that we can have serious discussions on the S1000D blog. There is, of course, no guarantee that the various S1000D committees will take on board what happens on this Blog.