Issuing unverified S1000D modules was the question of the week this week.
S1000D provides many controls over our data module’s state, ranging from version control numbers for controlling draft states and issues states of our modules. S1000D also includes quality assurance states for each module, enabling us to identify the module’s quality assurance status, be it verified or unverified and where that verification has taken place.
It is important to remember that whilst S1000D provides a great deal of guidance on producing our modern technical publication. Some specification areas assume ‘traditional’ tech pubs knowledge.
The areas of version control, quality assurance and module issuing are all areas where prior technical publication knowledge helps understand key S1000D concepts.
To the question of “is it normal to include unverified modules in a final delivery?”.
While short, the question itself has a couple of keywords that we must decide what we mean. Normal, for instance, assumes that all projects do the same thing when, in fact, they don’t. Most projects will have specific guidance on the issuing and delivery of data modules. These should be detailed and included in the project Business Rules. (learn more about S1000D Business Rules with our training course).
Secondly, understanding what is meant by the ‘final delivery’. The assumption is that the job is complete from a creation stand-point, and the module will pass on to another supplier, customer or user. An excellent example of this workflow is if the data module in question will change to ‘verified’ along with another partner or suppliers data module. The data module itself may only progress to a verified status when assured with supporting data modules.
Previous technical publication experience helps us here understand best practice beyond S1000D. Publishing draft or unverified content opens us to risk, whether a user is unaware of the ‘draft’ or ‘unverified’ status of the content and then uses it unwittingly. The user may then cause damage or harm, opening us to situations litigious in nature.
From a technical content perspective, the best practice is to clarify that the content is unverified or in a draft state. Most publishing tools allow us to extract the data module status information and present it front and centre.
The answer to the question is we would not typically include unverified content in the final delivery. However, there are circumstances where this may need to happen for a specific project purpose.
An excellent question, which on the face of it looks like a simple answer. Thank you for sending it in.
Do you have a question for me? Send it in!
Want more from Tech Data World? Why not join us as a full subscriber and gain access to more detailed content just like this? Watch the full video answering this question with some lovely imagery. New video releases every Sunday on YouTube – make sure you follow for the TDW updates.
