.

raw_docs/explanation/yourData.md

@@ -5,10 +5,8 @@ My experience has been, that I don't usually know the structure of the data, tha
 Instead, the aim is plot it - stat. Then evolve.
 
 ```scala mdoc:js
-import upickle.default.writeJs
 import viz.extensions.*
 import viz.PlotTargets.doNothing
-import com.github.tarao.record4s.upickle.Record.readWriter
 import com.github.tarao.record4s.%
 
 // We don't know this in advance, but we have a Seq of it, and we want a bar chart.

raw_docs/working_chart/intro.md

@@ -1,25 +1,10 @@
 # Styles
 
-There are essentially three strategies for working with a chart
-
-1. [Mutable](mutable.md)
-2. [The DSL](typesafe.md)
-3. a [mix](mixed.md) of the two...
-
-The typesafe DSL is generated out of the vega [JSON schema](https://github.com/vega/schema).
-
-I do not believe it to be 100% correct. About 95% correct.
-
-For this reason, the "mutable" option is the ultimate fallback. Typesafe is pretty nice to have, though.
+The library has evolved, currently, I believe the most productive engagement to be using the excellent [records4s](https://tarao.orezdnu.org/record4s/) as easy way to express sub-parts of vega specs.
 
 ## Design Note
 
-All charts are, in the end ... just a case class. For a given case class, the plot will _always_ be the same. Onen could argue that it is "functional" at that boundary.
-
-Finally, because we're just producing a chart;
-
-1. Your plot can be produced via a method defined directly on some data class itself
-1. You don't have to own the data structure - have a look at the extension methods. The homepage works through an extension method defined on ```Numeric[Iterable]```
+All charts are, in the end ... just a case class. For a given case class, the plot will _always_ be the same. Onen could argue that it is "functional" at that boundary. This therefore opens the potential for abstraction over charts, and in particular for unit testing strategies which have a high degree of confidence.
 
 ## Visualisation as JSON