XHTML is still alive as the section 13 "The XML syntax" in the "HTML Living Standard" shows us. Moreover XML comes with a host of useful technologies : schemas, XSLT, XQuery and namespaces. It is quite complex compared to JSON but more powerful when you consider the whole ecosystem. In the end, it depends on the need we have. Quick, small, simple XML is possible and easy.
The rise and rise of JSON (2017)
31–40 of 107 posts
Re: The rise and rise of JSON (2017)
#32If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…
XML without schema are a mess.
XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular.
Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity.
Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to expensive bugs in production, but in the real world the ability to mostly ignore types lets people get things done in a more hackish / amatuer way which eases the learning curve and helps popularity.
Re: The rise and rise of JSON (2017)
#33I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…
You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/seria…
I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol.
I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON.
When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
Re: The rise and rise of JSON (2017)
#34So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.
The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML". And at the time people insisted JSON could ne…
Yep. I'm reasonably new to software development, and I've always found JSON is simple yet effective. Less so for XML. It has its place, but I think less so for a simple and reliable data interchange format.
Re: The rise and rise of JSON (2017)
#35Earlier quoted context omitted.
> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to…
You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)
That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one.
Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.
Re: The rise and rise of JSON (2017)
#36So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.
Just like there is always a group of people turning every programming language into Java there are also people turning JSON into XML: http://json-schema.org http://www.jsoniq.org http://goessner.net/articles/jsont/ https://json-ld.org
Re: The rise and rise of JSON (2017)
#37If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…
Yes but in XML we view things as trees, not sets, tuples, or the likes. If you consider stuff as trees, there is not anti-pattern and the example is not wrong, it is correct. It is easy. Maybe we can be a little bit dissatisfied with the choice of attributes vs elements. Of course JSON and its small spec is easier than XML and its bunch of complex recommendations.
Re: The rise and rise of JSON (2017)
#38"JSON’s dominance is surprising when you consider that as recently as 2005 the web world was salivating over the potential of “Asynchronous JavaScript and XML” and not “Asynchronous JavaScript and JSON.”"
"As recently as 2005," heh. In the frontend world, you might as well say "as recently as the Paleolithic age."
Re: The rise and rise of JSON (2017)
#39It’s a great thing that JSON adequate. It’s a great pity that JSON isn't much better. It would be great if JSON had comments, more thorough typing and determinism so that data structures could be compared. Apart from that it’s streets ahead of XML.
It's exactly as good as it needs to be. Trying to 'improve' JSON will turn it into xml again.
Re: The rise and rise of JSON (2017)
#40If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…
XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…
JSON does have Schemas and Validation (JSON-LD and RDF I believe are the relevant standards here), which are backwards compatible with parsers that don't support it (though the number of parsers that do is sadly rather low).
In principle you still get schema and validation.