README.md in rflow-1.0.1 vs README.md in rflow-1.1.0

@@ -11,11 +11,11 @@
 [Storm](http://storm.incubator.apache.org/), and Clojure's
 [core.async](http://clojure.github.io/core.async/) library.
 
 In short, components communicate with each other by sending/receiving
 messages via their output/input ports over connections. Ports are
-"wired" together output->input with connections, and messages are
+'wired' together output->input with connections, and messages are
 explicitly serialized before being sent over the connection. RFlow
 supports generalized connection types and message serialization,
 however only two are in current use, namely ZeroMQ connections and
 Avro serialization.
 
@@ -56,11 +56,11 @@
   communicates with the rest of the system through explicit message
   passing via input and output ports.
 
 * __Port__ - a named entity on each component that is responsible for
   receiving data (and input port) or sending data (and output port).
-  Ports can be "keyed" or "indexed" to allow better multiplexing of
+  Ports can be 'keyed' or 'indexed' to allow better multiplexing of
   messages out/in a single port, as well as allow a single port to be
   accessed by an array.
 
 * __Connection__ - a directed link between an output port and an input
   port.  RFlow supports generalized connection types; however, only
@@ -68,11 +68,11 @@
   delivery are supported on a per-link basis.
 
 * __Message__ - a bit of serialized data that is sent out an output
   port and received on an input port. Due to the serialization,
   message types and schemas are explicitly defined. In a departure
-  from "pure" FBP, RFlow supports sending multiple message types via a
+  from 'pure' FBP, RFlow supports sending multiple message types via a
   single connection.
 
 * __Workflow__ - the common name for the digraph created when the
   components (nodes) are wired together via connections to their
   respective output/input ports.
@@ -124,11 +124,11 @@
 
 * `cleanup!` is the final call to each component, and allow the
   component to clean up any external resources that it might have
   outstanding, such as file handles or network sockets.
 
-"Source" components will often do all of their work within the `run!`
+'Source' components will often do all of their work within the `run!`
 method, and often gather message data from an external source, such as
 file, database, or network socket. The following component generates a
 set of integers between a configured start/finish, incrementing by a
 configured step:
 
@@ -156,11 +156,11 @@
     end
   end
 end
 ```
 
-"Middle" components receive messages on input port(s), perform a bit
+'Middle' components receive messages on input port(s), perform a bit
 of computation, and then send a message out the output port(s). The
 following component accepts a Ruby expression string via its config,
 and then uses that as an expression to determine what port to send an
 incoming message:
 
@@ -187,11 +187,11 @@
     end
   end
 end
 ```
 
-"Sink" components accept messages on an input port and do not have an
+'Sink' components accept messages on an input port and do not have an
 output port. They often operate on external sinks, such as writing
 messages to a file, database, or network socket. The following
 component writes the inspected message to a file (defined via the
 configuration):
 
@@ -218,13 +218,13 @@
 
 ## RFlow Messages
 
 RFlow messages are instances of
 [`RFlow::Message`](lib/rflow/message.rb), which are ultimately
-serialized via an Avro [schema](schema/message.zvsc).
+serialized via an Avro [schema](schema/message.avsc).
 
-There are two parts of the message "envelope": a provenance and the
-embedded data object "payload".
+There are two parts of the message 'envelope': a provenance and the
+embedded data object 'payload'.
 
 The `provenance` is a way for a component to annotate a message with a
 bit of data that should (by convention) be carried through the
 workflow with the message, as well as being copied to derived
 messages. For example, a TCP server component would spin up a TCP