The current hazardstatement is considerably looser than ANSI Z535.6, but I think it’s possible to build standard hazardstatement display with the current markup. A specialization enforcing proper semantic design could probably be built
based on the existing hazardstatement markup. That said, I’ll admit my knowledge of Z535 is mostly secondhand.
Schneider Electric uses hazardstatement extensively, but with very specific styling requirements based – I don’t know how closely – on the ANSI Z535 standard set.
They use Danger, Warning, Caution, and Notice hazardstatement types.
Via stylesheet, they switch up the order of consequence howtoavoid so that the consequence is last.
They have strict gentext to use for the consequence for the various hazard types. Any authored consequence is ignored in favor of the stylesheet-provided text for type=’danger’; the
authored consequence takes precedence over the stylesheet’s consequence for Warning, Caution, and Notice, but authors generally defer to the stylesheet.
They were
very particular about the colors used for the various hazard types.
You can see an example of all four types
here.
Chris
From: <> on behalf of Jang <>
Date: Tuesday, May 8, 2018 at 1:05 PM
To: DITA TC <>
Subject: Re: [dita] Proposal for a safety domain in DITA 2.0
I guess these companies must have created their own rendering then, because until recently, none of the publishing tools did anything even remotely correct with it. But even if companies are using it, there are
a number of things that are not correct about it when checking it against ANSI Z535.6, which is mandatory at least in the machinery industry.
So if we are checking with clients who are using the hazard statement, please also include feedback on whether these clients have done their own rendering transforms, and whether they have any
comments about incompatibilities, incompleteness or hard-to-use features of the domains. Just the fact that companies are using it does not say it was well designed.
Kind regards
Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands
Cell: +31 646 854 996
On 8 May 2018, at 18:59, Kristen James Eberlein <>
wrote:
Jang, there are manufacturing companies that use the current hazard statement domain, so I cannot agree with your assertion that "hardly anyone is really using [hazard statements]."
Consultants on the TC, can we get a tally of your clients whom you know are using the hazard statement domain?
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 5/8/2018 12:38 PM, Mr. Jang Graat wrote:
The hazardstatement domain is very poorly designed. There are almost too many things wrong with it, from its placement in the base directory and inclusion in all document shells to the content
model for the hazardstatement itself and poor naming of elements. Until very recently, none of the authoring and publishing tools for DITA have done anything even remotely right in rendering hazard statements. Which goes to show that hardly anybody is really
using them.
I propose to rework the hazardstatement domain in DITA 2.0 to align it with the ANSI Z535.6 standard on safety information. The new domain should be called safety domain and allow all and only those safety notices and symbols that are covered by the ANSI Z535.6
standard. This includes not only the current hazardstatement (with necessary fixes and constraints applied to it) but also embedded safety notices which follow the same ANSI Z535.6 rules.
I am willing to invest time in implementing the required elements and do the necessary reality checks with users from various industries, so that DITA 2.0 will have a safety domain that is really being used.
I am not currently a voting member of the DITA TC but intend to reach and maintain that status going forward, so that I can become champion for this proposal and take it through the process.
Kind regards
Jang F.M. Graat
Smart Infornation Design
Amsterdam, Netherlands
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
