anchor.diff:  
   <<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
  +(filtered queries, top-level filters, and facet level filters). While powerful, their implementation is not designed
   from ground up to support complex aggregations and thus limited.
   
   .Are facets deprecated?
   **********************************
  -As the functionality facets offer is a subset of the the one offered by aggregations, over time, we would like to
  +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 the facets around for the time being.
  -Nonetheless, facets are and should be considered deprecated and will likely be removed in one of the future major
  -releases.
  +Facets are not officially deprecated yet but are likely to be in the future.
   **********************************
   
   The aggregations module breaks the barriers the current facet implementation put in place. The new name ("Aggregations")
  -also indicate the intention here - a generic yet extremely powerful framework for building aggregations - any types of
  +also indicates the intention here - a generic yet extremely powerful framework for building aggregations - any types of
   aggregations.
   
   An aggregation can be seen as a _unit-of-work_ that builds analytic information over a set of documents. The context of
  -the execution defines what this document set is (e.g. a top level aggregation executes within the context of the executed
  +the execution defines what this document set is (e.g. a top-level aggregation executes within the context of the executed
   query/filters of the search request).
   
   There are many different types of aggregations, each with its own purpose and output. To better understand these types,
  
positive.code: that "fell in" each bucket.
  
  Bucket aggregations, as opposed to `metrics` aggregations, can hold sub-aggregations. These sub aggregations will be
  aggregated for each of 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
  define fixed number of multiple buckets, and others dynamically create the buckets during the aggregation process.
  
negative.code: 
  _Bucketing_::
  				A family of aggregations that build buckets, where each bucket is associated with a _key_ and a document
  				criterion. When the aggregation is executed, all the buckets criteria are evaluated on every document in
  				the context and when a criterion matches, the document is considered to "fall in" the relevant bucket.
  				By the end of the aggregation process, we'll end up with a list of buckets - each one with a set of
  				documents that "belong" to it.
  
  _Metric_::
  				Aggregations that keep track and compute metrics over a set of documents  
  