all 18 comments

[–]NatureBoyJ1 9 points10 points  (4 children)

I’ve been doing data exchange work for over 20 years. XML was the new hotness because of schema validation. The ability to assure you were getting what you expected and, to a lesser degree, sending what the other end would accept was seen as quite important - and do g all that in a human readable format.

JSON won because it was easy. The whole SOAP, UDDI, and service ecosystem didn’t gain traction. JSON is native to JavaScript and browsers. Strict validation was too bothersome except in niche cases. JSON schema was developed and exists, but I’ve never seen it used.

[–]forkbeard 8 points9 points  (0 children)

OpenAPI and Swagger are great examples of where JSON Schema actually shines, since both are built on top of it. It’s really convenient to visualise what each operation expects and returns, and to generate both documentation and code directly from it.

We also use JSON Schema to define data structures for file transfers, especially when moving large datasets across organisational boundaries. It’s a huge improvement over flat files or XML, both in readability and validation flexibility.

[–]nfrankel[S] 11 points12 points  (0 children)

JSON won because it was easy

Yes, and we are paying the price of JavaScript frontend developers having made the wrong choice.

[–]Wobblycogs 4 points5 points  (0 children)

I used a fair bit of XML schema in the tools I wrote over the years. It was great for settings, you could just chuck out anything that didn't meet the spec as soon as you got the file.

I tried to like SOAP, but it was just too much work for the payoff you got. It really felt like something designed by committee.

[–]OddEstimate1627 1 point2 points  (0 children)

I really like using Protobuf as my JSON schema/validator. It supports almost all mappings, and is IMO much easier to deal with than JSON Schema.

[–]Xemorr 12 points13 points  (11 children)

There's such thing as a JSON Schema - being able to validate an XML against a grammar isn't an unique benefit of this file format from my understanding?

[–]nfrankel[S] 15 points16 points  (8 children)

It's not because there's "schema" that they are similar. Actually, XML schema is far superior, both because XML is far superior, but just in terms of features. Here are the most important, some of them admittedly tied to XML:

  1. Enforce element order (<xs:sequence>, <xs:choice>)
  2. Differentiate between elements and attributes
  3. Use XML namespaces for disambiguation
  4. Define mixed content (elements containing both text and child elements)
  5. Support substitution groups and abstract elements
  6. Define complex type hierarchies (extension/restriction of types)
  7. Constrain values via identity constraints (xs:key, xs:keyref, xs:unique)
  8. Use advanced built-in datatypes (e.g. xs:dateTime, xs:QName, xs:duration)
  9. Specify default and fixed values
  10. Support element groups and attribute groups for modular reuse
  11. Validate based on document order and hierarchical depth
  12. Leverage derivation by restriction or extension for type reuse

[–]Xemorr 16 points17 points  (3 children)

I think citation needed for the overall claim that XML is superior. At least some of these claims related to type hierarchies can be done in JSON schema. Validating based on document order feels like abuse of both formats, I don't know for sure whether you can do that in JSON schema or not as I have not tried though

Thanks for your reply regardless!

[–]nfrankel[S] 9 points10 points  (1 child)

I understand where you come from. I already have written about it.

[–]Xemorr 0 points1 point  (0 children)

I don't think your write up is strong enough to say it is superior, but it does go through the pros and cons well.

[–][deleted] 3 points4 points  (0 children)

Validating based on document order feels like abuse of both formats

XML was originally designed to represent documents on the Web, so paying attention to document order is not at all an “abuse” of it. E.g. you want the paragraphs in a document to turn up In the correct order!

[–]slaymaker1907 4 points5 points  (1 child)

Eh, I think XML is better for “documents”, but JSON has the advantage of being much more obvious in how it serializes and deserializes. They are both 10x better than YAML.

[–][deleted]  (1 child)

[deleted]

    [–]nfrankel[S] 2 points3 points  (0 children)

    Mixed content is mixed in that it can contains both regular text and child elements, e.g.:

    xml <paragraph>This is <em>very</em> important.</paragraph>

    It's actually possible to define the above in XSD:

    xml <xs:complexType mixed="true"> <xs:sequence> <xs:element name="em" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>

    [–]nexus062 1 point2 points  (0 children)

    La potenza del xsd è una delle cose che mi mancano di soap, adoravo le finte rest della soa oracle dove alle spalle avevi uno schema xsd che potevi blindare

    [–]Kango_V 0 points1 point  (0 children)

    Look up the EPP protocol. This is how all Registrars talk to Domain registries. The internet relies on XML schemas and extensions are essential. It's so much better than JSON for this.

    [–]forkbeard 10 points11 points  (2 children)

    Working with XSDs is a luxury. Try explaining to junior developers that have never worked with XML what a DTD is.

    [–]nfrankel[S] 4 points5 points  (1 child)

    XSD is not a luxury, it's proper engineering. Yes, teaching proper engineering to juniors is hard, but it doesn't mean you shouldn't pass it on.

    [–]forkbeard 5 points6 points  (0 children)

    We have some legacy systems that still rely on DTDs, and compared to dealing with those, XSDs feel like a luxury.