--- a/relpipe-data/index.xml Sat Nov 21 20:36:38 2020 +0100
+++ b/relpipe-data/index.xml Wed Dec 30 10:29:29 2020 +0100
@@ -17,7 +17,7 @@
<p>
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.
+ We can connect programs and pass the STDOUT of the first one to the STDIN of the second one (etc.) using pipes.
</p>
<p>
@@ -85,12 +85,12 @@
<p>
But 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)
+ There is a 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.
+ They offer unlimited possibilities – and this is their strength and weakness at the same time.
</p>
<!--
@@ -116,7 +116,7 @@
</p>
<p>
- Thus the <m:name/> are streams containing zero or more relations.
+ 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.
@@ -129,7 +129,7 @@
<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.
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 before 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.