Featureless Settings Specification: 000e - Payload:
This is a "FSS-0002 (Basic List)" with two required objects\:
- 1) header.
- 2) payload.
+ 1) "header".
+ 2) "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 "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 "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 "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.
+ 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 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.
#
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 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".
+ - 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.
+ - 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.
+ 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.
+ - 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.
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.
+ 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.
+ 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.
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.
+ 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'.
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.
+ 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.
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.
+ 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:"#" character) as there is no terminating character for a comment (other than a newline "\n").
+ 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:'#" 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.
+ 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).
+ 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.
+ 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.
+ 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.
+ 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).
+ 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.
+ 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.
+ 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-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
projects / kevux.org-website / commitdiff