Meeting minutes from 2006/11/28

[dita@seicodyne.ch]

Meeting minutes uploaded by Chris Kravogel on behalf of Gerald Gtz.

1)  Roll call
We have quorum.

2) We need a Secretary
Issue postponed. The secretary role rotates.

3) Approve minutes from previous business meeting: 
* http://www.oasis-open.org/apps/org/workgroup/dita-machine-industry/email/archives/200611/msg00005.html

The date in the e-mail subject indicates November 13 but the date entry of the minutes references the right date - November 14

Minutes accepted by: Chris Kravogel
Seconded by: Gerald Goetz

4) Business: 

- Review of Issue #5 Hazard Statements: DTD and LangRef proposal http://www.oasis-open.org/apps/org/workgroup/dita-machine-industry/download.php/20875/issue5.pdf

- Review and Release of Issue #5 Hazard Statements http://www.oasis-open.org/apps/org/workgroup/dita-machine-industry/download.php/20867/IssueNumber5-haz_v1-5.htm 

4.1) Discussion of proposal #1 from Gerald Goetz:
 
  The required attribute "type" of the element "hazardstatement" should
  be renamed to "level" because it indicates the degree of the hazardstatement.

Proposal accepted by: Chris Kravogel
Seconded by: Patrick Willekens

4.2) Discussion of proposal #2 from Gerald Goetz:

  An optional attribute "type" should be added to the element hazardstatement
  to inicate the type of hazard. Examples for type: "Hazardous Electrical
  Voltage", "Laser Light", ...

  The type of the hazardstatement is not directly bound to the level.
    
  The DTD should allow to specialize the element "hazardstatement" to leave
  out the element "symbol" for applications where the user should only be
  allowed to pick from a predefined number of symbols (= types).

Proposal accepted by: Chris Kravogel
Seconded by: Patrick Willekens

Chris suggests the attibute type to be a CDATA attribute. Information architects can specialize it to a name token group (1 out of n selection).

Chris states that the DTD already supports the proposed specialization option.
The element "symbol" can be left out.

4.3) Discussion of proposal #3 from Gerald Goetz:

  The DTD should allow to specialize the element "messagepanel" to a
  stricter content model where "typeofhazard" is mandatory and at least
  one element "howtoavoid" must appear:

  <!ELEMENT messagepanel ( (%typeofhazard;), (%consequence;)*, (%howtoavoid;)+ ) >

Chris states that the DTD already supports this kind of specialization and suggests to restrict it right from the start like in the example above.

Proposal accepted by: Chris Kravogel
Seconded by: Patrick Willekens

4.4) Discussion of proposal #4 from Gerald Goetz:

  The DTD should allow to specialize the element "hazardstatement" to a
  stricter content model where "messagepanel" is mandatory (and the
  symbol is controled via the type attribute)

Chris states that the DTD already supports this kind of specialization.

The content model for hazardstatement has been discussed. Chris proposed to change the model with reference to multilingual hazard statements with more than one
messagepanel:

  <!ELEMENT hazardstatement ( (%messagepanel)+, (%symbol)* )>

Proposal accepted by: Chris Kravogel
Seconded by: Gerald Gtz

4.5) Discussion of proposal #5 from Gerald Goetz:

  The content model of the element "howtoavoid" should allow an optional intro for
  text like: "Before you turn on power".
  One alternative would be to change the content model from phrase to paragraph level.
  Alternatively howtoavoid could include commands:

    <!ELEMENT howtoavoid ( intro?, cmd+ )>

Decission passed to next meeting. Chris will validate the DTD options withing the DITA DTD and specialization framework - especially the usage of para level elements.


4.6) Discussion of proposal from Patrick Willekens to include
     an Element "hazardstatementlist".

Chris states that the rendering task described by Patrick can be solved via XSLT.
An element "hazardstatementlist" can also be specialized from another element.
 
4.7) Full vs. minimal implementation 

The group supports the full implementation.

4.8) Proposal from Chris regarding the note element:

  The type-Attribute of the element note should be changed.
  The attribute values "notice" and "caution" should be added
 
Proposal accepted by: Chris Kravogel
Seconded by: Patrick Willekens

Information architects can specialize note to have only a subset of the possible attribute values.

5) Announcements/Opens 

Patrick Willekens will leave ICOS. ICONS intends to continue supporting the group. Patrick intends to propose the content model for a maintenance task.


Tasks for Chris:

- Update issuse proposal number 5

- Check content model for "howtoavoid especially the use of para-level elements"

 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++