| | Table of object revisions ( <chg-object-revisions>) sorted by object revision with <short-name>, <long-name>, revision, release date (see 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 open changes resp. 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 topics  .
|