さてhazardstatementは実際上どのように管理するのでしょうか？私の想像ですが、取扱説明書のような技術文書では、製品の分野、製品のグループなどにより、出力文書に記述する内容が異なってくると思います．
しかしあくまで個別文書毎にいちいち記述する性格ではけっしてありません．かならず共有コンテンツとして管理し、conrefかkeyrefなど間接参照で使用するものでしょう．そうした場合に考えられる管理方法は
・hazardstatementごと共有管理する．もし特定のhazardstatement/messagepanelを取捨選択する場合、フィルタリング属性をつける．
・messagepanel毎に管理し、個々のhazardstatementからconrefまたはconkeyrefする．
というものがあります．
ところがこの両方について「ままっこ扱い」になるのがhazardsymbplです．以前紹介しましたように．hazardstatementは
( (messagepanel) (one or more) then (hazardsymbol) (any number) )
となっていて、messagepanelとhazardsymbolは切り離されているのです．
しかしhazardsymbolが存在するとすれば、それは、
messagepanel[1]に対してhazardsymbol[1]が対応し
messagepanel[2]に対してhazardsymbol[2]が対応し
messagepanel[3]に対してhazardsymbol[3]が対応し
と考えないとつじつまが合いません．
これは非常に管理しづらいのではないでしょうか？本来セットであるべきmessagepanelとhazardsymbbolを別々にしなければならないからです．もちろんhazardsymbolが一つもないhazardstatemetもありますので、この場合は除外します．
端的に言えば、情報アーキテクトは、hazardstatementが次のようになっていれば共有リソースとしての管理は格段に楽になるはずなのです．
( (messagepanel) (one or more)
そして、messagepanelは、
( (typeofhazard) then (consequence) (any number) then (howtoavoid) (one or more) then (hazardsymbol) (zero or one))
こうすれば、安全上の注意をそれを表すシンボルも含めて一括で共有管理できるのです．ところがDITA 1.2～の定義はそうなってくれていません．
これは実践上は非常な手間に思えます．何故このようになってくれていないのでしょうか？
これは端的に言えばhazardstatementがDITA 1.2でnoteから特殊化して作られ、そして実は次のような@class構造を取っていることに起因します．DITA 1.3のDTDを見ますと次のように定義されています．
<!-- ============================================================= -->
<!-- SPECIALIZATION ATTRIBUTE DECLARATIONS -->
<!-- ============================================================= -->
<!ATTLIST hazardstatement %global-atts; class CDATA "+ topic/note hazard-d/hazardstatement ">
<!ATTLIST messagepanel %global-atts; class CDATA "+ topic/ul hazard-d/messagepanel ">
<!ATTLIST hazardsymbol %global-atts; class CDATA "+ topic/image hazard-d/hazardsymbol ">
<!ATTLIST typeofhazard %global-atts; class CDATA "+ topic/li hazard-d/typeofhazard ">
<!ATTLIST consequence %global-atts; class CDATA "+ topic/li hazard-d/consequence ">
<!ATTLIST howtoavoid %global-atts; class CDATA "+ topic/li hazard-d/howtoavoid ">
つまりhazardstatementをインプリメントしていない処理系のために、hazaradstatementはnote、messagepanelはul、typeofhazard, consequence, howtoavoidはli、そそいてhazardsymbolはimageの特殊化として定義されています．これが根本原因です．
messagepanelの中にhazardsymbolを入れようとしても、それは無理です．何故ならulはliからしか構成されていないからです．この構造のなかにimageは入れられません．
つまりhazardstatementは、DITAの特殊化の限界（？）というか、新しいドメインをそれをサポートしてない処理系であっても一定の組版結果を得られるようにするというDUTAの根本的な思想で作られているためです．
もし、あなたの処理系がこのような特殊化のルールは「不要」と判断すれば、もっと共有コンテンツとして管理しやすいようなhazardstatemetを作ることができるかもしれません．ただしこれを行ってしまうと、他のシステムとの相互運用性を犠牲にしなければなりません．これとのトレードオフをどう考えるか？というところです．
しかし何にしてもhazardstatemetは必ずしも使いやすくないというのが現実に思えます．