Welcome to the sINI specification page.
The specifications laid out here seek to define an easy-edit / easy-parse format, generally compatible with the current existing INI format(s). This format is baptized sINI.
As there is no definitive specification for the general INI format and its implementations, sINI is not intended to be explicitly compatible with any, although in most cases, a basic INI parser will understand sINI0 (the base version), and vice versa.
The purpose of sINI is to provide a fixed, standardized and extended parametric configuration file format. It is intended to be easy to write parsing code for, and easy for a human to read and edit.
As of 2009-06-13 I have written parsers for both PHP and Python. They are decently commented so that anyone can follow what the code is doing and extend it.
The files themselves are under a Creative Commons Attribution-Share Alike license. I would ask thus anyone who wants to make improvements on the specs to use the D-versioning convention: marking derivative personnal specifications to avoid version clashes and later confusion.
For example, a sINI identifier of ;sINId1-Larry would tell the world that the format of the file is an improved version of sINI1 with extra features.
;sINId1-Larry parsers would thus be known to parse sINI1 correctly, along with its own features, whereas plain sINI1 parsers would safely reject ;sINId1-Larry formatted files.
For my part, the next version of sINI will be sINId1-ducake2 - an experimental version before comitting it as sINI2 :-)
This is to avoid version clashes, confusion, and more importantly a safeguard against permanently introducing features that are "bad".
And, at the risk of sounding pretentious: if you want to "canoncise" your own version, just let me know, and I'll be happy to trumpet your name in big letters to a new version of sINI!
The idea for sINI was two-fold: firstly, I was tired of seeing XML becoming the de facto standard for configuration files, introducing complexity where complexity was not needed; and secondly, I wanted a more linear format, with no look-back (for example, in XML you will have an explicitroot tag, for example <rootTag> and at the end you would see </rootTag> - a bit redundant, no? Also hell if you're trying to simply append data).
The base version, sINI0, is intended to be pretty much compatible with the normal INI "consensus". The newer, sINI1 has a multiline feature I wanted to add for a note-keeper project I was writing at the time. I did not want to go back to XML 1) for its complexity and redundant tags, and also because I could write to my files in append mode - and still keep structure.
I set out initially to create a more complex format - "Structured Records Format" - with features such as lists (INI configurations on steriods), columns (using header instead of key-value pairing), tables (combined list and columns), and trees (a bastardized tree-structure pulling concepts from Python, XML and Lisp) but I slowly realized that this was alot of wheel re-invention: given time, it would actually turn into a cross between XML and CSV...!
I came back to the initial idea of lists and decided that, instead of innovating a format, I would re-visit an old one: the humble INI file format.
There was a problem here though: each implementation had its own set of loosely defined rules, and there was no proper consensus on what features an INI parser should and shouldn't support. So.... I decided to define my own type of INI, the base version, and spruce it up with additional features.
Ta daa!