Anybody else get bummed out that many times that we create a lightweight thing to compensate for something overcooked (like XML) the new thing eventually ends up overcooked in much the same way?
Moreover, and on a related note, in many ways, JSON is great as an exchange format, but stifling as a config language. There is a lot if room between JSON and XML to work with.
I agree. JSON is overall better than XML for most things. It's simple and universal. This simplicity translates to the new incarnations of some good ideas that people were trying to implement on top of XML, like schemas. They are not mandatory, but useful in certain domains. Simpler format means that these things can also become simpler. So eventually we may do them right. It's a process of evolution.
> Moreover, and on a related note, in many ways, JSON is great as an exchange format, but stifling as a config language. There is a lot if room between JSON and XML to work with.
Also agree. There is also a tiny bit of room below JSON and above unstructured text that can fit a universal syntax on top of which other formats can be built, including ones for configuration. A modular one. Where you can have different formats that share the same underlying syntactical structure and as much idioms within that as reasonable.
And here comes the pitch: this is what I'm trying to introduce. A simple universal syntax. It is still somewhat undercooked (less the syntax which is minimal and stable but more its description and formats on top of it), but might be interesting for certain people. The thing is called TAO and it has a website here: https://www.tree-annotation.org/
I hope somebody will find this inspiring at least.
If so, here is a thread on HN for discussion: https://news.ycombinator.com/item?id=23966667
A (not necessarily the clearest; this is something I have to work on) description is here: https://www.tree-annotation.org/raw.html
To condense: If it's unbalanced you have to escape it with the grave accent `. Otherwise, if it's balanced, which is mostly the case, no problem.
Unbalanced brackets and consecutive grave accents (or a grave accent followed by a bracket) are the only things you need to escape in raw data.
For more discussion let's go to the other thread, not to hijack this one.
When you can make your 'format' in to a not-too-big diagram like that it makes it far easier for anyone interested to 'get it' and encompass the whole thing in their mind to work with.
https://archive.org/details/bitsavers_borlandturVersion7.0La...
JSON is a data exchange format which is sometimes used as a configuration format, also a mistake.
Will we go full circle and start using a configuration language for data exchange or mark-up? TOML APIs?
I've been developing https://concise-encoding.org over the past two years with this in mind.
A data-exchange format is essentially developing a mini-language. Even if we prohibit abstraction, we still want rich static types and the ability to define new types (algebraic types, nominal types). Taking inspiration from programming language theory, will hopefully help avoid a result like Google Protobufs, which is awkward, ad-hoc and non-compositional.
The string-type prefixing is there so that you don't actually need a schema for 80% of use cases (schemaless data is usually enough). A schema can be added later if desired, and I've been thinking of what that might look like, but it's at a different level than the encoding format and can be developed independently.
The primary purpose of this format is to serve the 80% use case (general purpose, ad-hoc, hierarchical, schemaless data with fundamental type support - or something that easily fits within this paradigm). For the remaining more complicated 20%, there are custom types and at some point in the future, schemas.
I don't agree at all with this point. RDBMS types for example are non-nullable by default. Protobufs, XML and many other exchange formats also have optional types but not null added to every type. If you want better interoperability with programming languages, I think it would be better to go after e.g. IEE754 support.
Concise Encoding does support IEEE754.
Yes and by using null-in-every type for your messaging, now you've pushed the problem out of your app and published it to the world.
But XML was perverted due to its inherent extensibility, The JSON syntax hasn't changed: scalars, arrays, associative arrays. That's all! So it has remained "pure" so to speak.
Fortunately the only issue I've run into with JSON is lack of proper NAN and NULL support, but that is largely a limitation of the language's implementation (can't support NULL if you ain't got a NULL!).
The main thing I miss is dates.
Cool link, btw. For all the years I've been using JSON I never visited the main page!
Of course, these type of "I hate the word simple" comments are always besides the point. They could be the whines of frustrated, incompetent programmers who continually produce overly complex solutions to relatively simple problems and call it a day. We all know those programmers exist.
Sometimes it doesn't happen like that, i.e. the whole clang-ir-llvm thing, but it often does (mostly during serialisation and API exports for third party consumption).
Take WSDL and XSD as an example, the idea was that you put your details in a file that can build on other abstractions and the result is a universal and portable format that allows any system to work with any other system. That failed of course because you end up exporting implementation details inside of those 'portable' abstracted specifications making it no longer portable because you now have to implement the exact same details on the 'consumer' side as well.
Comparable things happen with Protobuf and GRPC due to the same reasons. It's not as bad (yet) due to limitations on data formats you are allowed inside the protocol, and it makes it a bit more an RPC with message passing rather than a complete API encapsulation. If the maintainers can prevent it from eating in to serialisation of arbitrary objects it might even not end up all that bad after all. But that was the theory with XML as well and we all know how that worked out.
In XML-world, you felt this shame when you weren't use schema. You didn't have to, but you really ought to kind of deal. Now it's instead "hey there are schemas if you want that tool". To me that's progress.
If you contrast JSON Schema with the type declaration subset of TypeScript, you'll find that the latter is much more concise and readable.
Having said that, there's an interesting discussion to be had about the distinction (if any) between schemas as understood in the database/XML/JSON world and types used in programming languages. JSON Schema does more than most programming language type systems do (e.g. requiring string lengths/numbers be within a certain range) and this is useful for validation. It still doesn't excuse the syntax though.
Sure, you can still do these things when schemas are a non-JSON format, but it increases the barrier of entry to writing tooling on top of schemas.
A quick web search didn't yield any existing project attempting to do so, but perhaps I'm not typing the right keywords. Does anybody know if this exists?
If not, would you like it? What would be the main characteristics such a syntax should have? (Mine pet peeve are comments, i.e. lack thereof in json)
Jsonschema is a mixed bag of structure and validation, that sounds simplified, but its expressive power comes from the mix. For example, I have to limit the use of "Applicator" keyword (oneOf, allOf, anyOf) only under my controlled keywords under $defs .. urggg.
I hope in 2-3 months I could get a beta out.
Either way JSON schema is fairly lightweight and didn't try to accidentally create an awful new programming language (cough XSLT cough). I don't see it as indicative of any of the kind of fuck ups XML went through.