Re: [xml-dev] use of JSON instead of XML

I think a version of Conway's Law applies. A technology succeeds if it mirrors the organization of the programming team/institution.

So an organization where there is a high-value managed data set and related guru/guardian class will use schemas: for example SQL relational databases. Or Document databases. SGML. XML Schemas.

But an organization where conformance of a transmission to a format is condidered a kind of unit test, will not use schemas. They will have used simple XML, and then moved on to JSON.

I have been making some web services with JAX-RS 2.0. It is all about removing the need to code the layer between object and MIME mefia type. I have been impressed at how irrelevant the features it provides are to services with fixed schemas or which use XSLT. So added to JSON's virtues we have to add the force that many data binding frameworks take to developer away from using Schemas and XSLT: it artificially makes some things hard.*

Greetings from Granada, Spain!

Rick

* An example from a couple of data binding frameworks: if you use POST they support MIME multipart form only. No support for ZIP, for example. Which is not required by http or mime or html (or even The JAX-RS spec).

On 28 Jun. 2018 18:12, "Ihe Onwuka" <ihe.onwuka@gmail.com> wrote:

On Tue, Jun 26, 2018 at 5:58 PM, Peter Flynn <peter@silmaril.ie> wrote:
On 26/06/18 17:16, Ian Graham wrote:
> This has been fun!

Best we've had in weeks :-)
> But development teams aren't stupid: they think hard and pick the tools
> they believe will make them and their business successful.

Right. I just think they were initially misled into believing that XML
was a suitable format for rectangular data in the circumstances in which
they wanted it.

> To know why XML isn't picked, someone needs to talk with teams who
> made/make these decisions, and find out why XML (and associated tools)
> wasn't (and won't be) picked.
>
> An XML list is not the best forum for obtaining that answer ;-}

Nor would a JSON forum :-)

We don't need to go to a JSON forum one because we know the answer.
The argument was XML is an over-engineered solution for the development of web apps and services - JSON is simpler and better fit for that task - we don't need all the complexity and power of the XML ecosystem for that.

Perfectly valid argument.

Then they started applying JSON to more demanding domains that require namespacing and other complexities that are beyond the limited purview of a _javascript_ object but carried on making the same (or similar) but now fallacious arguments and no-one wants to deal with the vilification that would ensue if they were called out on it.

So now presenting an alternative "for those more familiar with JSON" has entered into the lexicon as uncritical justification for contorting the semantics of a working complex data model into a syntax and representation that is not equipped to deal with it.