diff -r 297da74fcab2 -r ee7e96151673 relpipe-data/index.xml
--- a/relpipe-data/index.xml	Sun Nov 25 01:03:26 2018 +0100
+++ b/relpipe-data/index.xml	Sun Nov 25 19:58:06 2018 +0100
@@ -20,10 +20,14 @@
 			Each running program (process) has one input stream (called standard input or STDIN) and one output stream (called standard output or STDOUT) and also one additional output stream for logging/errors/warnings (STDERR).
 			We can connect programs and pass the STDOUT of first one to the STDIN of the second one (etc.) using pipes.
 		</p>
+		
+		<p>
+			A classic pipeline example (<m:a href="classic-example">explained</m:a>):
+		</p>
+		
+		<m:classic-example/>
 
 		<!--		
-		<pre>cat /etc/fstab | dd 2>/tmp/dd.log | grep tmpfs</pre>
-		<p></p>
 		<m:diagram orientace="vodorovně">
 			node[shape=box];
 			
@@ -42,7 +46,7 @@
 			According to this principle we can build complex and powerful programs (pipelines) by composing several simple, single-purpose and reusable programs.
 			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. Simply: awesome.
+			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.
 			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!
@@ -79,6 +83,19 @@
 		</m:diagram>
 		-->
 		
+		
+		<p>Bytes, text, structured data? XML, YAML, JSON, ASN.1</p>
+		
+		<p>Rules:</p>
+		
+		<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>
+		
+		
 		<h2>What <m:name/> are?</h2>
 		
 		<p>
@@ -101,12 +118,12 @@
 		
 		<ul>
 			<li>Shell – we use existing shells (e.g. GNU Bash), work with any shell and even without a shell (e.g. as a stream format passed through a network or stored in a file).</li>
-			<li>Terminal emulator – same as with shells, we use existing terminals and we can use <m:name/> also outside any terminal; if we interact with any terminal, we use standard means as Unicode, ANSI escape sequences etc.</li>
-			<li>IDE – we use standard <m:unix/> tools as an IDE (GNU Screen, Make etc.) or any other IDE.</li>
+			<li>Terminal emulator – same as with shells, we use existing terminals and we can use <m:name/> also outside any terminal; if we interact with the terminal, we use standard means as Unicode, ANSI escape sequences etc.</li>
+			<li>IDE – we can use standard <m:unix/> tools as an IDE (GNU Screen, Make etc.) or any other IDE.</li>
 			<li>Programming language – <m:name/> are language-independent data format and can be produced or consumed in any programming language.</li>
 			<li>Query language – although some of our tools are doing queries, filtering or transformations, we are not inventing a new query language – instead, we use existing languages like SQL, XPath or regular expressions.</li>
 			<!--<li>Text editor – </li>-->
-			<li>Database system, DBMS – we focus on the stream processing rather than data storage. Although sometimes it makes sense to pipe data to a file and continue with the processing later.</li>
+			<li>Database system, DBMS – we focus on the stream processing rather than data storage. Although sometimes it makes sense to redirect data to a file and continue with the processing later.</li>
 		</ul>