--- 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.
--- a/relpipe-data/principles.xml Sat Nov 21 20:36:38 2020 +0100
+++ b/relpipe-data/principles.xml Wed Dec 30 10:29:29 2020 +0100
@@ -11,13 +11,13 @@
<h2>Sane software</h2>
<p>
<m:name/> (both the specification and the reference implementation) should be developed according to the <a href="https://sane-software.globalcode.info/">Sane software manifesto</a> (draft).
- Many of principles mentioned below are part of <em>being sane</em>.
+ Many of the principles mentioned below are part of <em>being sane</em>.
</p>
<h2>Free software and open specification</h2>
<p>
- <m:name/> is and always will be a <a href="https://www.gnu.org/philosophy/free-sw.html">free software</a> and the specification of the format, tools and libraries will be open.
+ <m:name/> are and always will be a <a href="https://www.gnu.org/philosophy/free-sw.html">free software</a> and the specification of the format, tools and libraries will be open.
It must not be impaired by software patents or other similar restrictions.
In our country, we do not accept the existence of patents at all.
</p>
@@ -65,7 +65,7 @@
</p>
<p>
- However, in any case, we should provide also an option of producing <em>raw</em> data in the <m:name/> format and allow others to convert it to any other format according their needs.
+ However, in any case, we should provide also an option of producing <em>raw</em> data in the <m:name/> format and allow others to convert it to any other format according to their needs.
</p>
<h2>Specification-first, contract-first</h2>