Update README.md

Reworked the Discussion: Compositional Loggers section.

Author: inkade

README.md

@@ -8,35 +8,21 @@
 
 # Discussion: Compositional Loggers
 
-LoggingExtras is designs around allowing you to build arbitrarily complicated
-systems for "log plumbing". That is to say basically routing logged information to different places.
-It is built around the idea of simple parts which are composed together,
-to allow for powerful and flexible definition of your logging system.
-Without you having to define any custom loggers by subtyping `AbstractLogger`.
-When we talk about composability we mean to say that the composition of any set of Loggers is itself a Logger.
-LoggingExtras is a composable logging system.
+When constructing complicated "log plumbing" systems, LoggingExtras allows for routing logged information to different places. Built upon the concept of simple parts composed together, LoggingExtras provides a powerful and flexible definition of your logging system without a need to define any custom loggers by subtyping `AbstractLogger`.
+When we talk about composability, the composition of any set of Loggers is itself a Logger, and LoggingExtras is a composable logging system.
 
 Loggers can be broken down into 4 types:
- - *Sinks*: Sinks are the final end point of a log messages journey. They write it to file, or display it on the console, or set off a red flashing light in the laboratory. A Sink should never decide what to accept, only what to do with it.
- - *Filters*: Filters wrap around other loggers and decide whether or not to pass on a message. They can further be broken down by when that decision occurs (See `ActiveFilteredLogger` vs `EarlyFilteredLogger`).
- - *Transformers*: Transformers modify the content of log messages, before passing them on. This includes the metadata like severity level. Unlike Filters they can't block a log message, but they could drop its level down to say `Debug` so that normally noone would see it.
- - *Demux*: There is only one possible Demux Logger. and it is central to log routing. It acts as a hub that receives 1 log message, and then sends copies of it to all its child loggers. Like in the diagram above, it can be composed with Filters to control what goes where.
-
-This is a basically full taxonomy of all compositional loggers.
-This package implements the full set. So you shouldn't need to build your own routing components, just configure the ones included in this package.
-
-It is worth understanding the idea of logging purity.
-The loggers defined in this package are all pure.
-The Filters, only filter, the Sinks only sink, the transformers only Transform.
-
-We can contrast this to the the `ConsoleLogger` (the standard logger in the REPL).
-The `ConsoleLogger` is an impure sink.
-As well as displaying logs to the user (as a Sink);
-it uses the log content, in the form of the `max_log` kwarg to decide if a log should be displayed (Active Filtering);
-and it has a min_enabled_level setting, that controls if it will accept a message at all
-(Early Filtering, in particular see `MinLevelLogger`).
-If it was to be defined in a compositional way,
-we would write something along the lines of:
+ - *Sinks*: Sinks are the endpoint of a log message journey. They write it to file or display it on the console or set off a red flashing light in the laboratory. A Sink should never decide what to accept, only what to do with it.
+ - *Filters*: Filters wrap around other loggers and decide whether or not to pass on a message. When that decision occurs, they can be further broken down (See `ActiveFilteredLogger` vs `EarlyFilteredLogger`).
+ - *Transformers*: Transformers modify the content of log messages before passing them on, including metadata, such as severity level. Unlike Filters, they can't block a log message, but they could drop its level down to say Debug so that usually no one would see it.
+ - *Demux*: There is only one possible Demux Logger, and it is central to log routing. It acts as a hub that receives one log message and then sends copies to all its child loggers. Like in the diagram above, it can be composed with Filters to control what goes where.
+
+This is a complete taxonomy of all compositional loggers, with this package implementing the entire set. As such, there should be no need to build routing components when configuring the ones included in this package.    
+
+It is worth understanding the idea of logging purity. The loggers defined in this package are all pure. The Filters only filter, the Sinks only sink, and the transformers only Transform.
+
+We can contrast this to the `ConsoleLogger` (the standard logger in the REPL). The `ConsoleLogger` is an impure sink. As well as displaying logs to the user (as a Sink); it uses the log content, in the form of the `max_log` to decide if a log should be displayed (Active Filtering); and it has a min_enabled_level setting, that controls if it will accept a message at all (Early Filtering, in particular see `MinLevelLogger`).
+If defined in a compositional way, we would write something along the lines of:
 ```julia
 ConsoleLogger(stream, min_level) =
     MinLevelLogger(