anchor.diff:  // TESTRESPONSE[s/"query": \[...\]/"query": $body.$_path/]
   // TESTRESPONSE[s/"collector": \[...\]/"collector": $body.$_path/]
   // TESTRESPONSE[s/"aggregations": \[...\]/"aggregations": []/]
  -<1> A profile is returned for each shard that participated in the response, and is identified
  -by a unique ID
  -<2> Each profile contains a section which holds details about the query execution
  -<3> Each profile has a single time representing the cumulative rewrite time
  -<4> Each profile also contains a section about the Lucene Collectors which run the search
  -<5> Each profile contains a section which holds the details about the aggregation execution
  -
  -Because a search request may be executed against one or more shards in an index, and a search may cover
  -one or more indices, the top level element in the profile response is an array of `shard` objects.
  -Each shard object lists its `id` which uniquely identifies the shard.  The ID's format is
  +<1> A profile is returned for each shard that participated in the response, and 
  +is identified by a unique ID.
  +<2> Each profile contains a section which holds details about the query 
  +execution.
  +<3> Each profile has a single time representing the cumulative rewrite time.
  +<4> Each profile also contains a section about the Lucene Collectors which run 
  +the search.
  +<5> Each profile contains a section which holds the details about the 
  +aggregation execution.
  +
  +Because a search request may be executed against one or more shards in an index, 
  +and a search may cover one or more indices, the top level element in the profile 
  +response is an array of `shard` objects. Each shard object lists its `id` which 
  +uniquely identifies the shard.  The ID's format is 
   `[nodeID][indexName][shardID]`.
   
  -The profile itself may consist of one or more "searches", where a search is a query executed against the underlying
  -Lucene index.  Most search requests submitted by the user will only execute a single `search` against the Lucene index.
  -But occasionally multiple searches will be executed, such as including a global aggregation (which needs to execute
  -a secondary "match_all" query for the global context).
  +The profile itself may consist of one or more "searches", where a search is a 
  +query executed against the underlying Lucene index.  Most search requests 
  +submitted by the user will only execute a single `search` against the Lucene 
  +index. But occasionally multiple searches will be executed, such as including a 
  +global aggregation (which needs to execute a secondary "match_all" query for the 
  +global context).
   
   Inside each `search` object there will be two arrays of profiled information:
  -a `query` array and a `collector` array.  Alongside the `search` object is an `aggregations` object that contains the profile information for the aggregations. In the future, more sections may be added, such as `suggest`, `highlight`, etc.
  -
  -There will also be a `rewrite` metric showing the total time spent rewriting the query (in nanoseconds).
  +a `query` array and a `collector` array.  Alongside the `search` object is an 
  +`aggregations` object that contains the profile information for the 
  +aggregations. In the future, more sections may be added, such as `suggest`, 
  +`highlight`, etc.
  +
  +There will also be a `rewrite` metric showing the total time spent rewriting the 
  +query (in nanoseconds).
   
   NOTE: As with other statistics apis, the Profile API supports human readable outputs. This can be turned on by adding
   `?human=true` to the query string. In this case, the output contains the additional `time` field containing rounded,
  
positive.code: [[query-section]]
  ===== `query` Section
  
  The `query` section contains detailed timing of the query tree executed by Lucene on a particular shard.
  The overall structure of this query tree will resemble your original Elasticsearch query, but may be slightly
  (or sometimes very) different.  It will also use similar but not always identical naming.  Using our previous
  `match` query example, let's analyze the `query` section:
  
  [source,console-result]
  --------------------------------------------------
  
negative.code: // TEST[setup:twitter]
  
  <1> Setting the top-level `profile` parameter to `true` will enable profiling
  for the search.
  
  
  The API returns the following result:
  
  [source,console-result]
  --------------------------------------------------
  