MSR-Documentation MSR-Report

Concepts of MSRREP.DTD

Notes


1 sometimes such elements are called "inline-elements"
2 if there is no problem, there can be no solution - nothing must be changed.
3 This feature should be controlled either by a runtime argument or by a processing instruction.
4 even if it is possible to refer to more than one version of a certain option, it is up to the author to decide if this makes sense.
5 In that respect, it is recommended to nest not more than four levels.
6 the other option would be to have an extra element for each chapter level
7 Actually it is up to the rendition system if the sequence is expressed as numbers or as letters.
8 it is not really easy to distinguish between these two elements. As a rule of thumb, one might say that the semantics of def-list is stronger than the one of labeled-list which is more layout oriented. The items of def-list can be referenced by xref which is not possible with the items of a labeled-list.
9 future revisions of the dtd might receive an explicit element for notes, warnings attentions etc.
10 This can be used for systems which can't display graphics.
11 This is the way how this document is prepared. It is visible in the sgml source.
12 it is recommended to enter the term always in singular and create plurals outside of the element (see second example).
13 But many people read footnotes first - so put the interesting stuff in footnotes
14 Note that in MSRDOC.DTD there are means to formally describe variables to be used if the system software of an ECU is specified.
15 these changes can be done by search and replace in some SGML editors
16 For definition of an exact setting or measurement value.
17 For definition of a typical value or value range.
18 For definition of an alpha-numerical value.
16
17
18
19 This feature should be controlled either by a runtime argument or by a processing instruction.