anchor.diff:  }
   --------------------------------------------------
   
  -The `aggregations` object (the key `aggs` can also be used) in the json holds the aggregations to be computed. Each aggregation
  +The `aggregations` object (the key `aggs` can also be used) in the JSON holds the aggregations to be computed. Each aggregation
   is associated with a logical name that the user defines (e.g. if the aggregation computes the average price, then it'll
   make sense to name it `avg_price`). These logical names will also be used to uniquely identify the aggregations in the
   response. Each aggregation has a specific type (`<aggregation_type>` in the above snippet) and is typically the first
   key within the named aggregation body. Each type of aggregation define its own body, depending on the nature of the
  -aggregation (eg. an `avg` aggregation on a specific field will define the field on which the avg will be calculated).
  +aggregation (e.g. an `avg` aggregation on a specific field will define the field on which the average will be calculated).
   At the same level of the aggregation type definition, one can optionally define a set of additional aggregations,
   though this only makes sense if the aggregation you defined is of a bucketing nature. In this scenario, the
   sub-aggregations you define on the bucketing aggregation level will be computed for all the buckets built by the
   bucketing aggregation. For example, if the you define a set of aggregations under the `range` aggregation, the
  -sub-aggregations will be computed for each of the range buckets that are defined.
  +sub-aggregations will be computed for the range buckets that are defined.
   
   [float]
   ==== Values Source
   
   Some aggregations work on values extracted from the aggregated documents. Typically, the values will be extracted from
  -a sepcific document field which is set under the `field` settings for the aggrations. It is also possible to define a
  +a specific document field which is set using the `field` key for the aggregations. It is also possible to define a
   <<modules-scripting,`script`>> that will generate the values (per document).
   
   When both `field` and `script` settings are configured for the aggregation, the script will be treated as a
  
positive.code: include::aggregations/metrics.asciidoc[]
  
  include::aggregations/bucket.asciidoc[]
  
  
  
negative.code: ["NOTE",id="aggs-script-note"]
  ===============================
  When working with scripts, the `lang` and `params` settings can also be defined. The former defines the scripting
  language that is used (assuming the proper language is available in Elasticsearch either by default or as a plugin). The latter
  enables defining all the "dynamic" expressions in the script as parameters, and by that keep the script itself static
  between calls (this will ensure the use of the cached compiled scripts in Elasticsearch).
  ===============================
  
  Scripts can generate a single value or multiple values per documents. When generating multiple values, once can use the
  `script_values_sorted` settings to indicate whether these values are sorted or not. Internally, Elasticsearch can
  perform optimizations when dealing with sorted values (for example, with the `min` aggregations, knowing the values are
  sorted, Elasticsearch will skip the iterations over all the values and rely on the first value in the list to be the
  minimum value among all other values associated with the same document).
  
  [float]
  