# fss-0002 iki-0000
#
# license open-standard-license-1.0-or-later
# version 2024/01/15
#
# This file (assumed to be named fss.txt) can be more easily read using the following iki_read commands:
#   iki_read fss.txt +Q -w -rrrrrrrr anti-KISS anti-KISS ASCII ASCII BOM BOM FSS FSS KISS KISS UTF-8 UTF-8 URL URL XML XML -WWW character "'" "'" code '"' '"' italic '"' '"'
#
# Individual sections in this file may be parsed using fss_basic_list_read command and then passed to the iki_read command.
# To read the "Featureless Settings Specifications" section of this file, use this command sequence:
#   fss_basic_list_read fss.txt +Q -cn "Featureless Settings Specifications" | iki_read +Q -w -rrrrrrrr anti-KISS anti-KISS ASCII ASCII BOM BOM FSS FSS KISS KISS UTF-8 UTF-8 URL URL XML XML -WWW character "'" "'" code '"' '"' italic '"' '"'
#

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

  The FSS:"Featureless Settings Specifications" defines the following\:
  - Will consist of numerous different kinds of specification files, depending on the type of information stored.
  - As with the practice of code:"#!/bin/bash", the setting files italic:"should" have the following: code:"# fss-????" format, such as "# fss-0001".
  - Multiple sub-standards may be appended to the FSS:"Featureless Settings Specifications" header, using the same format structure, such as supporting IKI: "# fss-0000 iki-0000" or HTML5: "# fss-0000 html-0005".
  - With the character:"?" representing the (hexadecimal/base-16) number that represents the particular specification structure.
  - All settings specifications italic:"should" avoid any form of noise, relative to the data being stored.
  - XML:"Extensible Markup Language" would be considered anti-KISS:"Anti Keep It Simple Stupid" due to the extreme level of noise generated by the XML:"Extensible Markup Language" 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:"Featureless Settings Specifications" consists of two main parts: an italic:"Object" and the italic:"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 italic:"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 code:"FSS-0000 (Basic)", Content is treated as a single item whereas in code:"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 italic:"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 code:"FSS-000 (Basic)" the entire Content may be further represented as a single column.
  For example, in code:"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 (character:"\n" only).
  Newline characters are only character:"\n" and are never anything else (character:"\r" is not considered newline in any manner).
  These specifications refer to characters that have printable representation as italic:"printable".
  These specifications refer to characters that have no printable representation as italic:"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 code:"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 a single quote character:"'" (unicode:"U+0027"), a double quote character:'"' (unicode:"U+0022"), or a grave character:'`' (unicode:"U+0060") and only a backslash character:"\\" (unicode:"U+005C") may be used as a delimiter.
  For example, code:"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, code:"FSS-0001 (Extended)" needs quotes to group parts that include spaces, if there is no initial quote, then a quote following the data italic:"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:"Unicode Transformation Format 8-bit"; 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:"American Standard Code for Information Interchange" and Unicode support.

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

  Unless otherwise specified, all designation characters italic:"must" represent ASCII:"American Standard Code for Information Interchange" codes.
  With designation characters being any character code used to designate how to identify an Object or Content (such as a colon character:":" at the end of a basic list).
  This keeps the processing and logic simple and safe, for both UTF-8:"Unicode Transformation Format 8-bit" and ASCII:"American Standard Code for Information Interchange".
  White space used for designation characters italic:"must" include support for UTF-8:"Unicode Transformation Format 8-bit" 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 unicode:"U+1680" character:" ") 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 italic:"invisible plus" character (unicode:"U+2064") is not to be considered as a plus.

  The UTF-8:"Unicode Transformation Format 8-bit" BOM:"Byte Order Mark" 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:"Byte Order Mark" by a standard).

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

  In any specification where security is intended, if there exists a Unicode character that matches an ASCII:"American Standard Code for Information Interchange" character, that Unicode character italic:"may" be prohibited by that standard in favor of the ASCII:"American Standard Code for Information Interchange" equivalent.
  One such example is in the case of a URL:"Uniform Resource Locator", where the name could be used to trick a person (url:"http://this-site.com/" vs url:"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 italic:"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
