# HG changeset patch
# User František Kučera <franta-hg@frantovo.cz>
# Date 1595792238 -7200
# Node ID f600b6f8a88ca5eb092696f8423ec2b08ddbd77a
# Parent  9045be58e15945afc7622dd833dc86d61922ee23
non-breaking spaces

diff -r 9045be58e159 -r f600b6f8a88c relpipe-data/index.xml
--- a/relpipe-data/index.xml	Sun Jul 26 19:45:53 2020 +0200
+++ b/relpipe-data/index.xml	Sun Jul 26 21:37:18 2020 +0200
@@ -21,7 +21,7 @@
 		</p>
 		
 		<p>
-			A classic pipeline example (<m:a href="classic-example">explained</m:a>):
+			A classic pipeline example (<m:a href="classic-example">explained</m:a>):
 		</p>
 		
 		<m:classic-example/>
@@ -45,8 +45,8 @@
 			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.
-			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>
+			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.<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>
@@ -99,7 +99,7 @@
 		
 		<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.
+			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>
@@ -117,40 +117,40 @@
 		
 		<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.
+			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).
+			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>
 		
 		<p>
 			<m:name/> are an open <em>data format</em> designed for streaming structured data between two processes. 
-			Simultaneously with the format specification, we are also developing a <em>reference implementation</em> (libraries and tools) as a free software.
+			Simultaneously with the format specification, we are also developing a <em>reference implementation</em> (libraries and tools) as a free software.
 			Although we believe in the specification-first (or contract-first) approach, we always look and check, whether the theoretic concepts are feasible and whether they can be reasonably and reliably implemented.
-			So befeore publishing any new specification or its version, we will verify it by creating a reference implementation at least in one programming language.
+			So befeore publishing any new specification or its version, we will verify it by creating a reference implementation at least in one programming language.
 		</p>
 		<p>
-			More generally, <m:name/> are a philosophical continuation of the classic <m:unix/> pipelines and the relational model.
+			More generally, <m:name/> are a philosophical continuation of the classic <m:unix/> pipelines and the relational model.
 		</p>
 		
 		
 		<h2>What <m:name/> are not?</h2>
 			
 		<p>
-			<m:name/> respect the existing ecosystem and are rather an improvement or supplement than a replacement.
-			So the <m:name/> are not a:
+			<m:name/> respect the existing ecosystem and are rather an improvement or supplement than a replacement.
+			So the <m:name/> are not a:
 		</p>
 		
 		<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>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 the terminal, we use standard means like Unicode, ANSI escape sequences etc.</li>
 			<li>IDE – we can use standard <m:unix/> tools as an IDE (GNU Screen, Emacs, 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, Guile/Scheme, AWK or regular expressions.</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, Guile/Scheme, AWK 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 redirect 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>
 		
 		
@@ -186,7 +186,7 @@
 		<m:img src="img/relational-pipes-big-picture-1.png"/>
 		
 		<p>
-			Data can flow through a sequence of several transformations or directly from the input filter to the output filter.
+			Data can flow through a sequence of several transformations or directly from the input filter to the output filter.
 		</p>