+

+ +

+

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 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). + 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, or are considered part of the appropriate character if they are Unicode combining characters (this includes zero-width punctuation characters and similar). + 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. +

+

+ 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 ' or a double quote " 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 code:#" 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): +

+

+ +

+

IKI

+

+ +

+

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

+

+ 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 Object. + The variable value is considered the Content. +

+

+ 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. +

+

+ A potential IKI variable name starts on word (or _, -, +) characters. + White space and non-word (and non _, -, +) 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 (U+2010 and U+2011). +

+

+ Any valid IKI data may be escaped to make it treated as non-IKI data by prepending a backslash " before the colon code::" that is before the opening quote (single or double). +

+

+ Unicode punctuation connector characters are supported just like _, except when they connect outside the current line (such as U+FE33 ï¸³). + Unicode invisible punctuations (such as invisible plus: U+2064) are not considered a punctuations in this standard (because they a zero-width characters), therefore they are not to be considered a valid _, -, or + Unicode equivalents. +

+

+ Key: +

+

\o = any printable word character, including _, -, + (and Unicode equivalents).
\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 ' or a double quote ".
\x = any character.
\W = any non-word character, discluding _, -, + (and Unicode equivalents).
\e = an optional escape sequence of any number of backslashes, such as \.
* = 0 or more occurrences.
~ = one or more occurrences, or 0 if at start of file.

+

+ 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 emphasis:"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 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 emphasis\:"is escaped to not be treated as IKI data".
+

+

+ Example Results: +

+Objects would be:
+  1) emphasis
+  2) url
+  3) code
+
+Contents would be:
+  1.1) emphasize some text
+  2.1) http://www.example.com/url with space/
+  3.1) const char *string = "My \"quoted\" C string.";
+

+

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

+

+ +

+

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. +

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0000 (Basic)

+

+ +

+

+ Each Object starts at the beginning of a line and white space to the left of the Object is not treated as part of the object. + White space separates an Object from the Content. + An Object may be preceded by a newline, in which case means that the Object has no Content. + If only printing white space follows a valid Object, that Object is considered to have no Content. +

+

+ Content exists on the same line as the Object. + Content is represented as a single Content column terminated by a newline. + Content column consists of everything following the first non-white space character until the newline. + Content column includes trailing white space before newline is reached. + Content column does not include any of the leading white space. + No delimits are supported in the Content. +

+

+ Key: +

+

\s = white space, except newline.
\b = either white space or printable, except newline.
\q = non-white space or quoted white space with no white space outside of the quotes.
\n = newline.
* = zero or more occurrences.
+ = one or more occurrences.

+

+ Before Structure: +

+

+ Structure: +

+

\s*\q+\s+\b*\n

+

+ After Structure: +

+

+ Example: +

+# fss-0000
+# valid comments are ignored.
+"The Object" Content until newline.
+Second object set.
+

+

+ Example Results: +

+Object would be:
+1) The Object
+2) Second
+
+Content would be:
+1.1) Content until newline.
+2.1) object set.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0001 (Extended)

+

+ +

+

+ Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. + White space separates an Object from the Content. + An Object may be followed by a newline, in which case means that the Object has no Content. + If only printing white space follows a valid Object, that Object is considered to have no Content. +

+

+ Content exists on the same line as the Object. + Content is represented as multiple Content columns. + Content columns are white space separated parts within the Content and terminated by a newline. + Any number of Content columns may exist in the Content until the newline is reached. +

+

+ Key: +

+

\s = White space, except newline.
\b = Either white space or printable, except newline.
\q = Non-white space or quoted white space with no white space outside of the quotes.
\n = Newline.
* = Zero or more occurrences.
+ = One or more occurrences.
()* = Grouping that repeats 0 or more times.

+

+ Before Structure: +

+

+ Structure: +

+

\s*\q+\s+(\s*\q+)*\s*\n

+

+ After Structure: +

+

+ Example: +

+# fss-0001
+# valid comments are ignored.
+"The Object" Content "content 2" content_3.
+Second object set.
+

+

+ Example Results: +

+Objects would be:
+  1) The Object
+  2) Second
+
+Contents would be:
+  1.1) Content
+  1.2) content 2
+  1.3) content_3.
+
+  2.1) object
+  2.2) set.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0002 (Basic List)

+

+ +

+

+ Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. + A colon followed by any white space until a newline terminates a valid Object. + Non-white space may not follow the colon of a valid Object. +

+

+ Content is represented as a single Content column of every line following a valid object until the end of file (or string) or until the next valid Object is found. + Any Content that could be interpreted as a valid Object must have the colon delimited. +

+

+ There is no single-quote or double-quote delimitation in this specification. + Only the colon that would result in a valid Object can be delimited. +

+

+ Empty Objects are allowed, that is, the length of the object may be zero. +

+

+ Key: +

+

\s = White space, except newline.
\o = Any printable character, except unescaped ':'.
\l = Any printable character or white space, except unescaped ':'.
\c = either white space or printable, including newline, that not interpretable as an Object.
\n = Newline.
* = Zero or more occurrences.

+

+ Before Structure: +

+

+ Structure: +

+

\s*\o\l*:\s*\n\c*\n*

+

+ After Structure: +

+

+ Example: +

+# fss-0002
+# valid comments are ignored.
+"The Object":
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  This Does\:
+Second:
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+

+

+ Example Results: +

+  Objects would be:
+    1) "The Object"
+    2) Second
+
+  Contents would be:
+    1.1) Does not need to be quoted.
+         This: does not need to be delimited.
+         This Does:
+    2.1) Continues until EOS/EOF.
+         All white space, including newline (and leading white space) is "part of content."
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0003 (Extended List)

+

+ +

+

+ Each Object starts at the beginning of a line and white space to the left of the Object is not treated as an object. + An open-brace { followed by any white space until a newline terminates a possible valid Object. + An Object is not considered fully valid until a valid close-brace } is found, designating the end of the Content. + Non-white space may not follow the open-brace of a valid Object. +

+

+ Content is represented as a single Content column of every line following a valid object until the end of file (or string) or until a non-delimited close-brace }. + Any Content column that could be interpreted as an end of Content must be delimited if it should be part of the Content. + White space may follow a valid close-brace but a terminating newline must be present to designate a valid end of Content. +

+

+ There is no single-quote or double-quote delimitation in this specification. + Only the open-brace that would result in a valid Object or the close-brace that would terminate valid Content can be delimited. + When inside potentially valid Content (which follows a valid Object) the open-brace cannot be delimited because this standard is not-recursive. + When not inside any potentially valid Content (that is, there is no previous unclosed Object), then the Object may be delimited. + Likewise, the close-brace may only be delimited if it is within any potentially valid Content. +

+

+ Each delimit slash in a delimitable open-brace is treated as a potential delimit such that two slashes represents a single delimited slash (\\{ would represent \{). + Only the first delimit slash in a delimitable close-brace is treated as a potential delimit (\\\} would represent \\}). +

+

+ Empty Objects are allowed, that is, the length of the object may be zero. +

+ Key: +

+

\s = White space, except newline.
\o = Any printable character, except unescaped {.
\l = Any printable character or white space, except unescaped }.
\c = Either white space or printable, including newline, that is not interpretable as an Object.
\n = Newline.
* = Zero or more occurrences.

+

+ Before Structure: +

+

+ Structure: +

+

\s*\o\l*{\s*\n\c*\n\s*}\s*\n

+

+ After Structure: +

+

+ Example: +

+# fss-0003
+# valid comments are ignored.
+"The Object" {
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  \}
+}
+
+Second {
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+}
+

+

+ Example Results: +

+Objects would be:
+  1) "The Object"
+  2) Second
+
+Contents would be:
+  1.1) Does not need to be quoted.
+       This: does not need to be delimited.
+       }
+  2.1) Continues until EOS/EOF.
+       All white space, including newline (and leading white space) is "part of content."
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0004 (Very Basic List)

+

+ +

+

+ This is a fss-0002 (Basic List) whose Content is then processed as fss-0000 (Basic). +

+

+ All fss-0002 (Basic List) escapes are applied before any fss-0000 (Basic) is identified. +

+

+ See the fss-0000 (Basic) and fss-0002 (Basic List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-0004
+# valid comments are ignored.
+"The Object":
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  This Does\:
+Second:
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects would be:
+  1.1) Does
+  1.2) This:
+  1.3) This
+
+  2.1) Continues
+  2.2) All
+
+Inner Contents would be:
+  1.1.1) not need to be quoted.
+  1.2.1) does not need to be delimited.
+  1.3.1) Does:
+
+  2.1.1) until EOS/EOF.
+  2.2.1) white space, including newline (and leading white space) is "part of content."
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0005 (Somewhat Basic List)

+

+ +

+

+ This is a code"fss-0002 (Basic List)" whose Content is then processed as fss-0001 (Extended). +

+

+ All fss-0002 (Basic List) escapes are applied before any fss-0001 (Extended) is identified. +

+

+ See the fss-0001 (Extended) and fss-0002 (Basic List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-0005
+# valid comments are ignored.
+"The Object":
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  This Does\:
+Second:
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects would be:
+  1.1) Does
+  1.2) This:
+  1.3) This
+
+  2.1) Continues
+  2.2) All
+
+Inner Contents would be:
+  1.1.1) not
+  1.1.2) need
+  1.1.3) to
+  1.1.4) be
+  1.1.5) quoted.
+
+  1.2.1) does
+  1.2.2) not
+  1.2.3) need
+  1.2.4) to
+  1.2.5) be
+  1.2.6) delimited.
+
+  1.3.1) Does:
+
+  2.1.1) until
+  2.1.2) EOS/EOF.
+
+  2.2.1) white space,
+  2.2.2) including
+  2.2.3) newline
+  2.2.4) (and
+  2.2.5) leading
+  2.2.6) white space)
+  2.2.7) is
+  2.2.8) part of content.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0006 (Somewhat Extended List)

+

+ +

+

+ This is a fss-0003 (Extended List) whose Content is then processed as fss-0000 (Basic). +

+

+ All fss-0003 (Extended List) escapes are applied before any fss-0000 (Basic) is identified. +

+

+ See the fss-0000 (Basic) and fss-0003 (Extended List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-0006
+# valid comments are ignored.
+"The Object" {
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  \}
+}
+
+Second {
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+}
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects would be:
+  1.1) Does
+  1.2) This:
+  1.3) }
+
+  2.1) Continues
+  2.2) All
+
+Inner Contents would be:
+  1.1.1) not need to be quoted.
+  1.2.1) does not need to be delimited.
+  1.3.1)
+
+  2.1.1) until EOS/EOF.
+  2.2.1) white space, including newline (and leading white space) is "part of content."
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0007 (Very Extended List)

+

+ +

+

+ This is a fss-0003 (Extended List) whose Content is then processed as fss-0001 (Extended). +

+

+ All fss-0003 (Extended List) escapes are applied before any fss-0001 (Extended) is identified. +

+

+ See the fss-0001 (Extended) and fss-0003 (Extended List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-0007
+# valid comments are ignored.
+"The Object" {
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  \}
+}
+
+Second {
+  Continues until EOS/EOF.
+  All white space, including newline (and leading white space) is "part of content."
+  # Valid comments are still ignored.
+}
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects would be:
+  1.1) Does
+  1.2) This:
+  1.3) }
+
+  2.1) Continues
+  2.2) All
+
+Inner Contents would be:
+  1.1.1) not
+  1.1.2) need
+  1.1.3) to
+  1.1.4) be
+  1.1.5) quoted.
+
+  1.2.1) does
+  1.2.2) not
+  1.2.3) need
+  1.2.4) to
+  1.2.5) be
+  1.2.6) delimited.
+
+  1.3.1)
+
+  2.1.1) until
+  2.1.2) EOS/EOF.
+
+  2.2.1) white space,
+  2.2.2) including
+  2.2.3) newline
+  2.2.4) (and
+  2.2.5) leading
+  2.2.6) white space)
+  2.2.7) is
+  2.2.8) part of content.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0008 (Embedded List)

+

+ +

+

+ This is a fss-0003 (Extended List) whose Content is then recursively processed as fss-0003 (Extended List). +

+

+ See the fss-0003 (Extended List) specification for details on the syntax rules. +

+

+ Example: +

+# fss-0008
+# valid comments are ignored.
+"The Object" {
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  \}
+}
+
+Second {
+  Nested Example.
+
+  Third {
+    Fourth {
+      This is nested Content.
+    }
+  }
+}
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects (depth 1) would be:
+  2.1) Third
+
+Inner Objects (depth 2) would be:
+  2.1.1) Fourth
+
+Inner Contents (depth 0) would be:
+  1.1.1) Does not need to be quoted.
+         This: does not need to be delimited.
+         }
+
+  2.1.1) Nested Example.
+
+         Third {
+           Fourth {
+             This is nested Content.
+           }
+         }
+
+Inner Contents (depth 1) would be:
+  2.1.1.1) Fourth {
+             This is nested Content.
+           }
+
+Inner Contents (depth 2) would be:
+  2.1.1.1.1) This is nested Content.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-0009 (Reverse Mapping)

+

+ +

+

+ This is based off of fss-0000 (Basic), except the Object is at the end of the line. +

+

+ Each Object starts at the end of a line and white space to the left of the Object is not treated as part of the object. + White space separates an Object from the Content. + An Object may be preceded by a newline, in which case means that the Object has no Content. + If only printing white space precedes a valid Object, that Object is considered to have no Content. +

+

+ Content exists on the same line as the Object. + Content is represented as a single Content column that begins at a newline. + Content column consists of everything following the first non-white space character at the start of the line until the Object is reached. + Content column includes trailing white space before newline is reached. + Content column does not include any of the white space between the last non-white space character and the start of the Object. + No delimits are supported in the Content. +

+

+ Key: +

+

\s = white space, except newline.
\b = either white space or printable, except newline.
\q = non-white space or quoted white space with no white space outside of the quotes.
\n = newline.
* = zero or more occurrences.
+ = one or more occurrences.

+

+ Before Structure: +

+

+ Structure: +

+

\s*\b*\s+\q+\s*\n

+

+ After Structure: +

+

+ Example: +

+# fss-0009
+# valid comments are ignored.
+Content from newline. "The Object"
+object set. Second
+

+

+ Example Results: +

+Object would be:
+  1) The Object
+  2) Second
+
+Content would be:
+  1.1) Content from newline.
+  2.1) object set.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000A (Extended Reverse Mapping)

+

+ +

+

+ This is based off of fss-0001 (Extended), except the Object is at the end of the line. +

+

+ Each Object starts at the end of a line and white space to the left of the Object is not treated as an object. + White space separates an Object from the Content. + An Object may be followed by a newline, in which case means that the Object has no Content. + If only printing white space follows a valid Object, that Object is considered to have no Content. +

+

+ Content exists on the same line as the Object. + Content is represented as multiple Content columns. + Content columns are white space separated parts within the Content is terminated by the start of the Object. + Any number of Content columns may exist in the Content until the Object is reached. +

+

+ Key: +

+

\s = White space, except newline.
\b = Either white space or printable, except newline.
\q = Non-white space or quoted white space, no white space outside of quotes.
\n = Newline.
* = Zero or more occurrences.
+ = One or more occurrences.
()* = Grouping that repeats 0 or more times.

+

+ Before Structure: +

+

+ Structure: +

+

\s*(\s*\q+)*\s+\q+\s*\n

+

+ After Structure: +

+

+ Example: +

+# fss-000a
+# valid comments are ignored.
+Content "content 2" content_3. "The Object"
+object set. Second
+

+

+ Example Results: +

+Objects would be:
+  1) The Object
+  2) Second
+
+Contents would be:
+  1.1) Content
+  1.2) content 2
+  1.3) content_3.
+
+  2.1) object
+  2.2) set.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000B (Simple List)

+

+ +

+

+ This might be similar to fss-0008 (Embedded List), except it is an fss-0003 (Extended List) with a (non-recursive) fss-0002 (Basic List) inside the Content. +

+

+ See the fss-0002 (Basic List) and fss-0003 (Extended List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-000b
+# valid comments are ignored.
+"The Object" {
+  Does not need to be quoted.
+  This: does not need to be delimited.
+  \}
+}
+
+Second {
+  Nested Example.
+
+  Third:
+    Fourth:
+      There is parallel to Second rather than nested within Second.
+}
+

+

+ Example Results: +

+Outer Objects would be:
+  1) "The Object"
+  2) Second
+
+Inner Objects (depth 1) would be:
+  2.1) Third
+  2.2) Fourth
+
+Inner Contents (depth 0) would be:
+  1.1.1) Does not need to be quoted.
+         This: does not need to be delimited.
+         }
+
+  2.1.1) Nested Example.
+
+         Third:
+           Fourth:
+             There is parallel to Second rather than nested within Second.
+
+Inner Contents (depth 1) would be:
+  2.1.1.1)
+  2.2.1.1) There is parallel to Second rather than nested within Second.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000C (IKI Text)

+

+ +

+

+ The IKI specifications are separate specifications from the FSS. + This is simply a more formal way to designate that this format utilizes IKI syntax. +

+

+ The IKI syntax may be used in any FSS. + The IKI format may be added to the. +

+

+ See the file:"iki.txt" specification for details on the IKI specifications. +

+

+ Example: +

+# fss-000c iki-0000
+
+This is a emphasis:"formal example" utilizing the FSS headers.
+

+

+ Example: +

+# iki-0000
+
+This is an emphasis:"informal example" utilizing the IKI headers.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000D (Basic Rule)

+

+ +

+

+ This is a special case that follows fss-0002 (Basic List), and different FSS formats inside this fss-0002 (Basic List). + This fss-0002 (Basic List) is considered the "Outer List" and the Content of this Outer List is considered the "Inner Content". +

+

+ The Inner Content may be any of the following FSS formats: fss-0000 (Basic), fss-0001 (Extended), and fss-0003 (Extended List). + The way in which each format is determined is first to see if the Inner Content Object would be a valid Extended List Object. + If the Inner Content Object is not a valid fss-0003 (Extended List) Object, then check to see if it is an fss-0000 (Basic) or fss-0001 (Extended) Object. +

+

+ The fss-0000 (Basic) and fss-0001 (Extended) Objects have the same format for Object names but the fss-0003 (Extended List) Object is slightly different. + Anything that would match an fss-0003 (Extended List) Object must therefore be an fss-0003 (Extended List) Object. +

+

+ This supports the use of iki-0000 (Unrestricted) but only within the Content of the outermost fss-0002 (Basic List). + That is to say, the IKI is only processed once. + Additional restrictions on the use of IKI syntax is allowed if explicitly defined in the implementing specification. + This additional restriction may also include using a more restrictive IKI syntax, such as iki-0001 (Basic). +

+

+ Anything implementing this specification may impose its own restrictions on when to determine if the Inner Content is what FSS format, based on Object names. +

+

+ See the fss-0000 (Basic), fss-0001 (Extended), and fss-0003 (Extended List) specifications for details on the syntax rules. +

+

+ Example: +

+# fss-000d
+main:
+  name "Boot Devices"
+
+script:
+  start {
+    ip addr add 127.0.0.1/8 label lo dev lo;
+    ip link set lo up;
+  }
+
+  stop {
+    ip link set lo down;
+  }
+
+command:
+  start mount -a -O no_netdev
+  stop umount -arf -O no_netdev
+

+

+ Example Results: +

+Outer List Objects would be:
+  1) main
+  2) script
+  3) command
+
+Outer List Contents would be:
+  1.1) name "Boot Devices"
+
+  2.1) start {
+         ip addr add 127.0.0.1/8 label lo dev lo;
+         ip link set lo up;
+       }
+
+       stop {
+         ip link set lo down;
+       }
+
+  3.1) begin mount -a -O no_netdev
+       end umount -arf -O no_netdev
+
+Inner Content Objects would be:
+  1.1.1) name
+  2.1.1) start
+  2.1.2) stop
+  3.1.1) begin
+  3.1.2) end
+
+Inner Content Contents would be (without breaking Content into its individual parts):
+  1.1.1) Boot Devices
+  2.1.1) ip addr add 127.0.0.1/8 label lo dev lo;
+         ip link set lo up;
+  2.1.2) ip link set lo down;
+  3.1.1) mount -a -O no_netdev
+  3.1.2) umount -arf -O no_netdev
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000E (Payload)

+

+ +

+

+ This is a fss-0002 (Basic List) with two required objects: +

+

header.
payload.

+

+ The header: +

+

The header's Content is of type fss-0001 (Extended).
The header is recommended to have the Objects length, status, part, and total.
The recommended length represents the size of the payload.
The recommended part represents a single part of a set of packets for when the data being transmitted is split across multiple payloads.
The recommended total represents the total number of parts representing a complete data transmitted across multiple payloads.
The recommended status represents status codes (such as success or failure) and multiple.
The Content for the recommended length and status are positive whole numbers (including zero) that may be in binary, octal, decimal, duodecimal, or hexidecimal numerical format.

+

+ The payload: +

+

The payload's Content may contain anything, including raw binary data.
The payload is required to be the last list Object in the file.
The payload is recommended to have its size designated in some manner in the header (such as with the recommended length).
The payload is terminated by the EOF character or by the recommended length header.
The payload may be empty (length may be zero), but the list Object payload must still exist.
Nothing in the payload may be considered a valid list Object by the outer fss-0002 (Basic List) and therefore escaping is unnecessary (No further processing by the outer fss-0002 (Basic List) is allowed at this point).
Comments in the payload are not considered comments and are instead considered part of the payload, as-is.
Essentially, the payload should be treated as binary data embedded in a text file.

+

+ The recommended length header Object used to designate the payload size does not necessarily have to be defined in the header. + That is to say, if the payload is expected to be of some pre-defined or static length then a length does not need to be provided in the header. +

+

+ The recommended status header Object may be a string, such as F_none, or a positive whole number. + What the status code represents is application specific (or specific to a sub-standard) but may often be used to represent FLL status code. +

+

The FLL status code is a 16-bit digit whose first two high-order bits represent error and warning ( representing signal).
The FLL status code as a number is binary sensitive and may not be portable across binaries or systems.
For best portability, consider using status as a name string to ensure cross-system or cross-binary compatibility.

+

+ Example: +

+# fss-000e
+# valid comments are ignored.
+header:
+  type error
+  status 296
+  length 30
+
+payload:
+The program is out of memory.
+

+

+ Example Results: +

+Outer Objects would be:
+  1) header
+  2) payload
+
+"header" Objects would be:
+  1.1) type
+  1.2) status
+  1.3) length
+
+"header" Contents would be:
+  1.1.1) error
+  1.2.1) 296
+  1.3.1) 30
+
+The payload would be:
+  2) The program is out of memory.
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

FSS-000F (Simple Packet)

+

+ +

+

+ This is a network packet format that contains fss-000e (Payload) within it. +

+

+ The Simple Packet structure is described in blocks, of which are structured in bytes. +

+

+ There are only three blocks in this format: +

+

Control Block.
Size Block.
Payload Block.

+

+ The Control Block is the first block in the packet and is considered endianless. + There exists only a single byte within the Control Block. + Regardless of the endianness of the packet, the leftmost bit is always the string or binary bit. + The second bit following that bit represents the endianness bit. +

+

+ The string or binary bit, a value of 0 designates that the packet is in string format and a value of 1 designates that the packet is in binary format. + While the packet might be considered to be in string format, it is technically always in binary format due to the Control Block and Size Block. + This means that the bit designating the packet as a string packet or a binary packet is referring to whether or not the Payload Block is in string format or is in binary format. +

+

+ The endianness bit designates whether or not the packet is in big endian or little endian format. + A bit value of 0 designates that this packet is in little endian and a value of 1 designates that this packet is in big endian format. + All binary data within this packet, following the Control Block, must respect this endianness bit (including the Size Block). +

+

+ The remaining bits are not defined by this standard and are expected to be 0. + Non-formal or local uses may utilize these remaining 6 bits as desired. + However, there may be additional standards that expand upon this and utilize these remaining Control bits. + Anything that utilizes these unused Control bits may add or remove additional Blocks after the Control Block as they see fit. +

+

+ The Size Block is an unsigned 32-bit integer representing the size of the entire packet, including the Control Block and Size Block. + This size must exactly match the packet to be a valid packet. + The size represents number of bytes in the file. + The Control Block is 1 byte long and the Size Block is 4 bytes long and so the maximum available size is (2^32)-6. +

+

+ The Payload Block is not defined by this standard of that that it exists and should be in fss-000e (Payload) format. + The fss-000e (Payload) may be represented in either string format or binary format. + The fss-000e (Payload) may contain multiple header(s) but may only contain a single payload. + With this in mind, it is recommended that only a single header be supported in the Payload Block. +

+

+ See the fss-000e (Payload) specification for details on the syntax rules for the Payload Block. +

+

+ Example Packet Structure: +

+[ Control Block ] [ Size Block                                  ] [ Payload Block         ]
+[ 0b10000000    ] [ 0b00000000 0b00000000 0b00000100 0b11010010 ] [ size: 1229 (1234 - 5) ]
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

IKI-0000 (Unrestricted)

+

+ +

+

+ This specification provides no restrictions on the vocabulary. +

+

+ +

+

Common Specification Rules

+

+ +

+

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

+

+ 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 Object. + The variable value is considered the Content. +

+

+ 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. +

+

+ A potential IKI variable name starts on word (or _, -, +) characters. + White space and non-word (and non _, -, +) 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 (U+2010 and U+2011). +

+

+ Any valid IKI data may be escaped to make it treated as non-IKI data by prepending a backslash " before the colon code::" that is before the opening quote (single or double). +

+

+ Unicode punctuation connector characters are supported just like _, except when they connect outside the current line (such as U+FE33 ï¸³). + Unicode invisible punctuations (such as invisible plus: U+2064) are not considered a punctuations in this standard (because they a zero-width characters), therefore they are not to be considered a valid _, -, or + Unicode equivalents. +

+

+ Key: +

+

\o = any printable word character, including _, -, + (and Unicode equivalents).
\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 ' or a double quote ".
\x = any character.
\W = any non-word character, discluding _, -, + (and Unicode equivalents).
\e = an optional escape sequence of any number of backslashes, such as \.
* = 0 or more occurrences.
~ = one or more occurrences, or 0 if at start of file.

+

+ 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 emphasis:"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 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 emphasis\:"is escaped to not be treated as IKI data".
+

+

+ Example Results: +

+Objects would be:
+  1) emphasis
+  2) url
+  3) code
+
+Contents would be:
+  1.1) emphasize some text
+  2.1) http://www.example.com/url with space/
+  3.1) const char *string = "My \"quoted\" C string.";
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

IKI-0001 (Basic)

+

+ +

+

+ This specification provides a small set of vocabulary names meant to be associated with common uses, such as e-mail addresses and URLs. +

+

+ Vocabulary: +

+

address: Any mailing address, except for e-mail and URI.
code: All text contained within represent code and should be presented as such.
email: Any valid e-mail address.
phone: Any valid phone number.
quote: All text within represents some quote.
uri: Any valid URI (allows URL and URN).
url: Any valid URL.
urn: Any valid URN.
var: All text contained within represents some sort of variable.

+

+ +

+

Common Specification Rules

+

+ +

+

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

+

+ 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 Object. + The variable value is considered the Content. +

+

+ 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. +

+

+ A potential IKI variable name starts on word (or _, -, +) characters. + White space and non-word (and non _, -, +) 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 (U+2010 and U+2011). +

+

+ Any valid IKI data may be escaped to make it treated as non-IKI data by prepending a backslash " before the colon code::" that is before the opening quote (single or double). +

+

+ Unicode punctuation connector characters are supported just like _, except when they connect outside the current line (such as U+FE33 ï¸³). + Unicode invisible punctuations (such as invisible plus: U+2064) are not considered a punctuations in this standard (because they a zero-width characters), therefore they are not to be considered a valid _, -, or + Unicode equivalents. +

+

+ Key: +

+

\o = any printable word character, including _, -, + (and Unicode equivalents).
\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 ' or a double quote ".
\x = any character.
\W = any non-word character, discluding _, -, + (and Unicode equivalents).
\e = an optional escape sequence of any number of backslashes, such as \.
* = 0 or more occurrences.
~ = one or more occurrences, or 0 if at start of file.

+

+ Before Structure: +

+

\x*\W~\*:*

+

+ Structure: +

+

\o\e:\q\c\q

+

+ After Structure: +

+

+ Example File: +

+# fss-000c iki-0001
+
+This is my sentence, anything can go here but sometimes I want to emphasis:"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 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 emphasis\:"is escaped to not be treated as IKI data".
+

+

+ Example Results: +

+Objects would be:
+  1) emphasis
+  2) url
+  3) code
+
+Contents would be:
+  1.1) emphasize some text
+  2.1) http://www.example.com/url with space/
+  3.1) const char *string = "My \"quoted\" C string.";
+

+

+ +

+

Featureless Linux Library Specification

+

+ +

+

IKI-0002 (Simple Script)

+

+ +

+

+ This specification provides a small set of vocabulary names meant to be used for substitution in simple scripts. +

+

+ This specification only loosely defines the vocabulary context. + This vocabulary may be further extended but must at least support the taxonomy defined here. + Flexibility on interpretation is intended so that the context can be more fine-tuned and customized. +

+

+ The taxonomy for the emphasis:"context", emphasis:"define", and emphasis:"parameter" are intentionally not defined here and left open. + One utilizing this should document the taxonomy for each of these as desired. +

+

+ Vocabulary: +

+

context: Intended to be used for printing (or tagging) context codes before and after text, such as with color context.
define: Intended to be used for global properties, much like a C/C++ #define.
parameter: Intended to be used for parameters or variables.

+

+ +

+

Common Specification Rules

+

+ +

+

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

+

+ 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 Object. + The variable value is considered the Content. +

+

+ 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. +

+

+ A potential IKI variable name starts on word (or _, -, +) characters. + White space and non-word (and non _, -, +) 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 (U+2010 and U+2011). +

+

+ Any valid IKI data may be escaped to make it treated as non-IKI data by prepending a backslash " before the colon code::" that is before the opening quote (single or double). +

+

+ Unicode punctuation connector characters are supported just like _, except when they connect outside the current line (such as U+FE33 ï¸³). + Unicode invisible punctuations (such as invisible plus: U+2064) are not considered a punctuations in this standard (because they a zero-width characters), therefore they are not to be considered a valid _, -, or + Unicode equivalents. +

+

+ Key: +

+

\o = any printable word character, including _, -, + (and Unicode equivalents).
\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 ' or a double quote ".
\x = any character.
\W = any non-word character, discluding _, -, + (and Unicode equivalents).
\e = an optional escape sequence of any number of backslashes, such as \.
* = 0 or more occurrences.
~ = one or more occurrences, or 0 if at start of file.

+

+ 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 emphasis:"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 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 emphasis\:"is escaped to not be treated as IKI data".
+

+

+ Example Results: +

+Objects would be:
+  1) emphasis
+  2) url
+  3) code
+
+Contents would be:
+  1.1) emphasize some text
+  2.1) http://www.example.com/url with space/
+  3.1) const char *string = "My \"quoted\" C string.";
+

+

+ +

+

2022 / 05 / 16 - FLL Specifications Added

+

+ +

+

+ Updated the FLL specifications and made them available on the website. +

+

+ Basic styling is applied to make the specifications reasonably readable on a website. I avoided doing any complicated designs so that I can focus on other tasks (such as making a stable release). I took a shortcut on the example results by using the <pre> tag. +

+

+ Only the main FLL specification pages are updated. The specifications (or links to specifications) on the programs pages have not been updated. There is still quite a lot to do in regards to documenting the programs. +

+

+ Several mistakes on the website, such as incorrect canonical addresses, are now fixed. +

+

+ I have also added an informal definition of my Completeness Theorem that I always used for just about all of my personal work. This has been in use by the FLL since I first started working on it. I believe that I just never formally (or informally) wrote down my theory (I believe that the concepts for this were touched on in my thesis). +

+

+ Kevin Day +

+