Fortunately! It was cool to do the easy things, but then you had monstruous path expressions, and all sort of programmatical drama.. Pfff...

did you know that XSLT was shown to be Turing complete ? https://staff.emu.edu.tr/zekibayram/Documents/papers/XSLT_Tu...

On the other side, I find XML/XSD still much better than JSON. JSON is way too simple...

▲

whizzter 4 days ago | parent [-]

Depends on the task, JSON won because it was so simple whilst XML is waaay to complex. Maybe an alternative to JSON with just a tad more complexity for sanity could have won 20 years ago, but alas it never happened.

▲

_heimdall 4 days ago | parent [-]

JSON is less complex because it only solves some of the problems that XML solves. That doesn't make it better or worse, but adding schema support or attempting to make REST APIs with JSON because complex, and IMO fragile, quickly.

▲

IshKebab 4 days ago | parent | next [-]

It solves the important problems that XML solved, without the mistakes.

What is it missing? I think only namespacing, but that isn't really necessary in JSON because it isn't a document format where arbitrary elements can appear in arbitrary places. I have never once needed namespacing in JSON.

Schemas... well there's JSON schema which is ok I guess. But in reality you probably don't want that either. Schemas are useful for IDEs and linters but that's it. Normally you validate a JSON file by parsing it, e.g. with Pydantic or Serde or Zod.

The biggest missing feature from XML that JSON should have had is comments! Yes it was a mistake to omit them.

▲

_heimdall 3 days ago | parent [-]

Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. There's nothing wrong with those libraries, they solve a real problem but the problem is in JSON itself.

The whole point of REST was to allow visitors to not only see the response to a request but to also be able to understand both the semantics and the functionality of it.

Think HTML - it would be comparatively useless if HTML could only contain structured data with meaning, semantics, or schemas. Anchor tags, buttons, and forms are semantic and tell the user not only what a piece of text is but how they can interact with it.

With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests.

	▲	IshKebab 3 days ago \| parent [-]
		> Validating JSON with third party runtime libraries like zod is only necessary because JSON doesn't support schemas though. No this is completely backwards. First of all, JSON Schema exists. Second libraries like Serde and Pydantic aren't schema validators; they are parsers. They parse strings (or sometimes dynamically typed JSON) into statically typed objects that you can actually use in your program. That's what you should use. A program that uses a separate schema validator and then blindly trusts the result is badly designed. There's even a name for this mistake - "parse don't validate" (you can Google it). > With JSON you have to know the shape of requests supported, the shape of data returned, and how to use that data to make other requests. Obviously. XML doesn't magically avoid the need for API documentation! I'm wondering if you've ever actually used XML at this point....

▲

whizzter 3 days ago | parent | prev [-]

On the contrary I think they did the right thing in not supporting any schema it.

1: The "simpleness" made it easy for producers/consumers with unstructured languages (ie JS,Python,PHP,Ruby,etc) to participate in the ecosystem without feeling that things were "bloated" (technically a drawback perhaps but pushed popularity)

2: DTD was put into the standard, but from my recollection most stuff was defined with XSD in practice (so a separate standard), so now implementations needed to carry both deprecated stuff and another layer. (Then again, sure you could generate bindings with XSD).

3: We needed 3 versions of Swagger/OpenAPI to come to a somewhat good standardized binding API (it itself depends/extends JSON Schema), but it's there today and we don't need to consider deprecated libraries,etc and can just point our code-generators to the schema documents and get automatic bindings.

So in practice you basically have no fragility today even if there is binding generator bugs, but that feels more of an implementation issue than a systematic error, and if anything it shows that schema generators.

Now one could argue that the "free-ness" of the JSON Format made schema generators needlessly cumbersome, and maybe that's true to a certain extent but it's still not nearly as bad as trying to interpret ASN.1 files despite all the standards (there it is.. "good luck trying to find the correct IDL files").