[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal for a safety domain in DITA 2.0
Thanks to all for the feedback.
It is good to read that a bunch of companies are actually using the hazardstatement - and have adapted their rendering to make it work. I am OK with keeping the naming of elements so that there is no disruption of current materials. But I would still like to review the hazardstatement domain for DITA 2.0 and make sure it does comply with ANSI Z535.6 and it does cover all the options given by that standard.
To answer the question about differences between ANSI Z535 and ANSI Z535.6 - there are none. ANSI Z535 contains a number of sub-standards that define shapes, symbols, colours etc. of safety signs and criteria for their usage. The dot 6 standard concerns safety information in product manuals, instructions and other collateral materials and simply applies all the other dot standards to our domain of technical content.
There are a number of issues I would like to see changed when reviewing the hazardstatement domain for DITA 2.0:
1. The hazardstatement domain currently only implements the so-called Section Safety Messages. There are no specific provisions for Grouped Safety Messages (a topic that lists only safety messages and appears as Safety chapter in the ToC, or even as separate Safety Manual) and Embedded Safety Messages (which may appear as inline text but do show the signal word). Of course, the Grouped Safety Messages can be implemented as a topic with a body that only contains hazardstatements, and an Embedded Safety Message could be implemented as a <note>. It would have been nice if there was a consistent coverage of all safety messages in a single hazardstatement domain.
2. The current hazardstatement has a @type that simply copies the @type on <note>. ANSI Z535 recognises just 4 hazard levels and imposes very strict rules on when these hazard levels should be used. Also, the hazard level should not be defined in the <hazardstatement> but in the <messagepanel>, possibly as a new @level, which is mandatory and has only the four defined levels as values. When multiple <messagepanel> are combined in a single <hazardstatement>, the highest @level value determines the signal word, color, symbol and heading text for the entire <hazardstatement>.
3. The ANSI Z535.6 standard states that the info on how to avoid the hazard may be omitted when the type of hazard and/or consequence is clear enough in itself. The current content model lists <howtoavoid> as one or more - this should be changed to zero or more.
4. Incorrect position of the optional hazardsymbol. The current definition allows any number of hazardsymbols following the one or more messagepanel elements in a hazardstatement. This makes no sense whatsoever as the optional hazardsymbol is used as a graphical representation of a particular type of hazard - it should be part of the <messagepanel>. This allows a number of CAUTION level messages to be grouped under a single CAUTION header, each showing a specific symbol - such as crushed hands, sharp edges, laser beam, etc.
5. The description of <hazardstatement> in the specs should include a clearer description of the hazard levels (which would be the values for the @level on <messagepanel>, not in a section named Example but as part of the specification text.
6. To keep consistency between Embedded, Grouped and Section safety messages, it might be useful to introduce a note-type hazard statement, which could be <hazardnote> and has the same @level as <messagepanel>. Such embedded safety notes appear either in a separate paragraph or as inline phrase, where only the signal word is used (with the defined formatting), followed by the safety message text.
The only disruptive change in the above list would potentially be moving the hazardsymbol into the messagepanel, where it belongs. I doubt that lots of companies are using multiple hazardsymbols in a grouped hazardstatement. For those companies that are using hazardsymbol a simple transform should be able to push it into the messagepanel.
Jang F.M. Graat
Smart Information Design
Cell: +31 646 854 996