Include a link to CF area-type table and make explicit the need to use standardized area-type strings in Section 7.3.3

ch03.adoc

@@ -178,7 +178,7 @@ Knowledge of the XML format is only necessary for application writers who plan t
 A formatted text version of the table is provided at
 link:$$https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html$$[https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html],
 and this table may be consulted in order to find the standard name that should be assigned to a variable.
-Some standard names (e.g. **`region`** and **`area_type`**) are used to indicate quantities which are permitted to take only certain standard values.
+Some standard names (e.g. **`region`**, <<geographic-regions>>, and **`area_type`**, <<statistics-applying-portions>>) are used to indicate quantities which are permitted to take only certain standard values.
 This is indicated in the definition of the quantity in the standard name table, accompanied by a list or a link to a list of the permitted values.
 
 Standard names by themselves are not always sufficient to describe a quantity.

ch07.adoc

@@ -379,18 +379,19 @@ Notice that a parenthesized comment in the `cell_methods` attribute provides the
 
 By default, the statistical method indicated by **`cell_methods`** is assumed to have been evaluated over the entire horizontal area of the cell.
 Sometimes, however, it is useful to limit consideration to only a portion of a cell (e.g. a mean over the sea-ice area).
-To indicate this, one of two conventions may be used.
+Cell portions are referred to by means of standardised **`area_type`** strings, maintained in the link:$$https://cfconventions.org/Data/area-type-table/current/build/area-type-table.html$$[area-type table], using one of two conventions.
 
 The first convention is a method that can be used for the common case of a single area-type.
 In this case, the **`cell_methods`** attribute may include a string of the form "__name: method__  **`where`**  __type__".
-Here __name__ could, for example, be **`area`** and __type__ may be any of the strings permitted for a variable with a **`standard_name`** of **`area_type`**.
+Here __name__ could, for example, be **`area`** and __type__ may be any of the standardised **`area_type`** strings.
 As an example, if the method were **`mean`** and the **`area_type`** were **`sea_ice`**, then the data would represent a mean over only the sea ice portion of the grid cell.
 If the data writer expects __type__ to be interpreted as one of the standard **`area_type`** strings, then none of the variables in the netCDF file should be given a name identical to that of the string (because the second convention, described in the next paragraph, takes precedence).
 
 The second convention is the more general.
 In this case, the **`cell_methods`** entry is of the form "__name: method__  **`where`**  __typevar__".
 Here __typevar__ is a string-valued auxiliary coordinate variable or string-valued scalar coordinate variable (see <<labels>>) with a **`standard_name`** of **`area_type`**.
 The variable __typevar__ contains the name(s) of the selected portion(s) of the grid cell to which the __method__ is applied.
+These name(s) must be a subset of the standardised **`area_type`** strings.
 This convention can accommodate cases in which a method is applied to more than one area type and the result is stored in a single data variable (with a dimension which ranges across the various area types).
 It provides a convenient way to store output from land surface models, for example, since they deal with many area types within each surface gridbox (e.g., **`vegetation`**, **`bare_ground`**, **`snow`**, etc.).
 

history.adoc

@@ -7,6 +7,7 @@
 
 === Working version (most recent first)
 
+* {issues}550[Issue #550]: Include a link to CF area-type table and make explicit the need to use standardized area-type strings in Section 7.3.3.
 * {issues}367[Issue #367]: Remove the AMIP and GRIB columns from the standard name table format defined by Appendix B.
 * {issues}403[Issue #403]: Metadata to encode quantization properties
 * {issues}530[Issue #530]: Define "the most rapidly varying dimension", and use this phrase consistently with the clarification "(the last dimension in CDL order)".