changed missing task references

Signed-off-by: SamMarkowitz <[email protected]>

code/examples_code/examples/defaultnav/nav_flow.sl

@@ -13,12 +13,12 @@ flow:
           produce_default_navigation:
             - navigation_type
 
-    # default navigation - go to this task on success
+    # default navigation - go to this step on success
     - do_something:
         do:
           something:
 
-    # default navigation - go to this task on failure
+    # default navigation - go to this step on failure
     - on_failure:
       - send_error_mail:
           do:

developer_architecture.rst

@@ -11,7 +11,7 @@ source file must undergo a process to transform it into a Score
 Precompilation
 --------------
 
-In the precompilation process, the source file is loaded, along with its 
+In the precompilation process, the source file is loaded, along with its
 dependencies if necessary, and parsed. The CloudSlang
 file's YAML structure is translated into Java maps by the ``YamlParser``
 using `snakeyaml <http://snakeyaml.org>`__. The parsed structure is
@@ -54,7 +54,7 @@ Generally, CloudSlang treats flows and operations similarly.
 Flows and operations both:
 
 -  Receive inputs, produce outputs, and have navigation logic.
--  Can be called by a flow's task.
+-  Can be called by a flow's step.
 -  Are compiled to ``ExecutionPlan``\ s that can be run by Score.
 
 Scoped Contexts
@@ -86,18 +86,18 @@ steps are built using their corresponding methods in the
 There are five types of :ref:`ExecutionSteps <execution_step>` used to build
 a CloudSlang :ref:`ExecutionPlan <execution_plan>`:
 
--  Start Step
+-  Start
+-  End 
+-  Begin Step
 -  End Step
--  Begin Task Step
--  End Task Step
--  Action Step
+-  Action
 
 An operation's :ref:`ExecutionPlan <execution_plan>`
 is built from a Start Step, an Action Step and an End Step.
 
 A flow's :ref:`ExecutionPlan <execution_plan>` is
-built from a Start Step, a series of Begin Task Steps and End Task
-Steps, and an End Step. The task steps hand off the execution to other
+built from a Start Step, a series of Begin Step Steps and End Step
+Steps, and an End Step. The step steps hand off the execution to other
 :ref:`ExecutionPlan <execution_plan>` objects representing operations or subflows.
 
 .. figure:: images/execution_steps.png

tutorial/02_lesson.rst

@@ -75,7 +75,7 @@ to print. We'll name our input ``text``.
 
 The values for the inputs are either passed via the :doc:`CloudSlang
 CLI <../cloudslang_cli>`, as we do below in this lesson, or from a
-task in a flow, as we will do in the next lesson.
+step in a flow, as we will do in the next lesson.
 
 Inputs can also have related parameters, such as ``required``,
 ``default`` and ``overridable``. We will discuss these parameters in lessons

tutorial/04_lesson.rst

@@ -80,7 +80,7 @@ For more information, see :ref:`expressions` in the DSL reference.
 
 At this point we won't be using the output value, but we will soon
 enough. In lesson :doc:`5 - Default Navigation <05_lesson>` we publish
-the ``available`` output and use it in another task.
+the ``available`` output and use it in another step.
 
 For more information, see :ref:`outputs` in the DSL reference.
 

tutorial/06_lesson.rst

@@ -18,8 +18,8 @@ Failure Handling
 ----------------
 
 There is special syntax that can be used for handling ``FAILURE``
-results by default. We wrap a task inside the ``on_failure`` key. Let's
-add this functionality after the ``print_finish`` task.
+results by default. We wrap a step inside the ``on_failure`` key. Let's
+add this functionality after the ``print_finish`` step.
 
 .. code-block:: yaml
 
@@ -29,8 +29,8 @@ add this functionality after the ``print_finish`` task.
             base.print:
               - text: "${'Failed to create address: ' + address}"
 
-Now, when any task receives a result of ``FAILURE`` from its operation
-the flow will navigate to the ``on_failure`` task by default.
+Now, when any step receives a result of ``FAILURE`` from its operation
+the flow will navigate to the ``on_failure`` step by default.
 
 For more information, see :ref:`on_failure` in the DSL reference.
 
@@ -46,14 +46,14 @@ lesson. This time, however, things should work slightly differently.
 
 In the case of the ``check_availability`` operation returning a result
 of ``SUCCESS`` we expect the flow to behave exactly as it did before.
-Notice that this means it will know not to run the ``on_failure`` task
+Notice that this means it will know not to run the ``on_failure`` step
 without us adding any navigation instructions. This is part of the
 default navigation behavior.
 
 In the case of the ``check_availability`` operation returning a result
 of ``FAILURE`` the flow will no longer terminate immediately with a
 result of ``FAILURE``. Instead, the flow will continue by running the
-``on_failure`` task, which in our case prints out an error message.
+``on_failure`` step, which in our case prints out an error message.
 
 Download the Code
 -----------------

tutorial/07_lesson.rst

@@ -36,9 +36,9 @@ Now that we've customized the result labels, the flow doesn't know what
 to do upon receipt of these results. Instead of relying on the default
 navigation, we'll have to explicitly tell the flow what to do next. For
 now, we'll just replicate what the flow would have done in the default
-navigation. We have to add navigation logic to the task for all possible
+navigation. We have to add navigation logic to the step for all possible
 results. We do so under the ``navigate`` key. Each possible result is a list
-item mapped to the task that should be navigated to when returned.
+item mapped to the step that should be navigated to when returned.
 
 .. code-block:: yaml
 

tutorial/08_lesson.rst

@@ -72,12 +72,12 @@ happens.
 Add to Flow
 -----------
 
-Let's add a task in the **new_hire** flow to call our new operation.
+Let's add a step in the **new_hire** flow to call our new operation.
 That will allow us to demonstrate how input properties affect the way
 variables are passed to operations.
 
-Between the ``print_start`` task and ``check_address`` task we'll put
-our new task named ``generate_address``.
+Between the ``print_start`` step and ``check_address`` step we'll put
+our new step named ``generate_address``.
 
 .. code-block:: yaml
 
@@ -95,7 +95,7 @@ our new task named ``generate_address``.
 We'll also have to change the inputs of the flow to reflect our new
 addition. We can remove the ``address`` from the flow inputs since we'll
 now be getting the address from the ``generate_user_email`` operation
-and publishing it in the ``generate_address`` task. Instead, we need to
+and publishing it in the ``generate_address`` step. Instead, we need to
 add the inputs necessary for the ``generate_user_email`` operation to
 the flow's inputs section.
 
@@ -229,7 +229,7 @@ above. You'll notice that no matter what is passed to the ``domain``
 input, ``acompany.com`` is what ends up in the email address. That's
 exactly what we want, but obviously there is no reason to pass values to
 the domain variable anymore. So let's just remove it from the flow
-inputs and the ``generate_address`` task.
+inputs and the ``generate_address`` step.
 
 .. code-block:: yaml
 

tutorial/09_lesson.rst

@@ -38,7 +38,7 @@ this section.
         - attempt
 
 Next let's create a ``workflow`` section and copy the
-``generate_address`` and ``check_address`` tasks into it.
+``generate_address`` and ``check_address`` steps into it.
 
 .. code-block:: yaml
 
@@ -84,11 +84,11 @@ of three result options.
       - UNAVAILABLE
       - FAILURE
 
-Now we can reroute the tasks' navigation to point to the flow results we
+Now we can reroute the steps' navigation to point to the flow results we
 just defined.
 
-For the ``generate_address`` task, whose operation returns ``SUCCESS``
-or ``FAILURE``, we can route ``SUCCESS`` to the next task and
+For the ``generate_address`` step, whose operation returns ``SUCCESS``
+or ``FAILURE``, we can route ``SUCCESS`` to the next step and
 ``FAILURE`` to the ``FAILURE`` result of the flow.
 
 .. code-block:: yaml
@@ -106,7 +106,7 @@ or ``FAILURE``, we can route ``SUCCESS`` to the next task and
           - SUCCESS: check_address
           - FAILURE: FAILURE
 
-For the ``check_address`` task, whose operation returns ``UNAVAILABLE``
+For the ``check_address`` step, whose operation returns ``UNAVAILABLE``
 or ``AVAILABLE``, we can route ``UNAVAILABLE`` to the ``UNAVAILABLE``
 result of the flow and ``AVAILABLE`` to the ``CREATED`` result of the
 flow.
@@ -123,7 +123,7 @@ flow.
           - UNAVAILABLE: UNAVAILABLE
           - AVAILABLE: CREATED
 
-Finally, we can pass along the outputs published in the tasks as flow
+Finally, we can pass along the outputs published in the steps as flow
 outputs.
 
 .. code-block:: yaml
@@ -150,15 +150,15 @@ Fix Up Parent Flow
 Finally, let's make changes to our original flow so that it makes use of
 the subflow we just created.
 
-First let's replace the two tasks we took out with one new task that
+First let's replace the two steps we took out with one new step that
 calls the subflow instead of an operation. You may have noticed that
 both flows and operations take inputs, return outputs and return
 results. That allows us to use them almost interchangeably. We've run
 both flows and operations using the CLI. Now we see that we can call
-them both from tasks as well.
+them both from steps as well.
 
-Delete the ``generate_address`` and ``check_address`` tasks. We'll now replace
-them with a new task called ``create_email_address``. It will pass along the
+Delete the ``generate_address`` and ``check_address`` steps. We'll now replace
+them with a new step called ``create_email_address``. It will pass along the
 flow inputs, publish the necessary outputs and wire up the appropriate
 navigation.
 
@@ -179,7 +179,7 @@ navigation.
           - FAILURE: print_fail
 
 All that's left now is to change the text of the messages sent in the
-``print_finish`` and ``print_fail`` tasks to better reflect what is
+``print_finish`` and ``print_fail`` steps to better reflect what is
 happening.
 
 .. code-block:: bash
@@ -217,7 +217,7 @@ Download the Code
 Up Next
 -------
 
-In the next lesson we'll change our new task to include a loop which
+In the next lesson we'll change our new step to include a loop which
 will retry the email creation several times if necessary.
 
 New Code - Complete

tutorial/12_lesson.rst

@@ -105,15 +105,15 @@ it doesn't reside where our other operations and subflows do.
 
 For more information, see :ref:`imports` in the DSL reference.
 
-Task
+Step
 ----
 
-Then, all we really need to do is create a task in our flow that will
+Then, all we really need to do is create a step in our flow that will
 call the ``send_mail`` operation. Let's put it right after the
 ``print_finish`` operation. We need to pass a host, port, from, to,
 subject and body. You'll need to substitute the values in angle brackets
 (``<>``) to work for your email host. Notice that the body value is
-taken directly from the ``print_finish`` task with the slight change of
+taken directly from the ``print_finish`` step with the slight change of
 turning the ``\n`` into a ``<br>`` since the ``html_email`` input
 defaults to true.
 

yaml_overview.rst

@@ -14,7 +14,7 @@ Unlike many programming, markup, and data serialization languages,
 whitespace is syntactically significant. Indentation is used to denote
 scope and is always achieved using spaces. Never use tabs.
 
-**Example: a CloudSlang task (in this case named divider) contains do,
+**Example: a CloudSlang step (in this case named divider) contains do,
 publish and navigate keys**
 
 .. code:: yaml
@@ -51,7 +51,7 @@ Maps
 Maps are denoted use a colon (``:``) and a space between each key value
 pair.
 
-**Example: a CloudSlang task's navigate key is mapped to a mapping of
+**Example: a CloudSlang step's navigate key is mapped to a mapping of
 results and their targets**
 
 .. code:: yaml