Can structured formatters prevent train crashes
Jacques André · Electronic Publishing - Origination, Dissemination and Design · 1989
Paris, Gare de Lyon, 27 June, 1988, 18:47. A crowded suburban train is ready for departure when, suddenly, another train arrives in front of it. There is a crash with 56 dead and hundreds injured. Obviously the killer train had no brakes. Why? The French government immediately set up a commission to analyse the disaster. This commission published its analysis in a report in September 1988 [1]. First of all it appears that ‘Such a disaster is not due to a single cause. Rather to a chain of different circumstances’. Someone pulled down the emergency lever which caused the train to stop in an unscheduled station; an air-brake pipe was faulty and the train driver was unable to bleed it; the radio alarm system was out of order, etc. However the commission noticed that the maintenance manuals were particularly complex to use, and it even noticed an error in the layout of the document describing the process of repairing brakes. The French text of that document, in its original layout, is shown in Figure 1. Figure 2(a) exhibits the main points of the document in that original layout, while Figure 2(b) shows how they should have appeared. Whenever the ‘1st CASE’ of Figure 2(a) applies, the layout tells us that the driver processes only the xxx actions and nothing else. Apparently he does not need to look at the second case, nor to notice the hidden phrase ‘In both cases’ with its associated actions. Thus, he does not switch on the taps, nor does he check the air brakes, and so on. By contrast, the layout of Figure 2(b) indicates that, after obeying the ‘1st CASE’ actions , the driver has to follow on with the ‘In both cases . . . ’ actions which, in turn, involve checking the brakes. We can surmise that the original document was typeset using a second-generation typesetting machine. Let us assume that, on such a machine, there are three tags for controlling indentation, of the form: