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):