anchor.diff:  === Bucket Aggregations
   
   Bucket aggregations don't calculate metrics over fields like the metrics aggregations do, but instead, they create
  -buckets of documents. Each bucket is associated with a criteria (depends on the aggregation type) that determines
  -whether or not a document in the current context "falls" in it. In other words, the buckets effectively define document
  +buckets of documents. Each bucket is associated with a criteria (depending on the aggregation type) which determines
  +whether or not a document in the current context "falls" into it. In other words, the buckets effectively define document
   sets. In addition to the buckets themselves, the `bucket` aggregations also compute and return the number of documents
  -that "fell in" each bucket.
  +that "fell in" to each bucket.
   
  -Bucket aggregations, as opposed to `metrics` aggregations, can hold sub-aggregations. These sub aggregations will be
  +Bucket aggregations, as opposed to `metrics` aggregations, can hold sub-aggregations. These sub-aggregations will be
   aggregated for the buckets created by their "parent" bucket aggregation.
   
   There are different bucket aggregators, each with a different "bucketing" strategy. Some define a single bucket, some
  
positive.code: --------------------------------------------------
  
  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 (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 the range buckets that are defined.
  
  [float]
  
negative.code: <<search-facets, Facets>> provide a great way to aggregate data within a document set context.
  This context is defined by the executed query in combination with the different levels of filters that can be defined
  (filtered queries, top-level filters, and facet level filters). While powerful, their implementation is not designed
  from the ground up to support complex aggregations and is thus limited.
  
  .Are facets deprecated?
  **********************************
  As the functionality facets offer is a subset of the one offered by aggregations, over time, we would like to
  see users move to aggregations for all realtime data analytics. That said, we are well aware that such
  transitions/migrations take time, and for this reason we are keeping facets around for the time being.
  Facets are not officially deprecated yet but are likely to be in the future.
  **********************************
  
  