FLL - Specifications
Author: Kevin Day
Description: Featurless Linux Library Specifications
Keywords: Kevin Day, Kevux, FLL, Featureless, Linux, Library, Distribution, Open-Source, specification, standard

# Featureless Linux Library Specifications

## About

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 FLL project is built around is the Featureless Make program, also called Fake. The Fake program is a great example on how the FSS are intended to be used.

The standards are not limited to those defined in the FSS. There are the IKI standards (which is not an acronym). The term IKI plays off of the term Wiki. The IKI standard is intended to have simpler syntax than a Wiki syntax and is used in several FLL projects and even inside standards defined by FSS.

## Featureless Settings Specifications

The version date of this specification is `2024/01/15`.

The license (copyright) is Open Standard License 1.0 or greater.

The Featureless Settings Specifications describe a set of standards designed around the age-old design principle referred to as Keep It Simple Stupid, aka KISS. The FSS are primarily intended for settings files but are extensible enough to be used beyond that.

The FSS defines the following:

- Will consist of numerous different kinds of specification files, depending on the type of information stored.
- As with the practice of `#!/bin/bash`, the setting files should have the following: `# fss-????` format, such as "# fss-0001".
- Multiple sub-standards may be appended to the FSS header, using the same format structure, such as supporting IKI: "# fss-0000 iki-0000" or HTML5: "# fss-0000 html-0005".
- With the `?` representing the (hexadecimal/base-16) number that represents the particular specification structure.
- All settings specifications should avoid any form of noise, relative to the data being stored.
- XML would be considered anti-KISS due to the extreme level of noise generated by the XML language (not easy to read).
- The settings files are setup so that they should (reasonably) produce easy readability on both the console and in a GUI.
- The specifications should strive for completeness (see the Completeness Theorem).

The most basic form of FSS consists of two main parts: an Object and the Content.

Object
  Considered the name or identifier of some property or data. Objects; do not require an associated Content.
Content
  The data associated with a given Object; all Content must have an associated Object.

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 `FSS-0000 (Basic)`, Content is treated as a single item whereas in `FSS-0001 (Extended)`, Content is broken apart in multiple sub-parts.

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 column is simply used as a grouping terminology. While a Content refers to the entire set, a column (more specifically, a Content column) refers to the individual discrete sets within the Content. For example, in `fss-000 (Basic)` the entire Content may be further represented as a single column. For example, in `fss-001 (Extended)` the entire Content may be further represented as multiple columns.

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.

Unless otherwise specified, all specifications are newline sensitive (`\n` only). Newline characters are only `\n` and are never anything else (`\r` is not considered newline in any manner). These specifications refer to characters that have printable representation as printable. These specifications refer to characters that have no printable representation as non-printable. White spaces characters that are printable, such as tabs and spaces, must be considered the same type for the purposes of parsing. Non-printing white spaces characters (zero-width characters) are ignored, are treated as placeholders for processing with the exception of combining characters. White spaces that use combining characters result in printable characters and the resulting combination is treated as not white space. Zero-width characters that use combining characters are treated as non-printing characters and are skipped. In terms of processing, it is recommended that the `NULL` 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.

Unless otherwise specified, newlines designate the potential start (or end) of an Object or Content.

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.

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.

Unless otherwise specified, quotes may only be either a single quote `'`, a double quote `"`, or a grave ``` and only a backslash `\` may be used as a delimiter.

For example, `FSS-0000 (Basic)`:

- `\"Object 1"` has content starting at the `1`, with an Object named `"Object`.
- `\\"Object 1"` has content starting at the `1`, with an Object named `\"Object`.
- `"Object 1\"` is an unterminated object due to the escaped closing quote.
- `"Object 1\\"` has content starting at the `has`, with an Object named `"Object 1\"`.

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, `FSS-0001 (Extended)` needs quotes to group parts that include spaces, if there is no initial quote, then a quote following the data must not be delimited.

Such as these following three lines:

    "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.'

Unlike this specification, a more traditional delimit process would have the above three lines instead represented as:

    "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.'

These examples would resolve as follows:

    1) Object\:
      - Object 1
       Content\:
      - This is a single quoted Content.
      - "Additional
      - unquoted
      - Content"
    2) Object\:
      - Object_2
       Content\:
      - This
      - is
      - multiple"
      - Contents
      - and
      - the
      - trailing
      - quote
      - does
      - not
      - need
      - to
      - be
      - delimited.
    3) Object\:
      - Object \"3
       Content\:
      - Wouldn't require delimits if no white space or end of string after.

All specifications are expected to support or be of the character encoding UTF-8; 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 ASCII and Unicode support.

Unless otherwise specified, comments are designated by the pound symbol `#` but only if only white space is to the left of the pound or the pound `#` is at the start of the line. There is no support for inline comments. Unless otherwise specified, the start comment may be delimited by `\` in the same manner as Objects and Contents are. This delimit only applies to the start of a comment (the pound `#` character) as there is no terminating character for a comment (other than a newline `\n`). 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 `#` character) then that white space is ignored.

Unless otherwise specified, all designation characters must represent ASCII codes. With designation characters being any character code used to designate how to identify an Object or Content (such as a colon `:` at the end of a basic list). This keeps the processing and logic simple and safe, for both UTF-8 and ASCII. White space used for designation characters must include support for UTF-8 white space characters, unless otherwise specified. 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 `U+1680` `` ) is not to be considered a white space, unless otherwise specified.

When used for syntax matching purposes, zero-width Unicode characters are only to be considered zero-width unless otherwise specified. For example, the invisible plus character (`U+2064`) is not to be considered as a plus.

The UTF-8 BOM 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 BOM by a standard).

The only Unicode dash-like characters allowed as a dash are those intended to connect, such as the Unicode hyphens (`U+2010` and `U+2011`) (unless otherwise specified).

In any specification where security is intended, if there exists a Unicode character that matches an ASCII character, that Unicode character may be prohibited by that standard in favor of the ASCII equivalent. One such example is in the case of a URL, where the name could be used to trick a person (`http://this-site.com/` vs `http://this‐site.com/`). 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.

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 visibly distinct.

The following are core specifications (each with a common name associated with the specification number):

- FSS-0000: Basic
- FSS-0001: Extended
- FSS-0002: Basic List
- FSS-0003: Extended List
- FSS-0004: Very Basic List
- FSS-0005: Somewhat Basic List
- FSS-0006: Somewhat Extended List
- FSS-0007: Very Extended List
- FSS-0008: Embedded List
- FSS-0009: Reverse Mapping
- FSS-000A: Extended Reverse Mapping
- FSS-000B: Simple List
- FSS-000C: Iki Text
- FSS-000D: Basic Rule
- FSS-000E: Payload
- FSS-000F: Simple Packet
- FSS-0010: Encrypted Simple Packet

## IKI

The version date of this specification is `2024/11/21`.

The license (copyright) is Open Standard License 1.0 or greater.

IKI is a minimally structured WIKI-like syntax meant to be simpler than WIKI syntax.

The IKI syntax describes a Variable that is defined by a Vocabulary name followed by quoted value called the Content.

The Variable refers to the Vocabulary, Content, and associated syntax that describes the Variable. The Variable name may be wrapped by a single open bracket, `[` (`U+005B`), at the start and a single close bracket, `]` (`U+005D`), at the end. The open and close brackets, also called the wrapping characters, for the Variable do not utilize escaping characters and instead any escaping is perform against the colon `:` (`U+003A`) that separates the Vocabulary from the Content. The Vocabulary generally defines the context and many of the IKI specifications may provide a discrete set of allowed Vocabulary. The Vocabulary may also be referred to as the Object. The Vocabulary only allows word characters or one of `_` (`U+005F`), `-` (`U+002D`), `+` (`U+002B`), `[` (`U+005B`)). White space, non-word, and non `_` (`U+005F`), `-` (`U+002D`), `+` (`U+002B`)) character punctuation 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 (`U+2010` and `U+2011`). Unicode punctuation connector characters are supported just like `_`, except when they connect outside the current line (such as `U+FE33` `︳`). The immediate left of a Vocabulary must not be a valid Vocabulary character, unless the Vocabulary is wrapped using the wrapping characters. Unicode invisible punctuation (such as invisible plus: `U+2064`) are not considered a punctuation in this standard (because they a zero-width characters), therefore they are not to be considered a valid `_` (`U+005F`), `-` (`U+002D`), or `+` (`U+002B`) Unicode equivalents.

The wrapping characters characters are not part of the Vocabulary name and instead only provide the syntax used to help identify a valid Variable. The wrapping characters characters are part of the Variable. The wrapping characters do not support escaping. Both wrapping characters must be specified or neither.

The Content refers to the value of the Variable. The Content is wrapped one of the following quote characters: single quote `'` (`U+0027`), double quote `"` (`U+0022`), or grave ``` (`U+0060`). The Content must escape any quotes that match the open and close quote used for the Variable by utilizing a backslash `\` (`U+005C`). If a matching closing quote is not found until the end of the data (or file), then this unclosed Variable is considered invalid. The handling of this erroneous case is left to the implementation.

The backslashes used for escaping quotes use `\` (`U+005C`). Unless otherwise specified, these backslash escapes are performed only when required and not unilaterally. One backslash escapes the valid quote, resulting in the quote being part of the Content. Two backslashes escape the backslash, resulting in the backslash (but not the quote) being part of the Content. An odd number of backslashes before a valid quote results in the backslashes and the quote being escaped. An even number of backslashes before a valid quote results in the backslashes but not the quote being escaped.

The IKI format will use `iki-0000` to represent an IKI with no explicitly defined vocabulary. Whereas `iki-0001` and beyond represent a specific IKI vocabulary.

Key:

- `\o` = any printable word character, including `_` (`U+005F`), `-` (`U+002D`), `+` (`U+002B`) (and Unicode equivalents).
- `\c` = any character, including white space and non-printing, and any escaped quote (used as the opening quote) or a any quote (unescaped) not used as the opening quote.
- `\q` = either a single quote `'` (`U+0027`), a double quote `"` (`U+0022`), or a grave ``` (`U+0060`).
- `\x` = any character.
- `\W` = any non-word character, discluding `_` (`U+005F`) (and Unicode equivalents), `-` (`U+002D`) (and Unicode equivalents), and `+` (`U+002B`) (and Unicode equivalents).
- `\e` = an optional escape sequence of any number of backslashes, such as `\` (`U+005C`).
- `[` = a single (conditionally optional) open bracket, `[` (`U+005B`).
- `]` = a single (conditionally optional) close bracket, `]` (`U+005D`).
- `*` = zero or more occurrences.
- `~` = one or more occurrences, or zero if at start of file.
- `+` = one or more occurrences.
- `:` = The colon `:` (`U+003A`).

Before Structure:

- `\x*\W~`

Structure:

- `[\o+]\e:\q\c\q`

After Structure:

- ``

Example File:

    # fss-000c iki-0000

    This is my sentence, anything can go here but sometimes I want to italic:"emphasize some text".

    Other times I want to render a URL such as this example URL: url:'http://www.example.com/url with space/'.

    There are no comments, except for maybe the FSS:"Featureless Settings Specification" header (which would not resolve to any IKI syntax anyway).

    Quotes may be included, such as: code:"const char *string = \"My \\\"quoted\\\" C string.\";".

    The following italic\:"is escaped to not be treated as IKI Variable".

    The conditionally optional open and close brackets allow for putting a variable directly next to another word character like: [context]:"bold"this[context]:"bold".

    These are examples of escapes: one:"\" escape", two:"\\" escape", three:"\\\" escape", six:"\\\\\\" escape".

    These are examples of non-escapes: one:"\' escape", two:"\\' escape", three:"\\\' escape", six:"\\\\\\' escape".

    These slashes \ \\ \\\ are not escaped because there is now quote immediately after each of them.

Example Results:

    Objects (also called vocabulary or variable name) would be:
       1.1) italic
       2.1) URL
       3.1) FSS
       4.1) code
       5.1) context
       6.1) context
       7.1) one
       8.1) two
       9.1) three
      10.1) six
      11.1) one
      12.1) two
      13.1) three
      14.1) six

    Contents (also called variable value) would be:
       1.1) emphasize some text
       2.1) http://www.example.com/url with space/
       3.1) Featureless Settings Specification
       4.1) const char *string = "My \"quoted\" C string.";
       5.1) bold
       6.1) bold
       7.1) " escape
       8.1) \
       9.1) \" escape
      10.1) \\\
      11.1) \' escape
      12.1) \\' escape
      13.1) \\\' escape
      14.1) \\\\\\' escape

The following are core specifications (each with a common name associated with the specification number):

- iki-0000: Unrestricted
- iki-0001: Basic
- iki-0002: Simple Script

## EKI

The version date of this specification is `2024/11/21`.

The license (copyright) is Open Standard License 1.0 or greater.

EKI is an extended EKI format that introduces the ability to have multiple variable names (Objects) per variable value (Content).

The EKI syntax is identical to the EKI syntax and all of its rules apply except for the modification defined in this specification.

This variable name, or Object, now supports an additional character, `:` (`U+003A`), is used to separate each individual variable name. Each variable name must follow the same requirements of a valid variable name as specified in the EKI specification. Only the last `:` (`U+003A`) before the opening single quote (`U+0027`), double quote (`U+0022`), or grave (`U+0060`) shall be a candidate for being escaped. When this escape is in place of a valid EKI variable, then that would be variable is no longer considered an EKI variable.

Key:

- `\o` = any printable word character, including `_`, `-`, `+` (and Unicode equivalents).
- `\O` = any printable word character, including `_`, `-`, `+` (and Unicode equivalents) followed by a colon `:` (`U+003A`) (cannot be only a colon by itself).
- `\c` = any character, including white space and non-printing, and any delimited quote (used as the opening quote) or a any quote (undelimited) not used as the opening quote.
- `\q` = either a single quote `'` (`U+0027`), a double quote `"` (`U+0022`), or a grave ``` (`U+0060`).
- `\x` = any character.
- `\W` = any non-word character, discluding `_` (and Unicode equivalents), `-` (and Unicode equivalents), `+` (and Unicode equivalents), and colon `:` (`U+003A`).
- `\e` = an optional escape sequence of any number of backslashes, such as `\` (`U+005C`).
- `[` = a single conditionally optional open bracket, `[` (`U+005B`).
- `]` = a single conditionally optional close bracket, `]` (`U+005D`).
- `*` = zero or more occurrences.
- `~` = one or more occurrences, or zero if at start of file.
- `+` = one or more occurrences.
- `:` = The colon `:` (`U+003A`).

Before Structure:

- `\x*\W~`

Structure:

- `[\O*\o+]\e:\q\c\q`

After Structure:

- ``

Example File:

    # fss-000c eki-0000

    This is my sentence, anything can go here but sometimes I want to italic:"emphasize some text".

    Other times I want to render a URL with bold such as this example URL: bold:url:'http://www.example.com/url with space/'.

    There are no comments, except for maybe the FSS:"Featureless Settings Specification" header (which would not resolve to any EKI syntax anyway).

    Quotes may be included, such as: code:"const char *string = \"My \\\"quoted\\\" C string.\";".

    The following bold:italic\:"is escaped to not be treated as EKI data".

    The conditionally optional open and close brackets allow for putting a variable directly next to another word character like: [context]:"bold"this[context]:"bold".

    Multiple Objects within a bracket is also valid, like: before[bold:context]:"important"after.

    These are examples of escapes: one:"\" escape", two:"\\" escape", three:"\\\" escape", six:"\\\\\\" escape".

    These are examples of non-escapes: one:"\' escape", two:"\\' escape", three:"\\\' escape", six:"\\\\\\' escape".

    These slashes \ \\ \\\ are not escaped because there is now quote immediately after each of them.

Example Results:

    Objects (also called vocabulary or variable name) would be:
       1.1) italic
       2.1) bold
       2.2) URL
       3.1) FSS
       4.1) code
       5.1) context
       6.1) context
       7.1) bold
       7.2) context
       8.1) one
       9.1) two
      10.1) three
      11.1) six
      12.1) one
      13.1) two
      14.1) three
      15.1) six

    Contents (also called variable value) would be:
       1.1) emphasize some text
       2.1) http://www.example.com/url with space/
       3.1) Featureless Settings Specification
       4.1) const char *string = "My \"quoted\" C string.";
       5.1) bold
       6.1) bold
       7.1) important
       8.1) " escape
       9.1) \\
      10.1) \" escape
      11.1) \\\
      12.1) \' escape
      13.1) \\' escape
      14.1) \\\' escape
      15.1) \\\\\\' escape

The following are core specifications (each with a common name associated with the specification number):

- eki-0000: Unrestricted
- eki-0001: Basic

## Other

The FSS, IKI and EKI are not the only standards provided by the FLL.

The following are other specifications that are provided:

- Time and EpochTime

Unless otherwise specified, these have a license (copyright) of Open Standard License 1.0 or greater.

## Completeness Theorem

The Completeness Theorem 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.

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.

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.

This does not conflict with KISS but instead complements it.

If this is not clear, then consider thinking of things this way. The KISS focuses on keeping the design and process simple. The Completeness Theorem focuses on making sure the design is complete.

Now if, say a car, is designed to follow KISS but violates the Completeness Theorem, 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.

Using that example, a car designed to follow both KISS and the Completeness Theorem would have doors.

To better understand the Completeness Theorem, 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 Completeness Theorem, 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 Completeness Theorem.

The Completeness Theorem is subjective and is intended to be used as a guide.

The Completeness Theorem 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.

## Terminology

ABI
  An Application Binary Interface is a binary implementation of an API making it an implementation of a specification. An ABI is neither a specification nor a standard.
API
  An Application Programming Interface is a specification of some implementation of a standard be it a formally defined standard or an informally defined standard. This is in effect, documentation. Note that this is a specification of an implementation rather than a specification of a standard.
Implementation
  Something that applies (implements) a standard or specification.
Protocol
  In the context of computer software, this is a standard focused on communication between two parties (often referring to Internet communication). Web services often provide, use, and follow protocols. These web protocols are commonly incorrectly referred to as an API.
SBI
  A Software Binary Interface is a new term created so that this project can more appropriately communicate the concept of what is traditionally referred to as an ABI. A Software Binary Interface is a more semantically accurate term intended to fully replace the misnamed ABI term.
Service
  Any action or labor performed by one party for another party (such as one person helping another person). In regards to computers and networking a service is often used to represent a web service often provided by a website. It is common for people to misrepresent a web service by saying they are using an API when, in fact, they are using a web service.
Specification
  A specific interpretation or clarification of a standard, such as the documentation that describes how to use or follow a standard.
SSI
  A Software Source Interface is a new term created so that this project can more appropriately communicate the concept of what is traditionally referred to as an API. A Software Source Interface is a more semantically accurate term intended to fully replace the misnamed API term.
Standard
  A set of rules and guidelines.
WSI
  A Web Service Interface is a new term created so that this project can more appropriately communicate the concept of a web service. A Web Service Interface 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.

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 'S' in FSS 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.

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.

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.