"JSON lines" extends JSON by a) not allowing newlines in values and b) allowing newlines to be used as a top-level separator for elements of a list, instead of the JSON-compliant comma-separated list enclosed in square brackets
This allows for per-line parsing, which can significantly reduce memory usage and allow for partial parsing in some scenarios. I've seen it used where the data is fundamentally a large collection at the top level where producing proper JSON was using too much memory
The way I do it is to define classes in C# and annotate with attributes (either DataContract and/or System.Xml.Serialization) and then export the schema as a set of XSD documents with the accompanying catalog file.
Sorry. My bad. PBC (Posting Before Coffee).
GraphQL
XML schema is a big reason that I would use XML. Otherwise, it’s a fairly painful and prolix standard.
XML is also a good way to deliver longer streams of data (for me), because so many parsers will allow “realtime” parsing of “broken” XML data, while JSON tends to require the entire document to be delivered (and correct) before parsing (I’m sure that will be changing, if it hasn’t already).
I’ve written ONVIF software, which is SOAP/WSDL-based.
I’ve written XSLT, which could be used as a form of medieval torture.
I’ve written servers, with REST, and REST-like APIs. I generally prefer REST-like, where the server response is JSON and/or XML (usually either one), but the GET/POST/PATCH stimulus is transaction/URI argument-based. That’s the way most folks seem to like doing it, as well.
Pure REST requires sending XML or JSON; putting a huge onus on the server, and making it difficult to be flexible (I like to support both XML and JSON as “first-class citizens”).
> Because the simplest way to validate a JSON document is first to consume it with some common library that guesses types almost like we do: “does it have quotes around? string!” And only then, with already cast value, to compare its type with whatever is defined in a schema.
This is true. JSON schema isn’t particularly useful to me. I feel like it works against the reason for using JSON. I like JSON, precisely because it is so lightweight.
XML Schema is incredibly mature and robust (and an enormous pain in the butt to write). Validation is built into almost every parser; while many folks are unaware that JSON Schema even exists.
What I tend to do, is serve both XML and JSON from a server, with XML accompanied by Schema (sometimes, dynamically generated), but the JSON derived from the XML, so it benefits from the XML validation.
I’m wondering if standards like OpenGL will replace both XML and JSON. I’ve never used it, because of the requirement to use a third-party library, but it is a compelling tool.