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 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.
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.