OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] hazard statement widths

I'm not finding the subcommittee's answer helpful
or acceptable.

Comments below.

> -----Original Message-----
> From: Christian Kravogel [mailto:christian.kravogel@seicodyne.ch] 
> Sent: Tuesday, 2009 March 03 13:25
> To: Grosso, Paul; 'dita'
> Subject: AW: [dita] hazard statement widths
> We have discssed this issue in the machine industry 
> subcommittee and came up
> with the following answer.
> We understand the request by Paul Grosso. But adding such a 
> warning into the
> specs, mentioning that a author should not specify a 
> hazardsymbol width
> wider then the width of the hazardstatement, is an affront to the
> intelligence of the author. And if an author would make this 
> unintentional,
> a warning in the specs would not have avoided it.

I'm not talking about adding a warning to the spec.

I'm talking about augmenting the spec to cover a case
it currently does not cover.  This is not an issue of
questioning the intelligence of anyone, it is a question
of writing a standard that covers all cases--even if the
way it covers it is to say the result is implementation
dependent.  A spec that doesn't cover all cases is broken.

> There is no necessity to warn users or avoid that an author 
> specifies a
> bigger hazardsymbol width then the available space.

I believe the subcommittee is missing the point.

The DITA standard is not speaking to authors.  It is speaking
to implementors.  The question it needs to answer is what
should implementors do when authors provide certain combinations
of data, and a spec that does not answer such a question is
missing something.

> The recommendation of the Machine Industry Subcommittee to 
> face this problem
> is:
> 1. We recommend that in the stylesheets of the DITA Open Toolkit the
> rendering of a hazard statement must be aligned to the ANSI 
> standard for
> warning lables. This includes to specify a maximum or default 
> value for the
> width of Hazardsymbols as well as all other layouting 
> recommendations by
> ANSI for hazardstatments. If an author uses attribute values 
> which are not
> inline with the ANSI standard, they just will be ignored.

I am not talking about what the OT does, and the DITA
spec should not be doing that either.

I don't know enough about the ANSI standard for warning labels.

Can the subcommittee turn this recommendation into a statement
on how the DITA spec can be modified to answer the question
of what an implementation should do in the cases I outline?

> 2. For DITA 1.3 we are going to discuss what attributes will 
> be required and
> which are not required in note and hazardstatement. We e.g. 
> need additional
> attributes defining the different panel arrangements 
> according to ANSI.

Fine, but the DITA 1.2 spec is broken and needs to be fixed
even if only to say something like:

 this is an error; an implementation may (but need not)
 give an error message, and may (but  need not) recover
 from this error condition by doing xxxxx.

which we do in several other places in the spec.


> Best regards
> Chris
> -----Ursprüngliche Nachricht-----
> Von: Grosso, Paul [mailto:pgrosso@ptc.com] 
> Gesendet: Dienstag, 10. Februar 2009 19:37
> An: dita
> Betreff: RE: [dita] hazard statement widths
> > -----Original Message-----
> > From: Christian Kravogel [mailto:christian.kravogel@seicodyne.ch]
> > Sent: Tuesday, 2009 February 10 12:25
> > To: 'dita'
> > Subject: AW: [dita] hazard statement widths
> > 
> > You are right, but do we really try to avoid any possible stupidity 
> > done by authors?
> Not necessarily, but the spec should probably say what should 
> happen in such
> cases.  Even if all it says is "this is an error; an 
> implementation may (but
> need not) give an error message, and may (but need not) 
> recover from this
> error condition by doing xxxxx".
> > 
> > If someone defines a table width of 2 inches and adds an 
> image into a 
> > table cell giving the width of 3 inches? Isn't it the same problem?
> Not really.  Putting something too large to fit in the 
> allotted space is a
> classic composition issue and isn't quite the same as having 
> a DTD that
> allows for two conflicting attributes.  But that's probably beside the
> point.
> > 
> > But on one point you are absolutely right, we should review 
> the note 
> > and hazardstatement attributes for DITA Version 1.3. There are a 
> > couple of open issues there, e.g. additional attributes to 
> define the 
> > panel arrangement of a note or hazardstatement.
> Fine.
> > 
> > Paul, I will take you input to our subcommittee and we will discuss 
> > what additional attributes are required and which should be 
> removed. 
> > For DITA 1.2 we have just copied the attributes from note. 
> But there 
> > might be better ideas.
> For DITA 1.2, we don't have to change the DTD (I leave that up to the
> subcommittee), but we do have to say something in the spec.  
> See my first
> paragraph above.
> paul
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Grosso, Paul [mailto:pgrosso@ptc.com]
> > Gesendet: Dienstag, 10. Februar 2009 16:02
> > An: dita
> > Betreff: [dita] hazard statement widths
> > 
> > In a hazard statement, you can set the width of the hazard 
> statement 
> > using the attribute width. There is also an align 
> attribute, so if the 
> > set width is smaller than the available width, we could align the 
> > output to center, right, or left. So far so good. But then there is 
> > also a width attribute on the hazardsymbol tag which is a 
> child of the 
> > hazard statement.
> > 
> > There is nothing to prevent users from doing things like 
> setting the 
> > hazard statement width to 2 inches and the hazard symbol width to 3 
> > inches.
> > 
> > It seems either we need to remove one of the width 
> attributes from the 
> > DTD or the spec needs to define what the correct processing 
> should be 
> > in such cases.
> > 
> > paul
> > 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]