--- a/relpipe-data/classic-example.xml Mon Nov 26 12:15:40 2018 +0100
+++ b/relpipe-data/classic-example.xml Mon Nov 26 18:56:21 2018 +0100
@@ -42,8 +42,8 @@
WHITE]]></pre>
<p>
- So we have a list of colors of our dogs printed in upper-case.
- In case we have several dogs of same color, we could avoid duplicates simply by adding <code>| sort -u</code> in the pipeline (after the <code>cut</code> part).
+ So we have a list of colors of our dogs printed in big letters.
+ In case we have several dogs of same color, we could avoid duplicates simply by adding <code>| sort -u</code> in the pipeline (after the <code>cut</code> step).
</p>
<h2>The great parts</h2>
--- a/relpipe-data/index.xml Mon Nov 26 12:15:40 2018 +0100
+++ b/relpipe-data/index.xml Mon Nov 26 18:56:21 2018 +0100
@@ -9,9 +9,8 @@
<text xmlns="http://www.w3.org/1999/xhtml">
<p>
One of the great parts of the <m:unix/>
- <m:podČarou>
- <m:unix tvar="vysvětlivka"/>
- </m:podČarou> culture is the invention<m:podČarou>which is attributed to Doug McIlroy, see <a href="http://www.catb.org/~esr/writings/taoup/html/ch07s02.html#plumbing">The Art of Unix Programming: Pipes, Redirection, and Filters</a></m:podČarou>
+ <m:podČarou><m:unix tvar="vysvětlivka"/></m:podČarou>
+ culture is the invention<m:podČarou>which is attributed to Doug McIlroy, see <a href="http://www.catb.org/~esr/writings/taoup/html/ch07s02.html#plumbing">The Art of Unix Programming: Pipes, Redirection, and Filters</a></m:podČarou>
of <em>pipes</em> and the idea<m:podČarou>see <a href="http://www.catb.org/~esr/writings/taoup/html/ch01s06.html">The Art of Unix Programming: Basics of the Unix Philosophy</a></m:podČarou>
that <em>one program should do one thing and do it well</em>.
</p>
@@ -47,7 +46,7 @@
Such single-purpose programs (often called <em>filters</em>) are much easier to create, test and optimize and their authors don't have to bother about the complexity of the final pipeline.
They even don't have to know, how their programs will be used in the future by others.
This is a great design principle that brings us advanced flexibility, reusability, efficiency and reliability.
- Being in any role (author of a filter, builder of a pipeline etc.), we can always focus on our task only and do it well.
+ Being in any role (author of a filter, builder of a pipeline etc.), we can always focus on our task only and do it well.<m:podČarou>see <a href="http://wiki.apidesign.org/wiki/Cluelessness">cluelessness</a> by Jaroslav Tulach in his <em>Practical API Design. Confessions of a Java Framework Architect</em></m:podČarou>
And we can collaborate with others even if we don't know about them and we don't know that we are collaborating.
Now think about putting this together with the free software ideas... How very!
</p>
@@ -84,17 +83,45 @@
-->
- <p>Bytes, text, structured data? XML, YAML, JSON, ASN.1</p>
+ <p>
+ Now the question is: how the data passed through pipes should be formatted and structured.
+ There is wide spectrum of options from simple unstructured text files (just arrays of lines)
+ through various <abbr title="delimiter-separated values e.g. CSV separated by comas">DSV</abbr>
+ to formats like XML (YAML, JSON, ASN.1, Diameter, S-expressions etc.).
+ Simpler formats look temptingly but have many problems and limitations (see the Pitfalls section in the <m:a href="classic-example">Classic pipeline example</m:a>).
+ On the other hand, the advanced formats are capable to represent arbitrary object tree structures or even arbitrary graphs.
+ They offer unlimited possibilities – and this is their strength and weaknes at the same time.
+ </p>
- <p>Rules:</p>
+ <!--
+ <blockquote>Everything should be made as simple as possible, but not simpler.</blockquote>
+ -->
- <ul>
- <li>a stream contains zero or more relations</li>
- <li>a relation has a name</li>
- <li>a relation has one or more attributes</li>
- <li>a relation contains zero or more records</li>
- </ul>
+ <p>
+ It is not about the shape of the brackets, apostrophes, quotes or text vs. binary.
+ It is not a technical question – it is in the semantic layer and human brain.
+ Generic formats and their <em>arbitrary object trees/graphs</em> are (for humans, not for computers) difficult to understand and work with
+ – compared to simpler structures like arrays, maps or matrixes.
+ </p>
+ <p>
+ This is the reason why we have chosen the relational model as our logical model.
+ This model comes from 1969<m:podČarou>invented and described by Edgar F. Codd,
+ see <em>Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks, Research Report, IBM</em> from 1969
+ and <em>A Relational Model of Data for Large Shared Data Banks</em> from 1970,
+ see also <a href="https://en.wikipedia.org/wiki/Relational_model">Relational model</a>
+ </m:podČarou>
+ and through decades it has proven its qualities and viability.
+ This logical model is powerful enough to describe almost any data and – at the same time – it is still simple and easy to be understood by humans.
+ </p>
+
+ <p>
+ Thus the <m:name/> are streams containing zero or more relations.
+ Each relation has a name, one or more attributes and zero or more records (tuples).
+ Each attribute has a name and a data-type.
+ Records contain attribute values.
+ We can imagine this stream as a sequence of tables (but the table is only one of many possible visual representations of such relational data).
+ </p>
<h2>What <m:name/> are?</h2>
--- a/relpipe-data/makra/unix.xsl Mon Nov 26 12:15:40 2018 +0100
+++ b/relpipe-data/makra/unix.xsl Mon Nov 26 18:56:21 2018 +0100
@@ -13,7 +13,7 @@
<xsl:template match="m:unix[@tvar = 'oboje']">*NIX (formerly UNIX, now mostly GNU/Linux)</xsl:template>
<xsl:template match="m:unix[@tvar = 'zkratka']"><abbr title="formerly UNIX, now mostly GNU/Linux">*NIX</abbr></xsl:template>
- <xsl:template match="m:unix[@tvar = 'vysvětlivka']">formerly UNIX, now mostly GNU/Linux</xsl:template>
+ <xsl:template match="m:unix[@tvar = 'vysvětlivka']">formerly UNIX, now mostly <a href="https://www.gnu.org/">GNU/Linux</a></xsl:template>
<xsl:template match="m:unix">*NIX</xsl:template>
</xsl:stylesheet>