equal
deleted
inserted
replaced
15 that <em>one program should do one thing and do it well</em>. |
15 that <em>one program should do one thing and do it well</em>. |
16 </p> |
16 </p> |
17 |
17 |
18 <p> |
18 <p> |
19 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). |
19 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). |
20 We can connect programs and pass the STDOUT of first one to the STDIN of the second one (etc.) using pipes. |
20 We can connect programs and pass the STDOUT of the first one to the STDIN of the second one (etc.) using pipes. |
21 </p> |
21 </p> |
22 |
22 |
23 <p> |
23 <p> |
24 A classic pipeline example (<m:a href="classic-example">explained</m:a>): |
24 A classic pipeline example (<m:a href="classic-example">explained</m:a>): |
25 </p> |
25 </p> |
83 --> |
83 --> |
84 |
84 |
85 |
85 |
86 <p> |
86 <p> |
87 But the question is: how the data passed through pipes should be formatted and structured. |
87 But the question is: how the data passed through pipes should be formatted and structured. |
88 There is wide spectrum of options from simple unstructured text files (just arrays of lines) |
88 There is a wide spectrum of options from simple unstructured text files (just arrays of lines) |
89 through various <abbr title="delimiter-separated values e.g. CSV separated by comas">DSV</abbr> |
89 through various <abbr title="delimiter-separated values e.g. CSV separated by comas">DSV</abbr> |
90 to formats like XML (YAML, JSON, ASN.1, Diameter, S-expressions etc.). |
90 to formats like XML (YAML, JSON, ASN.1, Diameter, S-expressions etc.). |
91 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>). |
91 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>). |
92 On the other hand, the advanced formats are capable to represent arbitrary object tree structures or even arbitrary graphs. |
92 On the other hand, the advanced formats are capable to represent arbitrary object tree structures or even arbitrary graphs. |
93 They offer unlimited possibilities – and this is their strength and weaknes at the same time. |
93 They offer unlimited possibilities – and this is their strength and weakness at the same time. |
94 </p> |
94 </p> |
95 |
95 |
96 <!-- |
96 <!-- |
97 <blockquote>Everything should be made as simple as possible, but not simpler.</blockquote> |
97 <blockquote>Everything should be made as simple as possible, but not simpler.</blockquote> |
98 --> |
98 --> |
114 and through decades it has proven its qualities and viability. |
114 and through decades it has proven its qualities and viability. |
115 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. |
115 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. |
116 </p> |
116 </p> |
117 |
117 |
118 <p> |
118 <p> |
119 Thus the <m:name/> are streams containing zero or more relations. |
119 Thus, the <m:name/> are streams containing zero or more relations. |
120 Each relation has a name, one or more attributes and zero or more records (tuples). |
120 Each relation has a name, one or more attributes and zero or more records (tuples). |
121 Each attribute has a name and a data-type. |
121 Each attribute has a name and a data-type. |
122 Records contain attribute values. |
122 Records contain attribute values. |
123 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). |
123 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). |
124 </p> |
124 </p> |
127 |
127 |
128 <p> |
128 <p> |
129 <m:name/> are an open <em>data format</em> designed for streaming structured data between two processes. |
129 <m:name/> are an open <em>data format</em> designed for streaming structured data between two processes. |
130 Simultaneously with the format specification, we are also developing a <em>reference implementation</em> (libraries and tools) as a free software. |
130 Simultaneously with the format specification, we are also developing a <em>reference implementation</em> (libraries and tools) as a free software. |
131 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. |
131 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. |
132 So befeore publishing any new specification or its version, we will verify it by creating a reference implementation at least in one programming language. |
132 So before publishing any new specification or its version, we will verify it by creating a reference implementation at least in one programming language. |
133 </p> |
133 </p> |
134 <p> |
134 <p> |
135 More generally, <m:name/> are a philosophical continuation of the classic <m:unix/> pipelines and the relational model. |
135 More generally, <m:name/> are a philosophical continuation of the classic <m:unix/> pipelines and the relational model. |
136 </p> |
136 </p> |
137 |
137 |