Edits for "conventions" and impersonal form

appd.adoc

@@ -279,8 +279,8 @@ No `standard_name` has been defined for `C` or `depth_c`.
 
 ===  Ocean sigma over z coordinate
 
-**The description of this type of parametric vertical coordinate is defective in version 1.8 and earlier versions of the standard, in that it does not state what values the vertical coordinate variable should contain.
-Therefore, in accordance with the rules, all versions of the standard before 1.9 are deprecated for datasets that use the "ocean sigma over z" coordinate.**
+**The description of this type of parametric vertical coordinate is defective in version 1.8 and earlier versions of these conventions, in that it does not state what values the vertical coordinate variable should contain.
+Therefore, in accordance with the rules, all versions of the conventions before 1.9 are deprecated for datasets that use the "ocean sigma over z" coordinate.**
 
 ----
 standard_name = "ocean_sigma_z_coordinate"

appf.adoc

@@ -17,7 +17,7 @@ These are:
 - `semi_major_axis`
 - `semi_minor_axis`
 
-In general we have used the FGDC "Content Standard for Digital Geospatial Metadata" <<FGDC>> as a guide in choosing the values for **`grid_mapping_name`** and the attribute names for the parameters describing map projections.
+In general, the FGDC "Content Standard for Digital Geospatial Metadata" <<FGDC>> is used as a guide in choosing the values for **`grid_mapping_name`** and the attribute names for the parameters describing map projections.
 
 === Albers Equal Area
 
@@ -84,7 +84,7 @@ This model is independent of the physical scan principles of any observing instr
 The model consists conceptually of a set of two rotating circles with a colocated centre, whose axes of rotation are perpendicular to each other.
 The axis of the outer circle is stationary, while the axis of the inner circle moves about the stationary axis.
 This means that a given viewing angle described using this model is the result of matrix multiplications, which is not commutative, so that order of operations is essential in achieving accurate results.
-The two axes are conventionally called the sweep-angle and fixed-angle axes; we adhere to this terminology, although some find these terms confusing, for the sake of interoperability with existing implementations.
+The two axes are conventionally called the sweep-angle and fixed-angle axes; this terminology is used here, although some find these terms confusing, for the sake of interoperability with existing implementations.
 
 +
 The algorithm for computing the mapping may be found at link:$$https://www.cgms-info.org/documents/pdf_cgms_03.pdf$$[https://www.cgms-info.org/documents/pdf_cgms_03.pdf].

apph.adoc

@@ -233,7 +233,7 @@ When the intention of a data variable is to contain only a single time series, t
 ====
 
 While an idealized time series is defined at a single, stable point location, there are examples of time series, such as cabled ocean surface mooring measurements, in which the precise position of the observations varies slightly from a nominal fixed point. It is quite common that the deployment position of a station changes after maintenance or repositioning after it drifts. 
-In the following example we show how the spatial positions of such a time series should be encoded in CF. In addition, this example shows how lossless compression by gathering <<compression-by-gathering>> has been applied to the deployment coordinate variables, which otherwise would contain a lot of missing or repetitive data.
+The following example shows how the spatial positions of such a time series should be encoded in CF. In addition, this example shows how lossless compression by gathering <<compression-by-gathering>> has been applied to the deployment coordinate variables, which otherwise would contain a lot of missing or repetitive data.
 Note that although this example shows only a single time series, the technique is applicable to all of the representations.
 
 [[example-h.5]]
@@ -1203,7 +1203,7 @@ In the latter case, listing the vertical coordinate variable in the coordinates
 ==== Ragged array representation of time series profiles
 
 When the number of profiles and levels for each station varies, one can use a ragged array representation.
-Each of the two element dimensions (time and vertical) could in principle be stored either contiguous or indexed, but this convention supports only one of the four possible choices.
+Each of the two element dimensions (time and vertical) could in principle be stored either contiguous or indexed, but these conventions support only one of the four possible choices.
 This uses the contiguous ragged array representation for each profile (9.5.43.3), and the indexed ragged array representation to organise the profiles into time series (9.3.54).
 The canonical use case is when writing real-time data streams that contain profiles from many stations, arriving randomly, with the data for each entire profile written all at once.
 
@@ -1443,7 +1443,7 @@ In the latter case, listing the vertical coordinate variable in the coordinates
 ==== Ragged array representation of trajectory profiles
 
 When the number of profiles and levels for each trajectory varies, one can use a ragged array representation.
-Each of the two element dimensions (along a trajectory, within a profile) could in principle be stored either contiguous or indexed, but this convention supports only one of the four possible choices.
+Each of the two element dimensions (along a trajectory, within a profile) could in principle be stored either contiguous or indexed, but these conventions support only one of the four possible choices.
 This uses the contiguous ragged array representation for each profile (9.3.3), and the indexed ragged array representation to organise the profiles into time series (9.3.4).
 The canonical use case is when writing real-time data streams that contain profiles from many trajectories, arriving randomly, with the data for each entire profile written all at once.
 

appm.adoc

@@ -5,15 +5,15 @@
 == Leap Seconds
 
 This appendix describes the treatment of leap seconds in CF in more detail than <<calendar>>, and provides guidance for writers of datasets about the choice of a suitable CF calendar.
-Because precision to the second has rarely been needed in the climate and forecast community, leap seconds have typically been ignored, including in many datasets and versions of the CF standard before 1.12.
+Because precision to the second has rarely been needed in the climate and forecast community, leap seconds have typically been ignored, including in many datasets and versions of the CF conventions before 1.12.
 
 In CF 1.13 and later, __in all calendars except the **`utc`** calendar__,
 
 * any datetime with seconds equal to or greater than 60 is invalid and must not appear as the reference datetime in the **`units`** attribute, and
 
 * the difference is always 60 seconds between the time coordinates for the start of consecutive minutes.
 
-If you are producing model-generated datasets with datetimes that follow the Gregorian calendar, the **`proleptic_gregorian`** calendar is recommended, because it unequivocally indicates to the user of the dataset that leap seconds are not included in the timeline (we assume this is true for model data).
+If you are producing model-generated datasets with datetimes that follow the Gregorian calendar, the **`proleptic_gregorian`** calendar is recommended, because it unequivocally indicates to the user of the dataset that leap seconds are not included in the timeline (it is assumed that this is true for model data).
 On these grounds, it is preferable to the **`standard`** calendar, which is ambiguous in CF versions before 1.13 about the inclusion of leap seconds (see below).
 
 If you are producing real-world datasets with datetimes in UTC, and if it's important for the datetimes and time intervals to be accurate to the second, the **`utc`** calendar is recommended.
@@ -34,7 +34,7 @@ It has the following consequences:
 
 * The difference between two time coordinates will differ from the duration of the time interval between the two instants by the net number of leap seconds that occurred between them.
 
-We illustrate the differences between the **`utc`** and **`standard`** calendars with examples related to the leap second that was added to UTC at the end of 2016.
+The differences between the **`utc`** and **`standard`** calendars are illustrated with examples related to the leap second that was added to UTC at the end of 2016.
  If **`calendar="utc"`** and **`units="seconds since 2016-12-31 23:59:58"`**, a value of 4 for the time coordinate represents the datetime 2017-01-01 00:00:01, because four seconds had elapsed by that instant since 2016-12-31 23:59:58 (seconds ending at 2016-12-31 23:59:59, 2016-12-31 23:59:60, 2017-01-01 00:00:00, 2017-01-01 00:00:01).
 If **`calendar="standard"`**, with the same **`units="seconds since 2016-12-31 23:59:58"`**, the datetime 2017-01-01 00:00:01 is represented by a time coordinate of 3, because the UTC leap second (from 2016-12-31 23:59:60 to 2017-01-01 00:00:00) is ignored when calculating time coordinates in the **`standard`** calendar .
 

cf-conventions.adoc

@@ -51,7 +51,7 @@ This enables users of data from different sources to decide which quantities are
 The CF conventions generalize and extend the COARDS conventions <<COARDS>>.
 The extensions include metadata that provides a precise definition of each variable via specification of a standard name, describes the vertical locations corresponding to dimensionless vertical coordinate values, and provides the spatial coordinates of non-rectilinear gridded data.
 Since climate and forecast data are often not simply representative of points in space/time, other extensions provide for the description of coordinate intervals, multidimensional cells and climatological time coordinates, and indicate how a data value is representative of an interval or cell.
-This standard also relaxes the COARDS constraints on dimension order and specifies methods for reducing the size of datasets.
+These conventions also relax the COARDS constraints on dimension order and specifies methods for reducing the size of datasets.
 
 :numbered:
 include::ch01.adoc[]