anchor.diff:  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
  +===== 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
  
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: are presented unstemmed, highlighted, with the right case, in the right order and with some context, their significance/meaning is more readily apparent.
  ============
  
  ==== Limitations
  
  ===== Single _background_ comparison base
  The above examples show how to select the _foreground_ set for analysis using a query or parent aggregation to filter but currently there is no means of specifying
  a _background_ set other than the index from which all results are ultimately drawn. Sometimes it may prove useful to use a different
  background set as the basis for comparisons e.g. to first select the tweets for the TV show "XFactor" and then look
  for significant terms in a subset of that content which is from this week. 
  
  ===== Significant terms must be indexed values
  Unlike the terms aggregation it is currently not possible to use script-generated terms for counting purposes.
  Because of the way the significant_terms aggregation must consider both _foreground_ and _background_ frequencies
  it would be prohibitively expensive to use a script on the entire index to obtain background frequencies for comparisons.
  Also DocValues are not supported as sources of term data for similar reasons.
  
  ===== No analysis of floating point fields
  Floating point fields are currently not supported as the subject of significant_terms analysis.
  While integer or long fields can be used to represent concepts like bank account numbers or category numbers which
  can be interesting to track, floating point fields are usually used to represent quantities of something. 
  As such, individual floating point terms are not useful for this form of frequency analysis. 
  
  ===== Use as a parent aggregation
  If there is the equivalent of a `match_all` query or no query criteria providing a subset of the index the significant_terms aggregation should not be used as the 
  top-most aggregation - in this scenario the _foreground_ set is exactly the same as the _background_ set and
  so there is no difference in document frequencies to observe and from which to make sensible suggestions.
  