I think there's a very good argument for the tip attribute. I'm not sure about the others, however.
Jane
--
Jane Credland
Lead Writer, Data Center Group Technical Documentation
Cisco Technical Communication
Office Phone: 408-424-6468
From: Robert D Anderson <>
Date: Wednesday, December 18, 2013 2:55 PM
To: JoAnn Hackos <>
Cc: Bob Thomas <>, dita <>
Subject: Re: [dita] Clarification about note/@type update for troubleshooting
In DITA 1.2 all note types were defined for the hazard statement, along with the othertype attribute. Does this mean that all values other than the 4 JoAnn listed should be documented as "do not use"?
For reference, the DITA 1.2 definition:
http://docs.oasis-open.org/dita/v1.2/os/spec/langref/hazardstatement.html#hazardstatement__attributes
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
JoAnn
Hackos ---12/18/2013 16:52:24---I agree completely. An "official" hazard statement that meets EU rules will be only danger, warning,
From: JoAnn Hackos <>
To: Robert D Anderson/Rochester/IBM@IBMUS, Bob Thomas <>,
Cc: dita <>
Date: 12/18/2013 16:52
Subject: Re: [dita] Clarification about note/@type update for troubleshooting
I agree completely. An "official" hazard statement that meets EU rules will be only danger, warning, caution, and notice. Nothing else is permitted.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
CIDM will be hosting the Content Management Strategies/DITA NA Conference 2014 in Seattle, Washington April 28-30. More information at:
http://www.cm-strategies.com/2014/index.htm
From: Robert Anderson <>
Date: Wednesday, December 18, 2013 3:49 PM
To: Bob Thomas <>
Cc: dita <>
Subject: Re: [dita] Clarification about note/@type update for troubleshooting
Hi Bob,
I think that makes sense as a reason not to include it, though it is likely to raise the question "Why did you add attention and tip but not trouble". However, the fact that it has several confusing values now is not a very good argument for adding one more
confusing value.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
Bob
Thomas ---12/18/2013 16:18:02---Hi Robert, My understanding is, that in ANSI Z535 and ISO 3864, the only hazard labels
From: Bob Thomas <>
To: Robert D Anderson/Rochester/IBM@IBMUS,
Cc: dita <>
Date: 12/18/2013 16:18
Subject: Re: [dita] Clarification about note/@type update for troubleshooting
Sent by: <>
Hi Robert,
My understanding is, that in ANSI Z535 and ISO 3864, the only hazard labels are caution, danger, notice, and warning. It seems like these four values should be the only ones included in the hazardstatement type attribute enumeration. But, I suppose that's academic
at this point.
If there was a specific desire to have the hazardstatement type enumeration match the note type enumeration, then we ought to add "trouble" to the hazardstatement type enumeration even though it's semantically dubious. It pains me to say this because if I were
to document the usage for hazardstatement/@type="trouble", I would say do not use it.
Best Regards,
Bob Thomas
On Wed, Dec 18, 2013 at 2:12 PM, Robert D Anderson <> wrote:
In one of our DITA 1.3 proposals we added a note type of "trouble" to go along with the usual caution, attention, and similar note types.
We have one specialization of <note> in the core OASIS types, from the hazard statement domain, called <hazardstatement>.
Should the new "trouble" type be added to the hazard statement element as well? For all other values of note/@type, the two elements are in sync. My assumption is that it should be added (overlooked in the proposal), but the TC needs to verify this before I
update the topic.
Thanks,
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat () or Skype
Time zone: Mountain (GMT-7)
[attachment "graycol.gif" deleted by Robert D Anderson/Rochester/IBM]
