relpipe-data/faq.xml
author František Kučera <franta-hg@frantovo.cz>
Fri, 30 Nov 2018 17:13:21 +0100
branchv_0
changeset 160 b731df137efb
parent 152 f876683324c2
child 163 580c0e195817
permissions -rw-r--r--
specification: relpipe-out-gui

<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/>
			...
		</p>
		
		<p>
			<strong>Why 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>
		
		<!--
		<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>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.
			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>