Apply suggestions from code review

Co-authored-by: Duncan Dewhurst <[email protected]>

docs/schema/merging.md

@@ -18,10 +18,10 @@ Guidance: [Updates and deletions](../guidance/build/merging)
 
 ### Discarded fields
 
-In the release schema, `"omitWhenMerged": true` is declared on fields that must be discarded during merging. These are presently: `id`, `date` `publisher` and `tag`.
+In the release schema, `"omitWhenMerged": true` is declared on fields that must be discarded during merging. These are presently: `id`, `date`, `publisher` and `tag`.
 
 * For a compiled release:
-  * Both the fields and their values are discarded, because they are metadata about the individual releases; the compiled release replaces these with its own metadata.
+  * Both the fields and their values are discarded, because they are metadata about the individual releases. The compiled release replaces these with its own metadata, as described below.
 * For a versioned release:
   * The fields are discarded, but their values are moved, as described below, in order to indicate from which releases each other field value is taken.
 
@@ -90,8 +90,8 @@ To create a compiled or versioned release, you must:
 1. For a compiled release:
   1. Set `date` to the maximum `date` among the releases.
   1. Set `id` to `{ocid}-{date}`.
-  1. Set `tag` to include all tag values from the individual releases together with "compiled".
-  1. If using set `publisher` to the publisher of the compiled release.
+  1. Set `tag` to all the unique tags from all the releases, plus the 'compiled' tag.
+  1. Optionally, set `publisher` to the publisher of the compiled release.
 1. Merge each release (**input**), in order, into the JSON object (**output**), as follows:
 
 #### Object values

schema/release-schema.json

@@ -33,7 +33,7 @@
     },
     "tag": {
       "title": "Release Tag",
-      "description": "A tag labeling the release, using the the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist might indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. Planning processes must not use the 'tender' code, even if they use `tender` fields. For a compiled release all the tags used in the individual releases for the contracting process should be included together with the 'compiled' tag.",
+      "description": "For a release, a tag labeling the release, using the open [releaseTag](https://standard.open-contracting.org/{{version}}/{{lang}}/schema/codelists/#release-tag) codelist. For a compiled release, all unique tags from all releases for this contracting or planning process, plus the 'compiled' tag. Tags distinguish, for example, planning and contracting processes and the stages of contracting processes. Codes outside the releaseTag codelist might indicate, for example, the notice or form to which the release corresponds, or the event that triggered the publication of the release. Planning processes must not use the 'tender' code, even if they use `tender` fields.",
       "type": "array",
       "items": {
         "type": "string"