Name: SKON
Owner: SpaceKrakens
Description: Space Kraken Object Notation - An alternative serialization language
Created: 2016-09-04 15:43:12.0
Updated: 2018-01-04 22:18:09.0
Pushed: 2017-02-14 19:04:32.0
Size: 85
Language: ANTLR
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Space Kraken Object Notation - https://github.com/SpaceKrakens/SKON
Is a language originally created to accommodate the data format language need for Project Porcupine.
Its main focus is besting all other object notation languages. No more need for 90% filler in xml, the unreadable "s in Json or the overly complex superset of JSON; YAML.
It's also notable that it has a schema language, SKEMA! So you don't have to just blindly trust the user. :octopus:
You can find the SKON Spec here and the SKEMA Spec here.
The following is an example showing the syntax of the language:
ON supports comments!
nd multiline ones too! :D */
sion: 1~ // This is the SKON version header.
very SKON file is considered a map so everything is stored in key-value pairs.
his is a value in the root map. The key is "RootKey" and it stores a string value "RootValue".
Key: "RootValue",
his is a map inside the root map, it stores data in key-value pairs.
ey: {
StringKey: "StringValue", // N.B.! In SKON every key value ends with a comma!! Even if it's the last one!!
// SKON has support for different data types!
IntKey: 1,
DoubleKey: 1.1,
BoolKey: true,
DateTimeKey: @2016-10-05, //N.B. You can read more about DateTimes in SKON below!
// In addition to maps SKON also has arrays!
StringArrayKey: [ "This", "is", "a", "string", "array!", ], // N.B. Note the comma after the last string!
// And of course nested maps in maps work, as expected!
NestedMap:
{
ANestedValueKey: "This is a nested value",
},
The schema language for SKON is called SKEMA. The following is an example of a SKEMA file and a maching SKON file.
sion: 1~
KEMA also supports comments!
efines a structure "Color" containing a string "Name" and int "Color"
Color:
Name: string,
Color: int,
efines that an array called Colors needs to exits
nd that the all the elements most conform to the Color definition.
rs: [ #Color ],
A quick SKON file that is valid for this SKEMA could look like this:
sion: 1~
MA: "./Colors.skema"~
rs:
{ Name: "Red", Color: 0xFF0000, },
{ Name: "Green", Color: 0x00FF00, },
{ Name: "Blue", Color: 0x0000FF, },
The language has a eight built in data types that allows data to be easily represented.
The built in types are devided into two categories, Simple types and Complex types.
The following is a list of the eight types in their respective category.
In SKON most simple data is represented in plain text with no additional syntax.
The exceptions to this is Strings, which are quoted and DateTimes wich start with an @.
Here are a few examples:
0 is an Integer."example" is a String.0.2 is a Double.true is a Boolean.@2016-01-01 is a DateTimeThe two complex types just enclose data with either braces or brackets.
Arrays are written as data surrounded by brackets with every entry separated by a comma.
An array can contain any data type if not otherwise stated in a SKEMA.
"This",
"is",
"an",
"array",
"of",
"strings",
A map is written as any number of key value pairs followed by a comma surrounded in curly braces.
A key value pair is written as such:
key: value
Where the key is plain text and the value is any data type.
So a map would then look like this:
Key1: value1,
Key2: value2,
Every file In SKON is a map, so all elements in root has to be a key value pair.
This is what a file containing a string and map would look like:
: "SomeName",
{
SomeKey: "SomeValue",
There are numerous ways to write date and time in SKON, most of which are based upon RFC 3339/ISO 8601. Additionally to this standard, SKON supports UNIX Timestamps.
Times:
@1, // These two values are valid UNIX Timestamps.
@1473113744,
@2310-12-01, // Just the date in the YYYY-MM-DD format.
@2310-12-01T13:37:01Z, // Date and additionally time in the HH:mm:ssZ format.
// Z stands for Zulu and means no difference from UTC.
// Date and time are always separated by a T (for time).
@2310-12-01T13:37:01.02Z, // Date and additionally time in the HH:mm:ss.SECFRACZ format.
// SECFRAC is a fraction of a second. Technically SKON gives
// you no limit but we advise to stay reasonable.
@2310-12-01T13:37:01+09:00, // To specify a different offset than UTC+0, substitute Z with
// either +HH:MM or -HH:MM.
@2310-12-01T13:37:01.002+09:00, // This obviously also works with fractions of seconds.
@13:37:01Z, // You can also write times alone by obmitting the date
@13:37:01.02Z, // part and the date/time separator T.
@13:37:01+09:00, // All four different formats for times are supported.
@13:37:01.002+09:00,