3 Basic Structures of the MSR Application Profile | B Technical Terms |
MSRREP.DTD is not very content oriented. Nevertheless some aspects of semantic processing shall be mentioned here.
<tt> can be used to generate specific lists or indexes, even if all types are rendered in the same manner.
all references should be checked
The strongest semantics is there in <changes>. Therefore the following processing is recommended:
Table of object revisions (<chg-object-revisions>) sorted by object revision with <short-name>, <long-name>, revision, release date (see Table 5, object revisions)
Tables of requested changes sorted by <chg-state> (open, in-progress, passed, rejected) <chg-priority>, related objects (<short-name>). This will actally be one table per <chg-state>. Each entry should refer to the change itself. Thus these tables can serve as a directory of change requests (see examples in Table 6, open changes resp. Table 7, in-progress changes etc.)
Table of requested changes sorted by <chg-state> (open, in-progress, passed, rejected) <chg-priority>, related objects (<short-name>). This will actally be one table per <chg-object>. Each entry should refer to the change itself. Thus these tables can serve as a directory of change requests.
Table of planned revisions with summarized effort
Release notes either one file per revision or only for one specific revision which is specified as a runtime argument. The release notes should be generated as fragment of a MSRREP.DTD instance, where a chapter is generated for each <chg-request>. It is recommended to include the release notes not directly into <report-body>, because <chapter> on level 1 usually starts a new page.
If the author wants to specify the detailled location of the implementation (e.g. the changed files) he can do this by introducing <topic>s. When the release notes are collected, the SGML processing system could assort the topics19.
The set of tables to produce should be controlled either by a processing instruction <?chg 1246> or by a runtime argument.
It is also possible to export the changes into other tools like Project Management Systems or Spreadsheets.
object | rev | title | effort | release date |
---|---|---|---|---|
msrrep.dtd | DTD for genereic reports | |||
0.15 | initial revision | 5 | April 96 | |
0.16 | improved changes | 7 | july 96 | |
msrdoc.dtd | DTD for MSR engineering doucumentation | |||
0.15 | performing major test | 7 | dec 95 | |
0.16 | releas candidate | 4 | sep96 |
change | priority | title | related object | revision | repsonsible | page |
---|---|---|---|---|---|---|
change | priority | title | related object | revision | responsible | page |
---|---|---|---|---|---|---|
priority | change | title | state | revision | responsible | page |
---|---|---|---|---|---|---|
priority | change | title | related object | effort | page |
---|---|---|---|---|---|
A 1 | chg-imp | improve chg-treatment | msrrep.dtd | 3 | 4 |
A 2 | chg-tt | Introduce tt | msrrep.dtd msrdoc.dtd | 1 | 9 |
Summary of A Changes | 4 |
3 Basic Structures of the MSR Application Profile | B Technical Terms |