--- /dev/null
+<!DOCTYPE html>
+<html lang="en">
+ <head>
+ <title>FLL - Design and Principles</title>
+
+ <base href="../">
+
+ <meta charset="UTF-8">
+ <meta name="author" content="Kevin Day">
+ <meta name="description" content="Featurless Linux Library Design and Principles">
+ <meta name="keywords" content="Kevin Day, Kevux, FLL, Featureless, Linux, Library, Distribution, Open-Source, design, principle">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+ <link type="text/css" rel="stylesheet" media="all" href="css/kevux.css">
+ <link type="text/css" rel="stylesheet" media="only screen" href="css/kevux-screen.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:501px)" href="css/kevux-screen-desktop.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (max-device-width:500px)" href="css/kevux-screen-mobile.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:1201px)" href="css/kevux-screen-large.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:501px) and (max-device-width:1200px)" href="css/kevux-screen-normal.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (min-device-width:251px) and (max-device-width:500px)" href="css/kevux-screen-small.css">
+ <link type="text/css" rel="stylesheet" media="only screen and (max-device-width:250px)" href="css/kevux-screen-tiny.css">
+ <link type="text/css" rel="stylesheet" media="only print" href="css/kevux-print.css">
+ <link type="text/css" rel="stylesheet" media="only print and (orientation:landscape)" href="css/kevux-print-landscape.css">
+ <link type="text/css" rel="stylesheet" media="only print and (orientation:portrait)" href="css/kevux-print-portrait.css">
+
+ <link rel="canonical" href="fll/design.html">
+ <link type="image/x-icon" rel="icon" href="images/kevux.ico">
+ <link type="image/x-icon" rel="shortcut" href="images/kevux.ico">
+ <link type="text/html" rel="license" href="licenses.html">
+ </head>
+
+ <body id="kevux" class="kevux no-js fll specifications">
+ <div role="banner" class="header-block">
+ <header class="header-section header">
+ <div class="header-site">Kevux Systems and Software</div>
+ </header>
+
+ <div class="nav-block">
+ <nav id="kevux-site-nav" class="nav-menu">
+ <div class="nav-item"><a href="news.html" class="nav-text link">News</a></div>
+ <div class="nav-item"><a href="distributions.html" class="nav-text link">Distributions</a></div>
+ <div class="nav-item active"><a href="fll.html" class="nav-text link">FLL</a></div>
+ <div class="nav-item"><a href="projects.html" class="nav-text link">Projects</a></div>
+ <div class="nav-item"><a href="documentation.html" class="nav-text link">Documentation</a></div>
+ </nav>
+ </div>
+ </div>
+
+ <div class="content-block">
+ <div id="nav-expanded" class="nav-block">
+ <nav id="kevux-document-nav" class="nav-menu">
+ <div class="nav-item block back">
+ <a href="fll.html" class="nav-text link back">Back</a>
+ </div>
+ <div class="nav-item block unlink">
+ <div class="nav-text notice">Featureless Linux Library</div>
+ </div>
+ <div class="nav-item block">
+ <a href="fll/design.html#principles" class="nav-text link">Design and Principles</a>
+ </div>
+ <div class="nav-item block">
+ <a href="fll/design.html#core_perspectives" class="nav-text link">Core Perspectives</a>
+ </div>
+ <div class="nav-item block">
+ <a href="fll/design.html#core_design" class="nav-text link">Core Design</a>
+ </div>
+ <div class="nav-item block">
+ <a href="fll/design.html#art_of_communication" class="nav-text link">Art of Communication</a>
+ </div>
+ <div class="nav-item block ellipses">
+ <a href="fll/design.html#nav-expanded" class="nav-text link open" title="Expand Menu">…</a>
+ <a href="fll/design.html" class="nav-text link close">Collapse Menu</a>
+ </div>
+ </nav>
+ </div>
+
+ <div role="document" class="main-block">
+ <main class="main">
+ <header class="section-header header">
+ <h1 class="section-title h h1">Featureless Linux Library</h1>
+ </header>
+
+ <section id="principles" class="section">
+ <header class="section-header header">
+ <h2 class="section-title h h2">Design and Principles</h2>
+ </header>
+
+ <div class="section-content">
+ <p class="p">
+ The Featureless Linux Library has a specific design with a specific set of principles. This design and these principles direct and govern how, what, and in what way the projects are built, styled, released, maintained, documented, and evolved.
+ </p>
+ <p class="p">
+ The <abbr title="Featureless Linux Library">FLL</abbr> project is a collection of different sub-projects, standards, specifications, and programs. Each of these has its own set of rules, guidelines, and principles. All of these are primarily drive by open-source design and principles but the specific way in which this happens is dependent on the specific type of material or data as well as the intended purpose or target audience.
+ </p>
+ </div>
+ </section>
+
+ <section id="core_perspectives" class="section">
+ <header class="section-header header separate">
+ <h2 class="section-title h h2">Core Perspectives</h2>
+ </header>
+
+ <div class="section-content">
+ <p class="p">
+ To better understand the core principles and even philosophy behind this <abbr title="Featureless Linux Library">FLL</abbr> project one must first understand some key terminology from the perspective of what the terms do or are for rather than what the direct meaning of the words are.
+ </p>
+ <p class="p">
+ The term <em>software</em> is understood as thought. That is to say, if you have an idea in your mind then treat this idea as software. This perspective introduces a problem, a problem of ambiguity. <em>Software</em> is more than an idea when it is on a computer. The general definition of <em>software</em> can refer to source code, binaries, or data (data encompasses both source code and binaries but for the purposes here please ignore this fact). A <em>binary</em> is usually created from <em>source code</em>.
+ </p>
+ <p class="p">
+ The perspective on <em>source code</em> should be described first to address the problem. <em>Source Code</em> is an idea communicated through some <em>language</em>. A single idea may be expressed differently between two distinct languages and still be the same idea. However, the representation of that idea may be limited or otherwise influenced by the constraints or limitation of a language.
+ </p>
+ <p class="p">
+ When the <em>source code</em> is compiled, interpreted, or otherwise converted into machine code, the idea behind the <em>source code</em> is now represented in a new language, the machine language. This resulting representation in the machine language is the <em>binary</em>.
+ </p>
+ <p class="p">
+ At this point the <em>software</em>, be it the <em>source code</em> or the <em>binary</em> is synonymous with spoken words. There is no product, only just a spoken and recored idea constrained by the language it is spoken in.
+ </p>
+ <p class="p">
+ The magic happens when the machine computes. This computation of the communicated idea requires <em>hardware</em>. It is this <em>hardware</em> that manifests the idea into reality. A product, therefore, may only exist in conjunction with some <em>hardware</em>.
+ </p>
+ <p class="p">
+ The world as it currently exists is a world of restrictions and patents. Supposedly an idea is not patentable. Supposedly math cannot be patented. Yet with <em>software</em> effectively being a written or spoken idea, often represented in mathematical equations, is treated as patentable.
+ </p>
+ <p class="p">
+ Associating, or otherwise linking, an idea is somehow treated as if the originator of the first spoken idea spoke the second idea. Take a conversation, for example. If the first person says "<em>I like cake.</em>" and the second person says "<em>I like candles on cake.</em>" then does that mean the first person is the one who originated the statement "<em>I like candles on cake.</em>"? Of course not. But the legal system in the United States of America, and perhaps the world, have decided otherwise. That is to say, linking one binary to another (somehow) creates a combined product. This appears to be some sort of magical fairy dust lawyers use to convince people that what you are smelling is actually a rose rather than something bovine herders have to shovel up from time to time.
+ </p>
+ <p class="p">
+ The core principle of this project is to use legal means to make such an absurdity illegal. Thus the copyrights, such as the <abbr title="GNU Lesser General Public License version 2.1 or greater">LGPLv2.1+</abbr> license, are utilized. The goal here is not to deny a person the ability to make a product and sell it. Instead, the goal here is so that a person who makes a product can actually make and sell it. Just because a bird house has nails in it doesn't mean the originator of the nails now owns all rights to the bird house. Just because an <abbr title="Advanced Micro Devices">AMD</abbr> motherboard has an Nvidia graphics card connected to it does not mean <abbr title="Advanced Micro Devices">AMD</abbr> now owns all rights to the Nvidia graphics card.
+ </p>
+ <p class="p">
+ The <abbr title="Featureless Linux Library">FLL</abbr> is a set of nails, screws, gears, and clockwork all designed and intended to be taken apart and used in whatever way another person deems necessary. For convenience, this library includes fully functionaly programs as an example on how to use the project. They too can be taken apart.
+ </p>
+ </div>
+ </section>
+
+ <section id="core_design" class="section">
+ <header class="section-header header separate">
+ <h2 class="section-title h h2">Core Design</h2>
+ </header>
+
+ <div class="section-content">
+ <p class="p">
+ The <abbr title="Featureless Linux Library">FLL</abbr> project, sub-projects, and related projects are all being built in stages. These stages are not temporal based but are instead goal based. There are temporal constraints to keep development within reason and to provide cut-off points. Each of these goal posts are separated by development and stable releases. A stable release may also be referred to as a production release.
+ </p>
+ <p class="p">
+ Long term stability is a flag ship goal of this project. To that extent, stable releases are to be maintained indefinitely. Ideally, this will hold true only for 1.0 releases and beyond but in practice pre-1.0 may also seek this goal. For long term stability, <abbr title="Application Programming Interface">API</abbr> breakage is not allowed with a stable release. For those people out there who blindly apply infinites to everything, stop it. If there is some major security issue or other such extreme problem then <abbr title="Application Programming Interface">API</abbr> breakage can be considered. This will, however, be strongly resisted to ensure only necessary breakage occurs. Strong resistence is not the same as never allowing.
+ </p>
+ <p class="p">
+ The term "<em>featureless</em>" is loosely used in this project to describe the idea that a project should not constantly add features like a kid in a candy shop wanting to try every new piece of candy they find. The entire <abbr title="Featureless Linux Library">FLL</abbr> project is designed so that you can do as you will so long as you do not deny another person the same. This means that you are free to add as many features as you like. In your own project. Or in your own hacked variation. This project shall attempt to maintain a discrete set of functionality specific to each stable release and the goals of that release.
+ </p>
+ <p class="p">
+ Temporal constraints may result in a stable release being made without all of the intended features. These such cases should be treated on a per-situation basis. Changes to a stable release to add features that did not make it is still discouraged and should be avoided. Futhermore, there is an undescribed point in time in which if a stable release has not achieve a planned or intended feature then that feature should never be added. Time matters. For example, if version 1.0 was supposed to bake a cake and failed to get that functionality but then 10-years later (when 3d-printing evolved into 3d-baking) the version 1.0 must not have the "bake a cake" feature added. Too much time has passed. Just make a 1.2 release for baking cakes. The rule of thumb is flexibility for short term and rigidity for long term.
+ </p>
+ <p class="p">
+ The <abbr title="Featureless Linux Library">FLL</abbr> project has the word "<em>library</em>" in the name. For good reason. The primary purpose of this project is to be used as a library. The original flag ship of this project is the <strong>Featureless Make</strong> program. Notice the word "<em>program</em>". The <abbr title="Featureless Linux Library">FLL</abbr> project does contain related programs but these are kept to a minimal. The purpose of the programs in this project are to have fully functional and usable example programs. They are not examples in the traditional sense but are instead full blown implementations.
+ </p>
+ <p class="p">
+ The <strong>Featureless Make</strong> is also an exception case. I wrote a thesis regarding the GNU make system and I proposed the <strong>Featureless Make</strong> as a solution that utilizes the <strong>Featureless Settings Specification</strong>. This is the foundation that birthed the <strong>Featureless Linux Library</strong>. For this reason, the <strong>Featureless Make</strong> will always be part of the <abbr title="Featureless Linux Library">FLL</abbr> project.
+ </p>
+ <p class="p">
+ Many of the programs provided by the <abbr title="Featureless Linux Library">FLL</abbr> are a way of extending the library in such a way that a shell script, such as GNU Bash, can utilize the library. Programs like the <strong>FSS Basic Read</strong> are examples of this.
+ </p>
+ <p class="p">
+ Other programs, namely the <strong>Controller</strong> program are not intended to be directly part of this project in the long term. They exist within this project for development convenience. Eventually they will budd off into their own separate project. These separate projects will still depend on and use the <abbr title="Featureless Linux Library">FLL</abbr>.
+ </p>
+ <p class="p">
+ The way in which data is stored, utilized, and communicated should also follow similar design and principles. The standards and their accompanying specifications are provided by the <abbr title="Featureless Linux Library">FLL</abbr> to achieve this.
+ </p>
+ <p class="p">
+ Keep it simple is one of the goals of the project. But again, all of you people out there that love infinitives, stop it. This project follows "<em>keep it simple</em>" rather than "<em>keep it absolutely simple</em>". There are many situations where complexity is not only encouraged but also necessary.
+ </p>
+ </div>
+ </section>
+
+ <section id="art_of_communication" class="section">
+ <header class="section-header header separate">
+ <h2 class="section-title h h2">Art of Communication</h2>
+ </header>
+
+ <div class="section-content">
+ <p class="p">
+ An important aspect of the design and principles of the <abbr title="Featureless Linux Library">FLL</abbr> project is that of communication. All aspects of the project are designed to have both explicit and implicit meaning. From the syntax and styling to the standards and protocols.
+ </p>
+ <p class="p">
+ The project hosts numerous plain text files following a given <abbr title="Featureless Settings Specification">FSS</abbr> format. The IKI format may be used in many of these files to provide further assistance in communicating different aspects of the documentation.
+ </p>
+ <p class="p">
+ These text files are then process either through scripts or manually and presented in different formats. One such format is on the Kevux website where this document might reside. This results in a bit of redudancy and complexity but achieves the goal of communication.
+ </p>
+ <p class="p">
+ Idealistically the <abbr title="Featureless Linux Library">FLL</abbr> project will be written in multiple programming languages. This would mean that the ideas represented by this project are communicated through different software languages. Given the complexity of this task, this is not a goal post but is instead an ideal. To that end, the design of the <abbr title="Featureless Linux Library">FLL</abbr> and related projects is done in such a way to be open-ended and better allow for additional languages even if no additional language is ever used.
+ </p>
+ </div>
+ </section>
+ </main>
+ </div>
+ </div>
+ </body>
+</html>
</header>
<div class="section-content">
- <p>
+ <p class="p">
The Featureless Linux Library defines several standards for use in this project. Many of these standards are defined via the Featureless Settings Specifications. Most of these are focused on settings files (configuration files) but are written general enough to support a wide range of uses. The original project that the <abbr title="Featureless Linux Library">FLL</abbr> project is built around is the <em>Featureless Make</em> program, also called <strong>Fake</strong>. The <strong>Fake</strong> program is a great example on how the <abbr title="Featureless Settings Specifications">FSS</abbr> are intended to be used.
</p>
- <p>
+ <p class="p">
The standards are not limited to those defined in the <abbr title="Featureless Settings Specifications">FSS</abbr>. There are the <em>IKI</em> standards (which is not an acronym). The term <em>IKI</em> plays off of the term <em>Wiki</em>. The <em>IKI</em> standard is intended to have simpler syntax than a <em>Wiki</em> syntax and is used in several <abbr title="Featureless Linux Library">FLL</abbr> projects and even inside standards defined by <abbr title="Featureless Settings Specifications">FSS</abbr>.
</p>
</div>
</header>
<div class="section-content">
- <p>
+ <p class="p">
The Featureless Settings Specifications describe a set of standards designed around the age-old design principle referred to as <em>Keep It Simple Stupid</em>, aka <abbr title="Keep It Simple Stupid">KISS</abbr>. The <abbr title="Featureless Settings Specifications">FSS</abbr> are primarily intended for settings files but are extensible enough to be used beyond that.
</p>
- <p>
+ <p class="p">
The <abbr title="Featureless Settings Specifications">FSS</abbr> defines the following:
</p>
<ul>
<li>The settings files are setup so that they should (reasonably) produce easy readability on both the console and in a GUI.</li>
<li>The specifications should strive for completeness (see the <a href="fll/specifications.html#completeness_theorem" class="link">Completeness Theorem</a>).</li>
</ul>
- <p>
+ <p class="p">
The most basic form of <abbr title="Featureless Settings Specifications">FSS</abbr> consists of two main parts: an <em>Object</em> and the <em>Content</em>.
</p>
<dl class="dl">
<dd class="dd">The data associated with a given Object; all Content <em>must</em> have an associated <em>Object</em>.</dd>
</div>
</dl>
- <p>
+ <p class="p">
Objects and Contents can include any characters allowed by the specifications.
The specification may choose how a given Object or Content are represented and parsed.
For example, in <code class="code">fss-0000 (Basic)</code>, Content is treated as a single item whereas in <code class="code">fss-0001 (Extended)</code>, Content is broken apart in multiple sub-parts.
</p>
- <p>
+ <p class="p">
Contents may be broken up into zero or more discrete sets of Content.
Each of these discrete sets of Content are referred to as a column.
These columns do not need to be setup in a column structure, the word <em>column</em> is simply used as a grouping terminology.
For example, in <code class="code">fss-000 (Basic)</code> the entire Content may be further represented as a single column.
For example, in <code class="code">fss-001 (Extended)</code> the entire Content may be further represented as multiple columns.
</p>
- <p>
+ <p class="p">
In all cases, specifications that separate Objects from Contents using white space, the first white space separating the Object and Content must not be considered part of the Object nor part of the Content.
All spaces after the first separating white space is generally ignored until the first non white space character is found, unless otherwise specified.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, all specifications are newline sensitive (<code class="code">\n</code> only).
Newline characters are only <code class="code">\n</code> and are never anything else (<code class="code">\r</code> is not considered newline in any manner).
These specifications refer to characters that have printable representation as <em>printable</em>.
In terms of processing, it is recommended that the <code class="code">NULL</code> character is not considered the end of a string, but this is only a suggestion.
Any specification may chose to limit, restrict, or otherwise prohibit special Unicode characters such as combining characters or zero-width characters.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, newlines designate the potential start (or end) of an Object or Content.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, white space may exist to the left of the start of Objects.
Unless otherwise specified, white space may exist to the right of the end of Objects, but only if that given Object is properly quoted and the white space is after the terminating quote but before any Content.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, white space immediately both before (and after, outside of the terminating quote) an Object is not considered part of the Object.
This simplifies identifying the object, use quoted Objects to support white space before/after an object for styling purposes.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, quotes may only be either a single quote <code class="code">'</code> or a double quote <code class="code">"</code> and only a backslash <code class="code">\</code> may be used as a delimiter.
</p>
- <p>
+ <p class="p">
For example, <code class="code">fss-0000 (Basic)</code>:
</p>
<ul>
<li><code class="code">"Object 1\"</code> is an unterminated object due to the escaped closing quote.</li>
<li><code class="code">"Object 1\\"</code> has content starting at the <code class="code">has</code>, with an Object named <code class="code">"Object 1\"</code>.</li>
</ul>
- <p>
+ <p class="p">
Unless otherwise specified, character/data delimits are performed only when required and not unilaterally.
In the case of Objects, delimits would only apply when that Object could be potentially identified as an Object.
For example, <code class="code">fss-0001 (Extended)</code> needs quotes to group parts that include spaces, if there is no initial quote, then a quote following the data <em>must not</em> be delimited.
</p>
- <p>
+ <p class="p">
Such as these following three lines:
</p><pre class="preserve">
"Object 1" "This is a single quoted Content." \"Additional unquoted Content."
Object_2 This is multiple" Contents and the trailing quote does not need to be delimited.
"Object \"3" 'Wouldn't require delimits if no white space or end of string after.'
</pre>
- <p>
+ <p class="p">
Unlike this specification, a more traditional delimit process would have the above three lines instead represented as:
</p><pre class="preserve">
"Object 1" "This is a single quoted Content." \"Additional unquoted Content.\"
Object_2 This is multiple\" Contents and the trailing quote does not need to be delimited.
"Object \\"3" 'Wouldn\'t require delimits if no white space or end of string after.'
</pre>
- <p>
+ <p class="p">
These examples would resolve as follows:
</p><pre class="preserve">
1) Object\:
Content\:
- Wouldn't require delimits if no white space or end of string after.
</pre>
- <p>
+ <p class="p">
All specifications are expected to support or be of the character encoding <abbr title="Unicode Transformation Format 8-bit">UTF-8</abbr>; however, there is no imposed restriction on supporting or using any other encoding.
Those encodings must only support the appropriate characters required by a given standard for differentiating Objects, Contents, and delimits.
All specifications do assume <abbr title="American Standard Code for Information Interchange">ASCII</abbr> and Unicode support.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, comments are designated by the pound symbol <code class="code">#</code> but only if only white space is to the left of the pound or the pound <code class="code">#</code> is at the start of the line.
There is no support for inline comments.
Unless otherwise specified, the start comment may be delimited by <code class="code">" in the same manner as Objects and Contents are.
A line containing a valid comment is in its entirety ignored.
This means that if there is white space before the designation symbol (the pound <code class="code">#</code> character) then that white space is ignored.
</p>
- <p>
+ <p class="p">
Unless otherwise specified, all designation characters <em>must</em> represent <abbr title="American Standard Code for Information Interchange">ASCII</abbr> codes.
With designation characters being any character code used to designate how to identify an Object or Content (such as a colon <code class="code">:</code> at the end of a basic list).
This keeps the processing and logic simple and safe, for both <abbr title="Unicode Transformation Format 8-bit">UTF-8</abbr> and <abbr title="American Standard Code for Information Interchange">ASCII</abbr>.
However, these white space used as a designation character, must be printing white space that are not combining white space characters.
Any visible/graph character that is considered a white space (such as <code class="code">U+1680</code> <code class="code"> </code>) is not to be considered a white space, unless otherwise specified.
</p>
- <p>
+ <p class="p">
When used for syntax matching purposes, zero-width Unicode characters are only to be considered zero-width unless otherwise specified.
For example, the <em>invisible plus</em> character (<code class="code">U+2064</code>) is not to be considered as a plus.
</p>
- <p>
+ <p class="p">
The <abbr title="Unicode Transformation Format 8-bit">UTF-8</abbr> <abbr title="Byte Order Mark">BOM</abbr> is not allowed as a Byte Order Mark; instead, it must always be treated as the character represented by its code (unless explicitly allowed to represent a <abbr title="Byte Order Mark">BOM</abbr> by a standard).
</p>
- <p>
+ <p class="p">
The only Unicode dash-like characters allowed as a <em>dash</em> are those intended to connect, such as the Unicode hyphens (<code class="code">U+2010</code> and <code class="code">U+2011</code>) (unless otherwise specified).
</p>
- <p>
+ <p class="p">
In any specification where security is intended, if there exists a Unicode character that matches an <abbr title="American Standard Code for Information Interchange">ASCII</abbr> character, that Unicode character <em>may</em> be prohibited by that standard in favor of the <abbr title="American Standard Code for Information Interchange">ASCII</abbr> equivalent.
One such example is in the case of a <abbr title="Byte Order Mark">URL</abbr>, where the name could be used to trick a person (<code class="code">http://this-site.com/</code> vs <code class="code">http://this‐site.com/</code>).
This (potential insecure behavior) is allowed in general because a well written program would be able to detect and communicate the possible misunderstanding and thereby avoid mistakes without imposing any character restrictions.
</p>
- <p>
+ <p class="p">
This is a common behavior for security reasons, each character used for any special purposes must be visibly distinct, with white space and non-printing characters as the exception to the words <em>visibly distinct</em>.
</p>
- <p>
+ <p class="p">
The following are core specifications (each with a common name associated with the specification number):
</p>
<ul>
</header>
<div class="section-content">
- <p>
+ <p class="p">
IKI is a minimally structured WIKI-like syntax meant to be simpler than WIKI syntax.
</p>
- <p>
+ <p class="p">
The IKI syntax provides a vocabulary name (with specific context associated with it) followed by quoted code that is associated with the given vocabulary name.
The vocabulary represents a list of allowed variable names that may also have specific contextual meaning defined by a given IKI specification.
The variable name is considered the <em>Object</em>.
The variable value is considered the <em>Content</em>.
</p>
- <p>
+ <p class="p">
The IKI format will use <code class="code">iki-0000</code> to represent an IKI with no explicitly defined vocabulary.
Whereas <code class="code">iki-0001</code> and beyond represent a specific IKI vocabulary.
</p>
- <p>
+ <p class="p">
A potential IKI variable name starts on word (or <code class="code">_</code>, <code class="code">-</code>, <code class="code">+</code>) characters.
White space and non-word (and non <code class="code">_</code>, <code class="code">-</code>, <code class="code">+</code>) character punctuations may not exist as part of the variable name.
The only Unicode dash-like characters allowed as a "dash" are those intended to connect, such as the Unicode hyphens (<code class="code">U+2010</code> and <code class="code">U+2011</code>).
</p>
- <p>
+ <p class="p">
Any valid IKI data may be escaped to make it treated as non-IKI data by prepending a backslash <code class="code">" before the colon code:</code>:" that is before the opening quote (single or double).
</p>
- <p>
+ <p class="p">
Unicode punctuation connector characters are supported just like <code class="code">_</code>, except when they connect outside the current line (such as <code class="code">U+FE33</code> <code class="code">︳</code>).
Unicode invisible punctuations (such as invisible plus: <code class="code">U+2064</code>) are not considered a punctuations in this standard (because they a zero-width characters), therefore they are not to be considered a valid <code class="code">_</code>, <code class="code">-</code>, or <code class="code">+</code> Unicode equivalents.
</p>
- <p>
+ <p class="p">
Key:
</p>
<ul>
<li><code class="code">*</code> = zero or more occurrences.</li>
<li><code class="code">~</code> = one or more occurrences, or zero if at start of file.</li>
</ul>
- <p>
+ <p class="p">
Before Structure:
</p>
<ul>
<li><code class="code">\x*\W~\*:*</code></li>
</ul>
- <p>
+ <p class="p">
Structure:
</p>
<ul>
<li><code class="code">\o\e:\q\c\q</code></li>
</ul>
- <p>
+ <p class="p">
After Structure:
</p>
<ul>
<li><code class="code"></code></li>
</ul>
- <p>
+ <p class="p">
Example File:
</p><pre class="preserve">
# fss-000c iki-0000
The following emphasis\:"is escaped to not be treated as IKI data".
</pre>
- <p>
+ <p class="p">
Example Results:
</p><pre class="preserve">
Objects would be:
2.1) http://www.example.com/url with space/
3.1) const char *string = "My \"quoted\" C string.";
</pre>
- <p>
+ <p class="p">
The following are core specifications (each with a common name associated with the specification number):
</p>
<ul>
</header>
<div class="section-content">
- <p>
+ <p class="p">
The <strong>Completeness Theorem</strong> represents an informal theory by Kevin Day focusing on how software should be complete. The theory has not been formalized and the following is a basic explanation. A formal definition may be provided in the future.
</p>
- <p>
+ <p class="p">
When developing software, one should not program for the minimum requirements. Instead, one should consider the scope of the project and its intended design. Taking that into consideration all functionality needed to achieve this should be considered and implemented.
</p>
- <p>
+ <p class="p">
The most common misconceptions about this theorem is that it is not about writing all possible combinations, permutations, possibilities, etc. In fact, it is more accurate to say the opposite. The key focus is figuring out what the scope and intended functionalities are and make sure to achieve those.
</p>
- <p>
+ <p class="p">
This does not conflict with <abbr title="Keep It Simple Stupid">KISS</abbr> but instead complements it.
</p>
- <p>
+ <p class="p">
If this is not clear, then consider thinking of things this way. The <abbr title="Keep It Simple Stupid">KISS</abbr> focuses on keeping the design and process simple. The <strong>Completeness Theorem</strong> focuses on making sure the design is complete.
</p>
- <p>
+ <p class="p">
Now if, say a car, is designed to follow <abbr title="Keep It Simple Stupid">KISS</abbr> but violates the <strong>Completeness Theorem</strong>, then that car could be built without doors. Not having doors simplifies the car. It is much simpler and easier to get in and out of.
</p>
- <p>
+ <p class="p">
Using that example, a car designed to follow both <abbr title="Keep It Simple Stupid">KISS</abbr> and the <strong>Completeness Theorem</strong> would have doors.
</p>
- <p>
+ <p class="p">
To better understand the <strong>Completeness Theorem</strong>, again take the car example. If the car is intended to be used only in say photo shoots and is not in any way intended ever to be used, then as per the <strong>Completeness Theorem</strong>, the car would not need an engine. Whereas a car designed and intended to be used that does not have an engine would fail to follow the <strong>Completeness Theorem</strong>.
</p>
- <p>
+ <p class="p">
The <strong>Completeness Theorem</strong> is subjective and is intended to be used as a guide.
</p>
- <p>
+ <p class="p">
The <strong>Completeness Theorem</strong> asserts that perfection is impossible and pointless and one must instead understand what is necessary to complete the project rather than to handle all possibilities. Simply because perfection isn't possible doesn't mean one must lower their standards or have no standards. Determine what is or is not needed to complete the project and meet that rather than meet less than that.
</p>
</div>
<dd class="dd">A <em>Web Service Interface</em> is a new term created so that this project can more appropriately communicate the concept of a web service. A <em>Web Service Interface</em> describes the interface in which to communicate to and receive response from a web service and is described by or adheres to some web protocol.</dd>
</div>
</dl>
- <p>
+ <p class="p">
Based on this terminology, a standard is the representation of some set of rules and guidelines, however it is the specification that actually defines and describes those roles. The last '<em>S</em>' in <abbr title="Featureless Settings Specifications">FSS</abbr> can therefore be used to represent either "standard" or "specification" in casual speech. Given that an implementation is not a standard, an implementation can deviate from the standard (or the specification of some standard). Such deviations do not alter the standard nor do they alter the specification.
</p>
- <p>
+ <p class="p">
Good documentation practices suggest the documentation of an implementation. It is very easy to confuse the specification of an implementation of some standard with the specification of the standard itself. This has happened several times in history where some implementation violates the standard but despite being non-standard that implementation becomes popular. When the specification of that, now non-standard, implementation becomes popularized, those properly following the specification of the standard tend to suffer.
</p>
- <p>
+ <p class="p">
This project encourages deviations from the standards and such actions are allowed and protected by the copyright licenses. However, this project discourages communicating compliance of some standard when something is, in fact, not compliant. Problems in the interpretation of a standard fall under communication problems and are not considered deviations from the standard even though it may technically be a deviation. It is for these reasons that the terminology has been explicitly defined, clarified, and presented on this page.
</p>
</div>
projects / kevux.org-website / commitdiff