├── dataformats.png ├── .github └── FUNDING.yml ├── Revisions.md ├── LICENSE ├── FAQ.md ├── Implementation.md ├── README.md └── SPEC.md /dataformats.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/NaturalIntelligence/nimn-spec/HEAD/dataformats.png -------------------------------------------------------------------------------- /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | github: NaturalIntelligence 4 | # open_collective: fast-xml-parser 5 | custom: ["https://paypal.me/naturalintelligence"] 6 | 7 | # ko_fi: # Replace with a single Ko-fi username 8 | # tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel 9 | # community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry 10 | # liberapay: # Replace with a single Liberapay username 11 | # issuehunt: # Replace with a single IssueHunt username 12 | # otechie: # Replace with a single Otechie username 13 | # custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2'] 14 | -------------------------------------------------------------------------------- /Revisions.md: -------------------------------------------------------------------------------- 1 | # Revisions 2 | This file is contains revision history with appropriate reason and detail of revision. 3 | 4 | ### Revision 3 / 22 Jun 2018 5 | 6 | #### Addition 7 | 8 | * Updated range is ASCII [175 - 188]. 9 | * Add Field-name-separator character (ASCII 188) to support dynamic maps. 10 | 11 | #### Update 12 | 13 | * Improve the detail of serialization and deserialization process. 14 | 15 | ### Revision 2 / 06 Jun 2018 16 | 17 | #### Addition 18 | 19 | * Update Nimn supported characters in continuous range to speed up the processing. Updated range is ASCII [175 - 187]. 20 | * Add Object-End character (ASCII 180) to increase redability, formatting without specification, and little more flexibility when new fields are added to the schema. 21 | 22 | #### Update 23 | 24 | * Improve the detail of serialization and deserialization process. 25 | 26 | ### Revision 1 / 06 Apr 2018 27 | 28 | * Initial schema design is drafted to register the mime type and to let people use the common specification in all the implementation. 29 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 Amit Kumar Gupta 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | If you use this library in a public repository then you give us the right to mention your company name and logo in user's list without further permission required, but you can request them to be taken down within 30 days. 13 | 14 | The above copyright notice and this permission notice shall be included in all 15 | copies or substantial portions of the Software. 16 | 17 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 18 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 19 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 20 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 21 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 22 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 23 | SOFTWARE. 24 | -------------------------------------------------------------------------------- /FAQ.md: -------------------------------------------------------------------------------- 1 | # FAQ 2 | 3 | 4 | ## Q: Does it speed up an application? 5 | Ans: The aim of nimn data format is to reduce the size of data. Processing the data or whether it can improve the performance depend on implementation. However as you have the data structure in advance, it's processing can be faster. 6 | 7 | ## Q: What if I compress JSON instead parsing it to Nimn data format? 8 | Ans: The size of Nimn data is smaller than compressed JSON. 9 | 10 | ## Q: I can't ensure the order of fields in data. Can I still use Nimn format? 11 | Ans: You need to maintain the order of keys in schema. Fields in original data can be jumbled. 12 | 13 | ## Q: My data is dynamic in nature. How can I use Nimn format? 14 | Ans. You'll have find the correct way to make it structured to use Nimn format. 15 | 16 | ## Q: Why does not it support premitive type? 17 | Ans: Premitive data are just values. They don't have any object structure. Hence there is no benefit you'll get them if supported by Nimn format. 18 | 19 | ## Q: Can I use non-English characters? 20 | Ans: Yes. Nimn is basically about data format not the data. 21 | 22 | ## Q: Is it secure? 23 | Ans: Nimn in itself doesn't apply any security mechanism. You either can encrypt particular field's data or the whole data after parsing to Nimn format. 24 | 25 | ## Q: I'm adding some fields in server response but I don't want to update client right now. Would it still work with 2 different schemas? 26 | Ans. Yes. Don't change the order of fields defined in server response schema. Add the extra fields in last. In this case, client schema should automatically ignore extra fields. 27 | 28 | ## Q: I have 2 different schemas at client side and server side which differ in terms of field's name and their values. Will it work? 29 | 30 | Server 31 | ```json 32 | { 33 | "name" : "string", 34 | "dob" : "string", 35 | "isRegistered" : "boolean", 36 | } 37 | ``` 38 | 39 | Client 40 | ```json 41 | { 42 | "dob" : "string", 43 | "name" : "string", 44 | "registered" : "boolean" 45 | } 46 | ``` 47 | 48 | Ans: Above example will not give any error at the time of deserialization but you'll end up with unexpected result. Eg 49 | 50 | Data to serialize 51 | ```json 52 | { 53 | "name" : "Amit gupta", 54 | "dob" : "some date", 55 | "isRegistered" : true 56 | } 57 | ``` 58 | 59 | Data after deserialization 60 | ```json 61 | { 62 | "dob" : "Amit gupta", 63 | "name" : "some date", 64 | "registered" : true 65 | } 66 | ``` 67 | -------------------------------------------------------------------------------- /Implementation.md: -------------------------------------------------------------------------------- 1 | Here is an example which can help to implement nimn data format serializer and deserializer in various programming languages. 2 | 3 | ```js 4 | var schema = { 5 | type : "list", 6 | detail : { 7 | type : "map", 8 | detail : [{ 9 | name : "name", 10 | type : "string" 11 | },{ 12 | name : "age", 13 | type : "number" 14 | },{ 15 | name : "isHuman", 16 | type : "boolean" 17 | },{ 18 | name : "address", 19 | type : "string" 20 | },{ 21 | name : "hobbies", 22 | type : "list", 23 | detail : { 24 | type : "string" 25 | } 26 | },{ 27 | name : "project", 28 | type : "map", 29 | detail: [{ 30 | name: "title", 31 | type : "string" 32 | },{ 33 | name: "description", 34 | type : "string" 35 | },{ 36 | name: "status", 37 | type : "string" 38 | } 39 | ] 40 | } 41 | ] 42 | } 43 | } 44 | 45 | var jsObject = [{ 46 | "name" : "somename", 47 | "isHuman" : true, 48 | "age": 32, 49 | "address" : "I'll not tell you", 50 | hobbies : [ 51 | null 52 | , "not reading "+ parser.chars.missingPremitive +" book" 53 | , "watching \\"+ parser.chars.nilPremitive +" movie" 54 | ], 55 | project : { 56 | title : "nimn", 57 | //description : "it is 80% smaller", 58 | status : "rocking" 59 | } 60 | },{ 61 | 62 | } 63 | ]; 64 | 65 | var nimnData = parser.chars.arrStart 66 | + parser.chars.objStart 67 | + "somename" + parser.chars.boundaryChar 68 | + "32" 69 | + parser.chars.yes // Order of the keys should be maintained as per schema not the data 70 | + "I'll not tell you" 71 | + parser.chars.arrStart 72 | + parser.chars.nilPremitive 73 | + "not reading \\"+ parser.chars.missingPremitive +" book" + parser.chars.boundaryChar 74 | + "watching \\\\"+ parser.chars.nilPremitive +" movie" 75 | + parser.chars.arrEnd 76 | + parser.chars.objStart 77 | + "nimn" //No boundary char if next field is nimn char 78 | + parser.chars.missingPremitive 79 | + "rocking" //last field can not have boundary char 80 | + parser.chars.objEnd 81 | + parser.chars.objEnd 82 | + parser.chars.emptyChar 83 | + parser.chars.arrEnd; 84 | ``` 85 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # निम्न (Nimn) 2 | 3 | You'll find an overview of Nimn format on this page. Please read [Specification](/SPEC.md) for more detail. Or visit [site]([https://amitkumargupta.work/nimn/](https://github.com/NaturalIntelligence/nimn-spec)) to try yourself how much data it can save. 4 | 5 | > Version 2 is in mind. Need time to develope it 6 | 7 | ## About 8 | > Nimn (निम्न) word is taken from Sanskrit language which means *very less*. 9 | 10 | When we communicate between servers or clients, half of the bandwidth is utilized by metadata. *Nimn data is dense form of data where field level information is kept separate from actual data.* In brief, it can be understood as **schema aware compressed** form. 11 | 12 | Initial version of Nimn data format was very much similar to Avro. However, to speed up the processing there are some changed done. The aim of Nimn data format is fast encoding, decoding, and search in data. No encoding technique is applied on field's value but it's structure to speed up searching. Hence encoded message has more bytes than Protobuf, Thrift, or Avro. However difference is not minimal. You can use addons for field level compression which will reduce the size further but you'll have to compromise with searching speed. 13 | 14 | ## Benefits and loss 15 | 16 | ### Benefits 17 | 18 | * Size of the data is reduced by more than 80% in comparison of XML. Hence less disk space and network bandwidth is required. 19 | * Defined schema can speed up processing of data. 20 | 21 | ### Loss 22 | 23 | * Updating schema everytime you change object structure. 24 | * Maintaining schema definition when you want to support all older versions of data structure. 25 | * Readability 26 | 27 | ### MIME type 28 | 29 | [application/vnd.nimn](https://www.iana.org/assignments/media-types/application/vnd.nimn) , application/nimn 30 | 31 | ### Comparision with other forms of data representation 32 | 33 | ![comparision of data formats](dataformats.png) 34 | 35 | #### XML (806 bytes) 36 | ```xml 37 | 38 | 39 | +122233344550 40 | Jack 41 | +122233344551 42 | 33 43 | Yes 44 | Wed, 28 Mar 1979 12:13:14 +0300 45 |
46 | New York 47 | Park Ave 48 | 1 49 | 1 50 |
51 |
52 | Boston 53 | Centre St 54 | 33 55 | 24 56 |
57 | 58 | 59 | +122233344553 60 | Boris 61 | +122233344554 62 | 34 63 | Yes 64 | Mon, 31 Aug 1970 02:03:04 +0300 65 |
66 | Moscow 67 | Kahovka 68 | 1 69 | 2 70 |
71 |
72 | Tula 73 | Lenina 74 | 3 75 | 78 76 |
77 | 78 | 79 | ``` 80 | 81 | #### JSON (580 bytes) 82 | ```json 83 | { 84 | "any_name": { 85 | "person": [ 86 | { 87 | "phone": [ 88 | 122233344550, 89 | 122233344551 90 | ], 91 | "name": "Jack", 92 | "age": 33, 93 | "married": "Yes", 94 | "birthday": "Wed, 28 Mar 1979 12:13:14 +0300", 95 | "address": [ 96 | { 97 | "city": "New York", 98 | "street": "Park Ave", 99 | "buildingNo": 1, 100 | "flatNo": 1 101 | }, 102 | { 103 | "city": "Boston", 104 | "street": "Centre St", 105 | "buildingNo": 33, 106 | "flatNo": 24 107 | } 108 | ] 109 | }, 110 | { 111 | "phone": [ 112 | 122233344553, 113 | 122233344554 114 | ], 115 | "name": "Boris", 116 | "age": 34, 117 | "married": "Yes", 118 | "birthday": "Mon, 31 Aug 1970 02:03:04 +0300", 119 | "address": [ 120 | { 121 | "city": "Moscow", 122 | "street": "Kahovka", 123 | "buildingNo": 1, 124 | "flatNo": 2 125 | }, 126 | { 127 | "city": "Tula", 128 | "street": "Lenina", 129 | "buildingNo": 3, 130 | "flatNo": 78 131 | } 132 | ] 133 | } 134 | ] 135 | } 136 | } 137 | ``` 138 | 139 | #### MESSAGE PACK (426 bytes) 140 | ``` 141 | 81 a8 61 6e 79 5f 6e 61 6d 65 81 a6 70 65 72 73 6f 6e 92 86 a5 70 68 6f 6e 65 92 cf 00 00 00 1c 75 ac d2 26 cf 00 00 00 1c 75 ac d2 27 a4 6e 61 6d 65 a4 4a 61 63 6b a3 61 67 65 21 a7 6d 61 72 72 69 65 64 a3 59 65 73 a8 62 69 72 74 68 64 61 79 bf 57 65 64 2c 20 32 38 20 4d 61 72 20 31 39 37 39 20 31 32 3a 31 33 3a 31 34 20 2b 30 33 30 30 a7 61 64 64 72 65 73 73 92 84 a4 63 69 74 79 a8 4e 65 77 20 59 6f 72 6b a6 73 74 72 65 65 74 a8 50 61 72 6b 20 41 76 65 aa 62 75 69 6c 64 69 6e 67 4e 6f 01 a6 66 6c 61 74 4e 6f 01 84 a4 63 69 74 79 a6 42 6f 73 74 6f 6e a6 73 74 72 65 65 74 a9 43 65 6e 74 72 65 20 53 74 aa 62 75 69 6c 64 69 6e 67 4e 6f 21 a6 66 6c 61 74 4e 6f 18 86 a5 70 68 6f 6e 65 92 cf 00 00 00 1c 75 ac d2 29 cf 00 00 00 1c 75 ac d2 2a a4 6e 61 6d 65 a5 42 6f 72 69 73 a3 61 67 65 22 a7 6d 61 72 72 69 65 64 a3 59 65 73 a8 62 69 72 74 68 64 61 79 bf 4d 6f 6e 2c 20 33 31 20 41 75 67 20 31 39 37 30 20 30 32 3a 30 33 3a 30 34 20 2b 30 33 30 30 a7 61 64 64 72 65 73 73 92 84 a4 63 69 74 79 a6 4d 6f 73 63 6f 77 a6 73 74 72 65 65 74 a7 4b 61 68 6f 76 6b 61 aa 62 75 69 6c 64 69 6e 67 4e 6f 01 a6 66 6c 61 74 4e 6f 02 84 a4 63 69 74 79 a4 54 75 6c 61 a6 73 74 72 65 65 74 a6 4c 65 6e 69 6e 61 aa 62 75 69 6c 64 69 6e 67 4e 6f 03 a6 66 6c 61 74 4e 6f 4e 142 | ``` 143 | or 144 | ``` 145 | ��any_name��person���phone��u��&�u��'�name�Jack�age!�married�Yes�birthday�Wed, 28 Mar 1979 12:13:14 +0300�address���city�New York�street�Park Ave�buildingNo�flatNo��city�Boston�street�Centre St�buildingNo!�flatNo��phone��u��)�u��*�name�Boris�age"�married�Yes�birthday�Mon, 31 Aug 1970 02:03:04 +0300�address���city�Moscow�street�Kahovka�buildingNo�flatNo��city�Tula�street�Lenina�buildingNo�flatNoN 146 | ``` 147 | #### NIMN (232 bytes) 148 | ``` 149 | ÆÆÇÆÇ122233344550º122233344551ÅJackº33ºYesºWed, 28 Mar 1979 12:13:14 +0300ÇÆNew YorkºPark Aveº1º1ÆBostonºCentre Stº33º24ÅÆÇ122233344553º122233344554ÅBorisº34ºYesºMon, 31 Aug 1970 02:03:04 +0300ÇÆMoscowºKahovkaº1º2ÆTulaºLeninaº3º78ÅÅ 150 | ``` 151 | #### NIMN with date compression (190 bytes) 152 | ``` 153 | ÆÆÇÆÇ122233344550º122233344551ÅJackº33ºYesºOMs9demÇÆNew YorkºPark Aveº1º1ÆBostonºCentre Stº33º24ÅÆÇ122233344553º122233344554ÅBorisº34ºYesºFaun34mÇÆMoscowºKahovkaº1º2ÆTulaºLeninaº3º78ÅÅ 154 | ``` 155 | or 156 | ``` 157 | �����122233344550�122233344551�Jack�33�Yes�OMs9dem��New York�Park Ave�1�1�Boston�Centre St�33�24���122233344553�122233344554�Boris�34�Yes�Faun34m��Moscow�Kahovka�1�2�Tula�Lenina�3�78�� 158 | ``` 159 | 160 | ## Contribution 161 | We need your expert advice, and contribution to grow nimn (निम्न) so that it can support all major languages. Please join the [us](https://github.com/NaturalIntelligence) on github to support it. And ask your friends, and colleagues to give it a try. It can not only save bandwidth but speed up communication, search and much more. 162 | 163 | ## Implementations 164 | 165 | Please refer following implementations in various languages 166 | 167 | * [Node / Java Script](https://github.com/NaturalIntelligence/nimnjs) 168 | -------------------------------------------------------------------------------- /SPEC.md: -------------------------------------------------------------------------------- 1 | # निम्न (Nimn) Specification 2 | Working copy of Nimn data format specification. 3 | 4 | ## Table of contents 5 | * [Introduction](https://github.com/nimndata/spec/blob/master/SPEC.md#introduction) 6 | * [Conventions Used in This Document](https://github.com/nimndata/spec/blob/master/SPEC.md#conventions-used-in-this-document) 7 | * [Grammar](https://github.com/nimndata/spec/blob/master/SPEC.md#grammar) 8 | * [Boundary characters](https://github.com/nimndata/spec/blob/master/SPEC.md#boundary-characters) 9 | * [Fixed value characters](https://github.com/nimndata/spec/blob/master/SPEC.md#fixed-value-characters) 10 | * [Values](https://github.com/nimndata/spec/blob/master/SPEC.md#values) 11 | * [Parser](https://github.com/nimndata/spec/blob/master/SPEC.md#parser) 12 | * [IANA considerations](https://github.com/nimndata/spec/blob/master/SPEC.md#iana-considerations) 13 | * [Customization / Extension](https://github.com/nimndata/spec/blob/master/SPEC.md#customization) 14 | 15 | 16 | ## Introduction 17 | Nimn is an object serialization specification like JSON. 18 | 19 | It represents more dense form of data. And can also be known as `Schema Aware Data Format` or `Schema Less Data` 20 | 21 | Nimn format can represent structured types (objects and arrays) having structured or primitive types (strings, numbers, booleans, and null), with data, missing (undefined), and empty values ([], {}, ""). 22 | 23 | An object (collection of zero or more name/value pairs) serialized in Nimn format doesn't contain keys. Hence the order of values is important. Information of keys, called schema or the structure of the object, can be maintained separately and it is required at the time of deserialization. Any change in order or type of keys may result error or invalid application object. 24 | 25 | Example: 26 | 27 | **Application Object** 28 | 29 | ```js 30 | { 31 | "name" : "Some Name [nick name]", 32 | "age" : 33, 33 | "address" : "Some long address" 34 | } 35 | ``` 36 | 37 | **Nimn Data** 38 | ``` 39 | {Some Name \[nick name\]|33|Some long address} 40 | ``` 41 | 42 | *Note* : Characters `{` , `[`, `]`, `|`, `}` in above Nimn data are used to represent ASCII char 182 , 187, 185, 179, and 180 respectively. Check [boundary characters](https://github.com/nimndata/spec/blob/master/SPEC.md#boundary-characters) for more detail. 43 | 44 | ## Conventions Used in This Document 45 | 46 | * *schema* : It defines the structure of *ordered* key/type pairs where the key defines the name of the field and type can be either primitive: string, boolean, number (custom types are not the part of this specification), or array (list of single type either premitive or schema), or another schema. 47 | 48 | Example: 49 | 50 | ```js 51 | { 52 | "name" : "string", 53 | "age" : "number", 54 | "address" : "string", 55 | "hobbies" : ["string"], 56 | "projects" : { 57 | "title" : "string", 58 | "description" : "string" 59 | } 60 | } 61 | ``` 62 | 63 | * *array* : Array represents the list of similar type of elements. 64 | * *object* : Object represents an instance of the schema given above. It should not contain any key which is not defined in the schema. But schema may have some keys which are missing in object. 65 | * *Dynamic value fields* : Dynamic value fields are the fields which can have any value like string, number, etc. 66 | * *Fixed value fields* : Fixed value fields are the fields which have fixed set of values like boolean. (or like Enum in Java) 67 | 68 | ## Grammar 69 | 70 | Nimn data is the sequence of data values, boundary characters, and fixed value characters (used instead of actual data values). If data value consist any boundary or fixed value character then it should be backslashed. 71 | 72 | Example 73 | 74 | *Application Object* 75 | ```js 76 | [ 77 | { 78 | "name" : "Some Name [nick name]", 79 | "age" : 33, 80 | "address" : "Some long address" 81 | }, 82 | { 83 | "name" : "Some Name", 84 | "age" : 35, 85 | "address" : "A-3:34 Some long address" 86 | } 87 | ] 88 | ``` 89 | *Nimn Format* 90 | ``` 91 | [{Some Name \[nick name\]|33|Some long address}{Some Name|35|A-3:34 Some long address}] 92 | ``` 93 | *Note* : Characters `{` , `[`, `]`, `|`, `}` in above Nimn data are used to represent ASCII char 182 , 187, 185, 179, and 180 repectively. 94 | 95 | ### Boundary characters 96 | 97 | * **Object start** : ASCII char 182 98 | * **Object end** : ASCII char 180 99 | * **Array start** : ASCII char 187 100 | * **Array end** : ASCII char 185 101 | * **Dynamic Value separator** : ASCII char 179 102 | 103 | Unlike enum, and boolean there can be fields like String, Number, Date and other which can have any dynamic values. Dynamic value separator is required to define the boundary of the value. 104 | 105 | Check [Serialization](#serialization) section for more detail 106 | 107 | * **Field Name separator** : ASCII char 188 108 | 109 | Many programming languages, like Java, supports maps where key name is not known in advance. These maps can be considered as special list of key value pairs. Nimn data format is all about separating object structure from actual data so dynamic maps are not recommended. However, to cover edge scenarios, field name separator can be used. 110 | 111 | Check [Serialization](#serialization) section for more detail 112 | 113 | ### Fixed Value Characters 114 | 115 | As per the Nimn data format `boolean` value can be represented as following; 116 | 117 | * *TRUE* : ASCII char 181 118 | * *FALSE* : ASCII char 183 119 | 120 | When a value is not present / missing / undefined: 121 | 122 | * *Missing premitive* : ASCII char 184 123 | * *Missing Object / Array / List* : ASCII char 186 124 | 125 | When a value is null; 126 | 127 | * *Null premitive* : ASCII char 175 128 | * *Null Object / Array / List* : ASCII char 176 129 | 130 | When a value is empty; 131 | 132 | * *Empty premitive* : ASCII char 177 133 | * *Empty Object / Array / List* : ASCII char 178 134 | 135 | ### Values 136 | 137 | Nimn data must be the serialized form of an object, array or a fixed value character representing missing, null, or empty value. 138 | 139 | ## Parser 140 | 141 | ### Serialization 142 | Serialization is the process of converting application object into Nimn data format which confirm Nimn [grammar](https://github.com/nimndata/spec/blob/master/SPEC.md#grammar). 143 | 144 | Points to be considered at the time of serialization. 145 | 146 | * In case of empty, nil, or missing map (object) or list (array) fixed value characters should be used. And respective boundary characters should be omitted. 147 | 148 | *Application object* 149 | ```js 150 | [] 151 | ``` 152 | 153 | *Nimn Data* 154 | ``` 155 | ! 156 | ``` 157 | 158 | *Note* - `!` is representing ASCII char 177 in above example. 159 | 160 | * Starting and ending of an object and array should be marked with appropriate boundary character. 161 | 162 | *Application object* 163 | ```js 164 | [{"msg": "This is awesome"}] 165 | ``` 166 | 167 | *Nimn Data* 168 | ``` 169 | [{This is awesome}] 170 | ``` 171 | 172 | *Note* : Characters `{` , `[`, `]`, `}` in Nimn data format are used to represent ASCII char 182 , 187, 185, and 180 respectively. Check [boundary characters](https://github.com/nimndata/spec/blob/master/SPEC.md#boundary-characters) for more detail. 173 | 174 | * In case of dynamic map or a list of key values pair where key names are not known in advance, key name should be attached with the value and separated by field name separator boundary character. 175 | 176 | *Application object* 177 | ```js 178 | {"msg": "This is awesome"} 179 | ``` 180 | 181 | *Nimn Data* 182 | ``` 183 | [msg/This is awesome] 184 | ``` 185 | 186 | *Note* : Characters `/` , `[`, `]` in Nimn data format are used to represent ASCII char 188 , 187, and 185 respectively. Check [boundary characters](https://github.com/nimndata/spec/blob/master/SPEC.md#boundary-characters) for more detail. 187 | 188 | * If data value consist any Nimn supported character (boundary or fixed value character) then it should be backslashed. 189 | 190 | *Application Object* 191 | 192 | ```js 193 | { 194 | "name" : "Some Name [nick name]" 195 | } 196 | ``` 197 | 198 | *Nimn Data* 199 | ``` 200 | {Some Name \[nick name\]} 201 | ``` 202 | 203 | * Order of the keys in schema, which defines object structure, should be same as order of values in serialized data. 204 | 205 | *Schema* 206 | 207 | ```js 208 | { 209 | "name" : "string", 210 | "age" : "number", 211 | "address" : "string" 212 | } 213 | ``` 214 | 215 | *Application Object* 216 | 217 | ```js 218 | { 219 | "age" : 33, 220 | "name" : "Some Name [nick name]", 221 | "address" : "Some long address" 222 | } 223 | ``` 224 | 225 | *Nimn Data* 226 | ``` 227 | {Some Name \[nick name\]|33|Some long address} 228 | ``` 229 | 230 | * Any key presents in application object but not in schema (definition of object) must be ignored. 231 | 232 | 233 | *Schema* 234 | 235 | ```js 236 | { 237 | "name" : "string", 238 | "address" : "string" 239 | } 240 | ``` 241 | 242 | *Application Object* 243 | 244 | ```js 245 | { 246 | "name" : "Some Name [nick name]", 247 | "age" : 33, 248 | "address" : "Some long address" 249 | } 250 | ``` 251 | 252 | *Nimn Data* 253 | ``` 254 | {Some Name \[nick name\]|Some long address} 255 | ``` 256 | 257 | * Any key presents in schema but not in object will be marked by [missing character](https://github.com/nimndata/spec/blob/master/SPEC.md#boundary-characters). 258 | 259 | 260 | *Schema* 261 | 262 | ```js 263 | { 264 | "name" : "string", 265 | "age" : "number", 266 | "address" : "string" 267 | } 268 | ``` 269 | 270 | *Application Object* 271 | 272 | ```js 273 | { 274 | "name" : "Some Name [nick name]", 275 | "address" : "Some long address" 276 | } 277 | ``` 278 | 279 | *Nimn Data* 280 | ``` 281 | {Some Name \[nick name\]|*|Some long address} 282 | ``` 283 | 284 | *Note* : Characters `|` , `*` in above Nimn data are used to represent ASCII char 179, and 184respectively. 285 | 286 | * A list can have single type of element which can be either any premitive value, an object or a list. 287 | * Data root should be either an object or a list. 288 | * Value separator character ( `|` ) should be used when any field out of two consecutive fields don't have Nimn supported character. 289 | 290 | Example 291 | 292 | *Application object* 293 | ```js 294 | { 295 | "Human" : true, 296 | "Asian" : false, 297 | "Name" : "some name", 298 | "Programmer" : false 299 | } 300 | ``` 301 | 302 | *Nimn Format* 303 | ``` 304 | {YNsome nameN} 305 | ``` 306 | 307 | *Note* : `{`, `Y`, `N`, and `}` in above example should be replaced by ASCII characters 182, 181, 183, and 180. Above example is for understanding purpose only. 308 | 309 | ### Deserialization 310 | Deserialization is the process of converting Nimn data into application object. 311 | 312 | All the points covered in serialization should be cosidered at the time of deserialization. In addition, 313 | 314 | * It should error when data type don't match as per schema. 315 | * It should error when Nimn data can't be mapped to given schema. 316 | * If the serialized data has more fields than defined in schema, they should be ignored if they appears in last. 317 | 318 | 319 | *Schema* 320 | 321 | ```js 322 | { 323 | "name" : "string", 324 | "age" : "number" 325 | } 326 | ``` 327 | 328 | 329 | *Nimn Data* 330 | ``` 331 | {Some Name \[nick name\]|30|Some long address} 332 | ``` 333 | 334 | *Application Object* 335 | 336 | ```js 337 | { 338 | "name" : "Some Name [nick name]", 339 | "age" : 30 340 | } 341 | ``` 342 | 343 | 344 | ## [IANA Considerations](https://www.iana.org/assignments/media-types/application/vnd.nimn) 345 | 346 | ### Encoding considerations 347 | 8bit if UTF-8; binary if UTF-16 or UTF-32 348 | 349 | ### Security Consideration 350 | 351 | Nimn data format in itself is not executable. Data encoded to Nimn format may contain binary data, regular expressions, scripting code, SQL queries etc. So the user application should convert it first into the application object instead of direct evaluation if they use the same format to represent the executable code. 352 | 353 | Structure of the application object is not bundled with encoded data. It needs to be provided externally. Hence if there is any modification in structure of encoded data like extra data field is inserted, existing data field is deleted, or if the sequence of data field is changed in encoded data then Nimn decoder may error out. However, as Nimn format doesn't enforce any limit or restriction on encoded data other than backslashing Nimn supported characters, user should ensure the integrity or confidentiality of encoded data externally. 354 | 355 | ### Applications which use this media: 356 | Any application can use Nimn data format to exchange data between same or two different applications. 357 | 358 | ### Restrictions on usage: 359 | none 360 | 361 | ## Customization 362 | 363 | The aim of the Nimn data form is to minimize object representation of data by keeping schema information apart. However the user can minimize it further by specifying special/unique characters for the set of fixed values, or by applying some compression algorithm. 364 | 365 | Such customizations can be used within the application boundary and can't be the part of this specification. 366 | --------------------------------------------------------------------------------