<stránka

	xmlns="https://trac.frantovo.cz/xml-web-generator/wiki/xmlns/strana"

	xmlns:m="https://trac.frantovo.cz/xml-web-generator/wiki/xmlns/makro">

	<nadpis>FAQ</nadpis>

	<perex>Frequently asked questions</perex>

	<pořadí>16</pořadí>

	<text xmlns="http://www.w3.org/1999/xhtml">

		<p>

			<strong>When the stable version will be released?</strong>		

			<br/>

			We don't know – there is no exact date.

			<m:name/> are something that should be released about twenty years ago. But real work started in 2018.

			So it is not a big difference whether it will be released this month or the next one.

			We understand the <em>release early, release often</em> rule.

			But it fits better to application software than to standards and APIs.

			Of course, we expect some evolution after the v1.0.0 release, but we need to stabilize and verify many things before the release in order to be able to maintain backward compatibility in future.

		</p>

		<p>

			<strong>How can I help you?</strong>		

			<br/>

			<ul>

				<li>Suggest more examples how <m:name/> can be used; especially how YOU would like to use it.</li>

				<li>We are looking for illustrations that would supplement our documentation and website.</li>

				<li>

					As an author of a program that generates or consumes some data, you could add relational input and output to your program. 

					But please mention that we do not have v1.0 yet, so these features should be marked as experimental. 

					The API might/will change. 

					Other (and maybe better for now) option is to add input/output of values separated by null byte (<code>\0</code>).

					This "API" will be supported for sure and data are simply the attribute values. There are no record separators (we know the number of attributes, so they are not needed).

					Disadvantage of this approach is that the stream can contain only a single relation; and that the metadata are not embedded in the stream and must be passed separately.

				</li>

				<li>Review our source code and suggest improvements and fixes. Constructive criticism is always welcome. This is one of reasons why we publish our programs as free software.</li>

				<li>Native speakers could suggest improvements and corrections of our English texts.</li>

			</ul>

		</p>

		<p>

			<strong>Why do you speak about <em>relations</em> instead of <em>tables</em>?</strong>

			<br/>

			It might be uncommon terminology for someone, but <em>relations</em> and <em>attributes</em> symbolizes

			that we focus on substance of the data. Pure data are conveyed through the pipelines 

			and the presentation of such data is only the last step.

			The data might be presented/visualized in many various forms.

			And tables (consisting of rows and columns) are only one of many possible options.

		</p>

		<m:tabulka>

			Relational	SQL	alternative terms

			relation	table

			attribute	column	field

			record	row	tuple

		</m:tabulka>

		<!--

		<p>

			<strong>?</strong>		

			<br/>

			...

		</p>

		<p>

			<strong>Why don't build on XML? It is a standard since 1998 and there are many tools and libraries for it.</strong>		

			<br/>

			XML is a great and mature (meta)format and its ecosystem is respectable and inspiring.

			But the XML does not conform to our <m:a href="principles">principles</m:a>, especially the ability to concatenate multiple files/streams and to append new records to an already existing relation.

			XML is also not concise. 

			And the implementation of the XML parser in various environments would be <em>a bit more complex</em>.

		</p>

		<p>

			We prefer XML as an input and output format and look forward to cooperation with XML ecosystem (XSD, XPath, XSLT, XQuery etc.).

			Such steps might be at the beginning, at the end, or even in the middle of the relational pipeline.

		</p>

		<p>

			<strong>?</strong>		

			<br/>

			...

		</p>

		-->

		<p>

			<strong>Why C++?</strong>		

			<br/>

			Firstly, <m:name/> are a specification of a data format and as such are not bound to any programming language.

			This specification is totally language- and platform- independent.

		</p>

		<p>

			The ideal/perfect language does not exist and our implementations will be written in various languages.

			We started our prototype and first real implementations in C++ from several reasons:

		</p>

		<ul>

			<li>It is mature and widespread: GCC runs almost everywhere and other compilers/toolchains are also available.</li>

			<li>Programs written in C++ starts immediately: very important for CLI tools.</li>

			<li>Can be seamlessly mixed with C and its libraries. Is good for interaction with the operating system.</li>

			<li>Modern C++ is a quite good language.</li>

			<li>We are not C++ gurus and C++ is not our first-choice language i.e. the fact that we are able to do implementation in C++ proves that the specification is simple enough to be reasonably implemented by an average software engineer in any other language :-)</li>

		</ul>

		<p>Implementation in other languages will follow. Java is the next one. Then probably Perl, Python, Rust, Go, PHP etc. (depends on community involvement).</p>

		<p>			

			<strong>Have you seen <a href="https://xkcd.com/927/">XKCD 927</a>?</strong>		

			<br/>

			Yes. And we liked it so much that we followed their instructions and created <m:name/>.

		</p>

		<p>

			<strong>Are <m:name/> compatible with cloud, IoT, SPA/PWA, AI, blockchain and mobile-first? Should our DevOps use it in our serverless hipster fintech app with strong focus on SEO, UX and machine learning?</strong>

			<br/>

			Go @#$%&amp; yourself. We are pretty old school hackers and we enjoy our green screen terminals!<br/>

			Of course, you can use <m:name/> anywhere if it makes sense for you.

			<m:name/> are designed to be generic enough – i.e. not specific to any industry (banking, telecommunications, embedded etc.) nor platform.

			Data in this format are very concise, so can be used even in very small devices.

			Its native data structure is a relation (table) but it can also handle tree-structured data (i.e. any data).

			It is designed rather for streaming than for storage (but under some circumstances it is also meaningful to use it for storage).

		</p>

	</text>

</stránka>