[beam-site] 03/04: More updates from review feedback

[me...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git

commit 708bd587b45934e52a12a282b107cb14c4b45171
Author: melissa <me...@google.com>
AuthorDate: Thu Sep 28 18:19:12 2017 -0700

    More updates from review feedback
---
 src/documentation/execution-model.md | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/documentation/execution-model.md b/src/documentation/execution-model.md
index e09fe56..049c7f3 100644
--- a/src/documentation/execution-model.md
+++ b/src/documentation/execution-model.md
@@ -22,14 +22,8 @@ limit the distribution of output to other machines.
 
 ### Serialization and communication
 
-The runner may serialize elements between machines for communication purposes
-and for other reasons such as persistence. For example, a runner may serialize
-and persist elements in these two situations.
-
-1. When used as part of a stateful `DoFn`, the runner may persist values to some
-   state mechanism.
-1. When committing the results of processing, the runner may persist the outputs
-   as a checkpoint.
+The runner might serialize elements between machines for communication purposes
+and for other reasons such as persistence.
 
 A runner may decide to transfer elements between transforms in a variety of
 ways, such as:
@@ -46,6 +40,13 @@ ways, such as:
     This may allow the runner to avoid serializing elements; instead, the runner
     can just pass the elements in memory.
 
+Some situations where the runner may serialize and persist elements are:
+
+1. When used as part of a stateful `DoFn`, the runner may persist values to some
+   state mechanism.
+1. When committing the results of processing, the runner may persist the outputs
+   as a checkpoint.
+
 ### Bundling and persistence
 
 Beam pipelines often focus on "[embarassingly parallel](https://en.wikipedia.org/wiki/embarrassingly_parallel)"
@@ -165,7 +166,7 @@ down and abandoned.
 If a failure to process an element in `ParDo2` causes `ParDo1` to re-execute,
 these two steps are said to be _co-failing_.
 
-For this example, we will use the dependently parallel `ParDo`s from figure 4.
+For this example, we will use the two `ParDo`s from figure 4.
 
 In figure 7, worker two successfully executes `ParDo1` on all elements in bundle
 B. However, the worker fails to process an element in bundle D, so `ParDo2`

-- 
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.