incubator-tinkerpop git commit: grammar tweaks to the MatchStep section of the docs.

[ok...@apache.org]

Repository: incubator-tinkerpop
Updated Branches:
  refs/heads/master 0297f15ae -> 7f1ecadaf


grammar tweaks to the MatchStep section of the docs.


Project: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/commit/7f1ecada
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/tree/7f1ecada
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/diff/7f1ecada

Branch: refs/heads/master
Commit: 7f1ecadafa7a7aeca4bf5288e9b3fb65c62bef66
Parents: 0297f15
Author: Marko A. Rodriguez <ok...@gmail.com>
Authored: Fri Jun 19 12:00:29 2015 -0600
Committer: Marko A. Rodriguez <ok...@gmail.com>
Committed: Fri Jun 19 12:00:37 2015 -0600

----------------------------------------------------------------------
 docs/src/the-traversal.asciidoc | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/7f1ecada/docs/src/the-traversal.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/the-traversal.asciidoc b/docs/src/the-traversal.asciidoc
index 1b77f62..0b6124f 100644
--- a/docs/src/the-traversal.asciidoc
+++ b/docs/src/the-traversal.asciidoc
@@ -706,7 +706,7 @@ WARNING: The anonymous traversal of `local()` processes the current object "loca
 Match Step
 ~~~~~~~~~~
 
-The `match()`-step (*map*) provides a more link:http://en.wikipedia.org/wiki/Declarative_programming[declarative] form of graph querying based on the notion of link:http://en.wikipedia.org/wiki/Pattern_matching[pattern matching]. With `match()`, the user provides a collection of "traversal fragments," called patterns, that have variables defined that much hold true throughout the duration of the `match()`. When a traverser is in `match()`, a registered `MatchAlgorithm` analyzes the current state of the traverser (i.e. its history based on its <<path-data-structure,path data>>) and returns a traversal-pattern that the traverser should try next. The default `MatchAlgorithm` provided is `CountMatchAlgorithm` and it dynamically revises the pattern execution plan by sorting the patterns according to their filtering capabilities (i.e. largest set reduction patterns execute first). For very large graphs, where the developer is uncertain of the statistics of the graph (e.g. how many `knows`
 -edges vs. `worksFor`-edges exist in the graph), it is advantageous to use `match()`, as an optimal plan will be determined automatically. Furthermore, some queries are much easier to express via `match()` than with single-path traversals.
+The `match()`-step (*map*) provides a more link:http://en.wikipedia.org/wiki/Declarative_programming[declarative] form of graph querying based on the notion of link:http://en.wikipedia.org/wiki/Pattern_matching[pattern matching]. With `match()`, the user provides a collection of "traversal fragments," called patterns, that have variables defined that must hold true throughout the duration of the `match()`. When a traverser is in `match()`, a registered `MatchAlgorithm` analyzes the current state of the traverser (i.e. its history based on its <<path-data-structure,path data>>), the runtime statistics of the traversal patterns, and returns a traversal-pattern that the traverser should try next. The default `MatchAlgorithm` provided is called `CountMatchAlgorithm` and it dynamically revises the pattern execution plan by sorting the patterns according to their filtering capabilities (i.e. largest set reduction patterns execute first). For very large graphs, where the developer is uncer
 tain of the statistics of the graph (e.g. how many `knows`-edges vs. `worksFor`-edges exist in the graph), it is advantageous to use `match()`, as an optimal plan will be determined automatically. Furthermore, some queries are much easier to express via `match()` than with single-path traversals.
 
     "Who created a project named 'lop' that was also created by someone who is 29 years old? Return the two creators."
 
@@ -721,7 +721,7 @@ g.V().match('a',
         __.as('c').has('age', 29)).select('a','c').by('name')
 ----
 
-Note that the above can also be more concisely written as below which demonstrates that imperative inner-traversals can be arbitrarily defined.
+Note that the above can also be more concisely written as below which demonstrates that standard inner-traversals can be arbitrarily defined.
 
 [gremlin-groovy,modern]
 ----
@@ -759,7 +759,7 @@ g.V().match('a',
 
 <1> *Patterns of arbitrary complexity*: `match()` is not restricted to triple patterns or property paths.
 <2> *Recursion support*: `match()` supports the branch-based steps within a pattern, including `repeat()`.
-<3> *Imperative/declarative hybrid*: Pre and prior to a `match()`, it is possible to leverage classic Gremlin traversals.
+<3> *Imperative/declarative hybrid*: Before and after a `match()`, it is possible to leverage classic Gremlin traversals.
 
 To extend point #3, it is possible to support going from imperative, to declarative, to imperative, ad infinitum.
 
@@ -775,7 +775,7 @@ g.V().match('a',
             select('z').values('name')
 ----
 
-IMPORTANT: The `match()`-step is stateless where the variable bindings of the traversal patterns are stored in the path history of the traverser. As such, the variables used over all `match()`-steps within a traversal are globally unique. A benefit of this is that subsequent `where()`, `select()`, `match()`, etc. steps can leverage the same variables in their analysis.
+IMPORTANT: The `match()`-step is stateless. The variable bindings of the traversal patterns are stored in the path history of the traverser. As such, the variables used over all `match()`-steps within a traversal are globally unique. A benefit of this is that subsequent `where()`, `select()`, `match()`, etc. steps can leverage the same variables in their analysis.
 
 Like all other steps in Gremlin, `match()` is a function and thus, `match()` within `match()` is a natural consequence of Gremlin's functional foundation (i.e. recursive matching).
 
@@ -798,7 +798,7 @@ There are four types of `match()` traversal patterns.
   . `...as('b')`: only the end of the traversal has a declared variable.
   . `...`: there are no declared variables.
 
-If a variable is at the start of a traversal pattern it *must* exist as a label in the path history of the traverser else the traverser can not go down that path. If a variable is at the end of a traversal pattern then if the variable exists in the path history of the traverser, the traverser's current location must match (i.e. equal) its historic location at that same label. However, if the variable does not exist in the path history of the traverser, then the current location is labeled as the variable and thus, becomes a bound variable for subsequent traversal patterns. If a traversal pattern does not have an end label, then the traverser must simply "survive" the pattern to continue to the next pattern. If a traversal pattern does not have a start label, then the traverser can go down that path at any point, but will only go down that pattern once as a traversal pattern is executed once and only once for the history of the traverser. Typically, traversal patterns that do not hav
 e a start label are used in conjunction with `and()`, `or()`, and `where()`. Once the traverser has "survived" (i.e. not filtered) all the patterns (or at least one for `or()`), `match()`-step analyzes the traversers path history and emits a `Map<String,Object>` of the variable bindings to the next step in the traversal.
+If a variable is at the start of a traversal pattern it *must* exist as a label in the path history of the traverser else the traverser can not go down that path. If a variable is at the end of a traversal pattern then if the variable exists in the path history of the traverser, the traverser's current location *must* match (i.e. equal) its historic location at that same label. However, if the variable does not exist in the path history of the traverser, then the current location is labeled as the variable and thus, becomes a bound variable for subsequent traversal patterns. If a traversal pattern does not have an end label, then the traverser must simply "survive" the pattern (i.e. not be filtered) to continue to the next pattern. If a traversal pattern does not have a start label, then the traverser can go down that path at any point, but will only go down that pattern once as a traversal pattern is executed once and only once for the history of the traverser. Typically, traversal
  patterns that do not have a start and end label are used in conjunction with `and()`, `or()`, and `where()`. Once the traverser has "survived" all the patterns (or at least one for `or()`), `match()`-step analyzes the traverser's path history and emits a `Map<String,Object>` of the variable bindings to the next step in the traversal.
 
 [gremlin-groovy,modern]
 ----
@@ -812,7 +812,7 @@ g.V().as('a').out().as('b'). <1>
     ).select('a','b','c').by('name').by('name').by() <6>
 ----
 
-<1> A standard, labeled traversal can come prior to `match()`.
+<1> A standard, step-labeled traversal can come prior to `match()`.
 <2> If the traverser's path prior to entering `match()` has the requisite variables, then no "start variable" is needed.
 <3> It is possible to use <<a-note-on-barrier-steps,barrier steps>> though they are computed locally to the pattern (as one would expect).
 <4> It is possible to nest `and()`- and `or()`-steps for conjunction matching.
@@ -823,7 +823,7 @@ g.V().as('a').out().as('b'). <1>
 Using Where with Match
 ^^^^^^^^^^^^^^^^^^^^^^
 
-Match is typically used in conjunction with both `select()` (demonstrated previously) and `where()` (presented here). A `where()` allows the user to further constrain the result set provided by `match()`.
+Match is typically used in conjunction with both `select()` (demonstrated previously) and `where()` (presented here). A `where()`-step allows the user to further constrain the result set provided by `match()`.
 
 [gremlin-groovy,modern]
 ----
@@ -833,7 +833,7 @@ g.V().match('a',
           where('a', neq('c')).select('a','c').by('name')
 ----
 
-The `where()`-step can take either a `P`-predicate (example above) or a `Traversal` (example below). Using `MatchPredicateStrategy`, `where()`-clauses can be automatically folded into `match()` and thus, subject to the query optimizer within `match()`-step.
+The `where()`-step can take either a `P`-predicate (example above) or a `Traversal` (example below). Using `MatchPredicateStrategy`, `where()`-clauses are automatically folded into `match()` and thus, subject to the query optimizer within `match()`-step.
 
 [gremlin-groovy,modern]
 ----