[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] <hazardsymbol> and the redesign of the hazard statement domain
Hi there,  My vote is for the option Kris has proposed. This solution would allow authors to associate the symbol with whichever content it applies and allows for multiple symbols without having to rebuild the specialization.  Have a great day, A  From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Kristen James Eberlein  Background Pretty much everyone who has chimed in on this thread agrees that we need to make changes regarding where <hazardsymbol> is permitted. But ... Different people have very different ideas about where it should be allowed. Current content model Below is markup for a simple hazard statement and its rendered output:        <hazardstatement type="warning"> Note that each <hazardstatement> element can contain:
The <hazardstatement> element might be rendered as follows: Issues with the current content model Obviously the current content model works fine for the simple hazard statement provided above. But what happens when a hazard statement has multiple message panels? Multiple hazard symbols? Then it is unclear which symbol is associated with which message panel -- or even which child component of the message panel. Does a image represent the "type of hazard" or "how to avoid" the hazard? This might matter if a company's style calls for rendering one type of image on the left and another type of image on right. Current suggestions for modifying the content model
Assumptions that drive design choices There IS a reason for the current design; the only reason that multiple <messagepanel> elements are permitted is that Chris Kravogel anticipated that companies might want to have hazard statements that presented the information in multiple languages. (KJE: This is not a use case that I have seen in real world usage, at least yet. And the design does not allow for presenting the "signal word" -- based on the value of the @type attribute -- on <hazardstatement> in multiple languages ) Use cases that the original design did not consider:
What do you all think? Which option is best? And do we continue to allow <hazardsymbol> to be associated with <hazardstatement>? -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]