3 ms·

Concise Encoding: https://concise-encoding.org https://concise-encoding.org The friendly data format for human and machine. Think JSON, but with 1:1 compatible

Concise Encoding: https://concise-encoding.org https://concise-encoding.org The friendly data format for human and machine. Think JSON, but with 1:1 compatible twin binary and text formats and rich type support. * Edit text, transmit binary. Humans love text. Machines love binary. With Concise Encoding, conversion is 1:1 and seamless. * Rich type support. Boolean, integer, float, string, bytes, time, URI, UUID, list, map, markup, metadata, comments, etc. * Plug and play. No schema needed. No special syntax files. No code generation. Just import and go. The specifications are pretty much ready for version 1.0 release now, but I'm holding off until I have the reference implementation done (about 90% complete at https://github.com/kstenerud/go-concise-encoding https://github.com/kstenerud/go-concise-encoding). After that I'll start on the schema specification. Once that's done, I have a low-level communication protocol that will use this format under the hood. I could use help in the following areas: * Looking over the specifications and pointing out anything that looks weird or off or might cause problems. * Help with the schema specification. * Implementations in other languages.

kumarsw 6y ago
Somewhat OT, but one of my pet crazy ideas is a Forth-like data file format based on a stack. I've never thought about it enough to say if it's completely stupid or not.
- iujjkfjdkkdkf 6y ago
  Could you elaborate a bit? Would the file be a set of instructions that generates the data (this is how postscript works), or something else?
  - kumarsw 6y ago
    I was thinking some some subset of a stack-based language, enough to define different data types, eg. arr_name 1 2 3 4 5 array; float_name 5.75 float Sort of like how Clojure or KiCad uses S-expressions to store data. The idea was that like Forth, the parser for such a data structure would be minimal and suitable for even a crappy programmer to implement. I'd thought this would be useful for minimal systems like microcontrollers or locked-down corporate systems with no chance of installing third-party libraries.
    - iujjkfjdkkdkf 6y ago
      Interesting - if you had a parsing language defined, you could combine raw data with transformations, e.g. float_name 5.75 DUP MUL float so the transformed data gets loaded in. Could be cool for arrays or more complex data where you want to save the raw data and a record of how it gets transformed. And I understand you are targeting a minimal implementation, but the concept could also apply to bigger datasets and higher level languages, e.g. array_name 1 2 3 4 5 "x if x%2 ==0" array
mcint 6y ago
You might post on the IETF JSON and CBOR lists for feedback, help, and additional use-cases and considerations. They're a focal point for likeminded people, including implementors and users who have experience with common usage issues, upgradability, implementation simplicity, and other concerns related to human and machine-readable data interchange formats. cbor@ietf.org https://mailarchive.ietf.org/arch/browse/cbor/ https://mailarchive.ietf.org/arch/browse/cbor/ json@ietf.org https://mailarchive.ietf.org/arch/browse/json/ https://mailarchive.ietf.org/arch/browse/json/
crazypython 6y ago
My game plans to build an encoding for JSON that has schema that shows structure, name, and type. So, we would transmit a schema ID that maps to an in-memory schema. Do you have any plans for something like this? If so, we could work together.

kumarsw 6y ago

Somewhat OT, but one of my pet crazy ideas is a Forth-like data file format based on a stack. I've never thought about it enough to say if it's completely stupid or not.

iujjkfjdkkdkf 6y ago
Could you elaborate a bit? Would the file be a set of instructions that generates the data (this is how postscript works), or something else?
- kumarsw 6y ago
  I was thinking some some subset of a stack-based language, enough to define different data types, eg. arr_name 1 2 3 4 5 array; float_name 5.75 float Sort of like how Clojure or KiCad uses S-expressions to store data. The idea was that like Forth, the parser for such a data structure would be minimal and suitable for even a crappy programmer to implement. I'd thought this would be useful for minimal systems like microcontrollers or locked-down corporate systems with no chance of installing third-party libraries.
  - iujjkfjdkkdkf 6y ago
    Interesting - if you had a parsing language defined, you could combine raw data with transformations, e.g. float_name 5.75 DUP MUL float so the transformed data gets loaded in. Could be cool for arrays or more complex data where you want to save the raw data and a record of how it gets transformed. And I understand you are targeting a minimal implementation, but the concept could also apply to bigger datasets and higher level languages, e.g. array_name 1 2 3 4 5 "x if x%2 ==0" array

mcint 6y ago

You might post on the IETF JSON and CBOR lists for feedback, help, and additional use-cases and considerations. They're a focal point for likeminded people, including implementors and users who have experience with common usage issues, upgradability, implementation simplicity, and other concerns related to human and machine-readable data interchange formats. cbor@ietf.org https://mailarchive.ietf.org/arch/browse/cbor/ https://mailarchive.ietf.org/arch/browse/cbor/ json@ietf.org https://mailarchive.ietf.org/arch/browse/json/ https://mailarchive.ietf.org/arch/browse/json/

crazypython 6y ago

My game plans to build an encoding for JSON that has schema that shows structure, name, and type. So, we would transmit a schema ID that maps to an in-memory schema. Do you have any plans for something like this? If so, we could work together.