anchor.diff:  Like most design decisions, this is the basis of a trade-off in which we have chosen to provide fast performance at the cost of some (typically small) inaccuracies.
   However, the `size` and `shard size` settings covered in the next section provide tools to help control the accuracy levels. 
   
  -
  -=== Parameters
  -
  -
  -==== Size & Shard Size
  +==== Parameters
  +
  +
  +===== Size & Shard Size
   
   The `size` parameter can be set to define how many term buckets should be returned out of the overall terms list. By
   default, the node coordinating the search process will request each shard to provide its own top term buckets
  
positive.code:          default value of 3 is used to provide a minimum weight-of-evidence.
  
  
  ==== Filtering Values
  
  It is possible (although rarely required) to filter the values for which buckets will be created. This can be done using the `include` and
  `exclude` parameters which are based on regular expressions. This functionality mirrors the features
  
negative.code: http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#UNICODE_CHARACTER_CLASS[`UNICODE_CHARACTER_CLASS`] and
  http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#UNIX_LINES[`UNIX_LINES`]
  
  ===== Execution hint
  
  There are two mechanisms by which terms aggregations can be executed: either by using field values directly in order to aggregate
  data per-bucket (`map`), or by using ordinals of the field values instead of the values themselves (`ordinals`). Although the
  