anchor.diff:  
   _Bucketing_::
   				A family of aggregations that build buckets, where each bucket is associated with a _key_ and a document
  -				criteria. When the aggregations is executed, the buckets criterias are evaluated on every document in
  -				the context and when matches, the document is considered to "fall in" the relevant bucket. By the end of
  -				the aggreagation process, we'll end up with a list of buckets - each one with a set of documents that
  -				"belong" to it.
  +				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  
  
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 (eg. an `avg` aggregation on a specific field will define the field on which the avg 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.
  
  [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
  <<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
  
negative.code: of that bucket. This is where the real power of aggregations kicks in: *aggregations can be nested!*
  
  NOTE:	Bucketing aggregations can have sub-aggregations (bucketing or metric). The sub aggregations will be computed for 
  		the buckets their parent aggregation generates. There is not hard limit on the level/depth of nested
  		aggregations (one can nest an aggregation under a "parent" aggregation which is itself a sub-aggregation of
  		another higher aggregations)
  
  