Sorry, as who have already designed yet another JSON alternative. Many things about this format are just wrong (as of the first edition):
- (EDIT: Mistakenly read SHOULD as MUST, ignore this item please) The requirement for the mandatory BOM is unacceptable for most non-Windows users, as BOM is by definition invisible.
- An arbitrary name is equally questionable, even XML doesn't do that. Do you accept tabs for example?
- There is absolutely no way to indicate the data type. The document accidentally mixes the wire format and serialization protocol; never a good sign.
- Do you accept 3,000 or 3,,000 or 30,00 or 3,0,0,0 or ,,,3000 or 3000,,, or 3,e,3 or 0.000,3e7 or ,,,?
- How many digits in each group are recommended for the encoder?
- What on earth is "IEEE 64 bit double precision floating point numbers" in the context of textual format?
- Do you require a specific rounding or not in the decimal-to-binary conversion?
- Is `\u{d800}` accepted or not? (JSON famously has this issue.)
- If you have to escape the base64 padding, maybe you should just drop the padding?
- Graph is generally a bad thing to encode at this level, because many applications do not even expect graphs and that can lead to DoS attacks.
- No clear definition of the data model. The document starts with objects, arrays and scalars (untyped? stringy? I dunno), then only reveals that objects can be typed and shared and specific types of scalars should be written in certain ways much later. Define the data model first and describe possible encodings of that model instead.
- Not allowing anything besides from space and tab is okay, but that doesn't speed processing to be exact.
- While technically a matter of choice, it uses a lot of unmatching angle brackets and that's just... ugly.
- In fact, I don't really see why other grouping characters were unused in the first place.
- No canonical representation.
Maybe you should review tons of other alternatives in this space (I recall at least 2--30 of them, probably much more) before your own design.