The treatment of the reuqested changes can be documented in <chg-treatment>.
Figure 3: Change treatment
The treatment of one change request is expected in following steps:
 
The request goes through a life cycle which is documented in <chg-state>. This element receives some notes about the next actions as well as a formal state using the attribute [state] with the selection of open, in-progress, passed, rejected or done:

open
The request is captured, but no further action has been taken on it.
in-progress
The request is accepted and is in implementation.
passed
The request is accepted, but no implementation started up to now.
rejected
The request is rejected. It will not be implemented.
done
The request is implemented. It is highly recommended, that the <chg-release-notes> is completely filled now for each changed object.

 
If there are change requests related to the actual one, this can be documented using <chg-related-requests> and <chg-request-ref>. It is possible to express if the related change is a prerequisite to the actual one. Further informatione about the relationship can be entered as text in <chg-request-ref>.
 
For the <chg-request> the responsibility is specified in (<chg-responsibility>). The assignment is done verbally using <desc> or as a set of <team-member-ref>s in <chg-responsible>. The latter style is treated formally and can be used to generate task lists for team members.
 
The possible solutions to the problem can be documented in <chg-solution> where each option can be specifed in <chg-solution-spec> and discussed using <chg-solution-pro> <chg-chg-solution-con>.
Also the estimated effort can be assinged using <chg-effort>. This is treated as a single value. It is up to the user to decide if the effort is measured in hours, days, weeks or months. Since a SGML processing system can sumarize the effort, it is recommended to use the same units.
 
Finally there should be a conclusion, documented in <chg-conclusion> with the following aspects:

<chg-solution-spec>
This is the place to document internals of the chosen solution as well as technical consequences etc.
<chg-implementations>
is a set <chg-implementation>s, each consisting of a pointer (<chg-object-revision-ref>) to <chg-object-revision> to show, in which ones of the revisions the solution is or will be implemented.
<chg-implementation> also receives the <chg-release-notes> which receives the information for the release notes regarding the change-object denoted by <chg-object-revision-ref>. This information should be extracted into an entity holding a <chapter> by an SGML processing system.
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 based on their <long-names> .
<chg-implementation> can be ther more than once if the solution touches more than one <chg-object> .