Working with Warnings and Cautions

Way back When

We have just been involved in the handling of Warnings and Cautions and what was being asked for set the OGCs (Old Grey Cells) grinding away trawling up the early days of S1000D. To be precise Issue 1.6 (Change 6 as it was known then). I remember that the UK MoD spent quite a time looking at just what should happen when a Warning was being used.

Lets put on one side the IETM action on being shown a Warning. Although the method determined on was a bit of a contentious issue with the end users it was the only way to make sure that it was put in front of them. Whether they read them is, of course, another matter.

The mechanics were that one referenced a Warning in a Data Module and each warning should be located in a separate Data Module. Indeed the DefStan group created quite a number of special Hazard Warnings and Cautions which were related to specific situations. The mechanism was straightforward. Reference a warning/caution and it was brought up in front of the user. Each Warning or Caution was in its own Data Module. Easy! Easy to find and easy to modify.

Now

OK, so I know that you don't have to use everything that is provided within S1000D, but who thought up the 'latest mechanism' I wonder. You know, the one which stuffs all the warnings in one or more repository files which then has to be referenced (file and warning id) which is then inserted on the fly.
We have two problems here as far as I can see.

1. You have a file which contains theoretically hundreds of warnings. So when it needs updating first work out which file contains the one that you need to change and then find it in the file itself.
2. Just how easy it is to share the warnings between projects?

By having a single warning in a data module the question of updating is much easier, and the ability to share with other projects is also easier.

The question of sharing Data Modules form me was addressed very early. When I was working for another company we had the MoD project manager for a large item of equipment visit us. He has been told that all the legacy Data Modules for some of the equipment which was common across many platforms had to be converted to the latest issue at that time. The reason was that the different issues were incompatible. We were able to demonstrate within 10 minutes that we could create an IETM using Data Modules from the three issues available at that time and they worked perfectly well. So if this is being held up as the reason for the new system it doesn't wash.

Scrutiny

A lot of the problems which occur due to changes which have not, from the end users point of view, been thought out. In a modified system this problem could very easily be solved by making available to a wider audience the proposed changes before they became 'caste in stone'. It is very easy to place a time limit on the 'consultation' period. I realise that this time would perhaps delay the publication of new issues but overall that would be time well spend.

I know that I did mention this mechanism and pointed to the W3C way of working as a possible solution a long time ago. It is certainly a lot easier and quicker than a British or any other standard institution mechanism.

The last time there was deathly silence so I suppose that the same will happen again.