> Adam: [...] He also wanted people to use JavaScript properly – use semicolons, use a functional style, don’t use a vowel, use JSLint and so on.

They could have done the same with XML, i.e. define a simple-XML subset without schema, CDATA, entities, etc. Instead they built it on top of another language that is so infamous that they felt the need to write JSLint.

> Adam: The thing they came up with, Doug’s idea for sending JavaScript data back and forth, they didn’t even give it a name. It just seemed like the easiest way to talk between the client side and the backend, a way to skip having to build XML parser in JavaScript.

So the original reason was that they could use eval(jsonstr)? Because of the security implications they better had written a JSON parser. At that point, is it any better than writing a simple-XML parser? At least, that would have saved them from the "it's not a standard" discussions.

Not so different from today. That quote is about HyperCard, not JS, by the way.

The current state of JSON generation/validation is simpler than the XML ecosystem, but a bit hackish.

We can have a much better stack.

Seems politeness goes a long way when you're facing federal charges

It also means it's worse format for configs where you sometimes need to annotate a few nodes with comments.

Local schemas, not crazy remote schemas.

Or some sort of way to bless an "official" schema format.

  In 1996 I was at some of the initial XML meetings. 
  The participants� anger at HTML for �corrupting� 
  content with layout was intense. Some of the initial 
  backers of XML were frustrated SGML folks who wanted 
  a better cleaner world in which data was pristinely 
  separated from presentation. In short, they disliked 
  one of the great success stories of software history, 
  one that succeeded because of its limitations, not 
  despite them. I very much doubt that an HTML that had 
  initially shipped as a clean layered set of content 
  XML, Layout rules – XSLT, and Formatting- CSS) would 
  have had anything like the explosive uptake.

Also, it's way better in transferring/storing big, complex intricate data like 3D objects.

Not so with XML: all the parsers were insanely complex with the namespacing and whatnot feature support and possible external URLs and everything else...and as a result however no XML library was ever adequate to interface with anything. On multiple occasions generally the best way to build XML for something was to take a working copy, and then glue text together so you would exactly replicate whatever that specific application wanted, rather then trying to use anyone's library for it.

I think it's not so much about readability but about complexity. XML is meant to represent complex data, like complex rich text or nested vector graphics. That makes XML complex, conceptually, visually, and in implementation. If you use it to represent something that could have been a csv you're going to have a bad time (as everyone had in the 90s).

[0]: https://dev-docs.kicad.org/en/file-formats/sexpr-intro/

ie, the benefits of simplicity have a limit.

Writing a conformant XML parser is a HUGE undertaking comparison.

I could get most places to give me the time to write a JSON parser in whatever language of it didn’t have one. I couldn’t do that with XML.

Because of this, every common language (and most uncommon ones) has a JSON parser while XML parsers are less common (and fully conformant ones are even more rare).

In reality people insert those meta-processing instructions in other ways.

But you still should have the option to at least ignore them while reading. That would make JSON config files so much better to work with.

At least use a native toml file as an example.

Also if I was handwriting that I would probably make more use of doted property names implying dictionaries like so, which though it has a little bit more repetition in property names, seems easier to read:

    apiVersion = "v1"
    current-context = ""
    kind = "Config"

    [[clusters]]
    name = "my-cluster"
    cluster.certificate-authority-data = "LS0tL..."
    cluster.server = "https://example.com"

    [[contexts]]
    name = "context0"
    context.cluster = "my-cluster"
    context.user = "my-user"

    [[contexts]]
    name = "context1"
    context.cluster = "my-cluster"
    context.user = "my-user"

    [[users]]
    name = "my-user"
    user.exec.apiVersion = "client.authentication.k8s.io/v1beta1"
    user.exec.args = ["eks", "get-token"]
    user.exec.command = "aws"

Such a redesigned to be a more TOML friendly schema would then look like this:

    apiVersion = "v1"
    current-context = ""
    kind = "Config"

    [clusters.my-cluster]
    certificate-authority-data = "LS0tL..."
    server = "https://example.com"

    [contexts.context0]
    cluster = "my-cluster"
    user = "my-user"

    [contexts.context1]
    cluster = "my-cluster"
    user = "my-user"

    [users.my-user.exec]
    apiVersion = "client.authentication.k8s.io/v1beta1"
    args = ["eks", "get-token"]
    command = "aws"

I disagree, this example is just sloppy programming. Passing unvalidated data deep into a program is bad, I'm not arguing for that. What I'm saying is that you should be converting your unvalidated serialized data into a structured type right on the edge. Your data type/type system should __be__ your schema/validator.

> So if you're using a language like JavaScript or Python, then a JSON schema can be used to validate input right away. Think of it like enforcing a pre-condition.

This is what I do with python+pydantic:

    @dataclass
    class Foo:
        bar: int

    foo = Foo(**json.loads(json_buff))

> It's also useful in cases where JSON is being used for configuration files. At my company we have quite a few places where JSON files checked-in to a git repo are our source-of-truth which then get POST'ed to an API. We can enforce the schema of those files using pre-commit hooks so no one even wastes time opening a PR that will fail to POST to the API. The same JSON schema is also used by the API to ensure the POST'ed data is correct.

You can easily do with serdes and a type library as well.

---

I guess schemas may be useful for crossing language boundaries, but you're going to need language specific types/objects at some point so why use schemas directly even then? (I think gRPC may have code gen tools for this purpose).

At first XML namespacing sounds simple. Each tag and attribute will have an optional uri attached to it, no big deal right?

From reading through the specification one could be forgiven from assuming that the prefixes are just arbitrary mappings that a processor can ignore, or automatically remap to alternate prefixes.

For example, it is true that <abc:a xmlns:abc="https://example.com/xyz" xmlns:def="https://example.com/xyz"><def:b>5</def:b></abc:a> (notice both namespaces are the same url) is equivalent to: <a xmlns="https://example.com/xyz"><b>5</b></a>.

Unfortunately, the data model also allows for content to reference the namespaces by prefix, and therefore every general xml processor that supports namespaces must keep around an application accessible mapping from the prefixes to namespaces, as the application may need to be able to access that information to interpret attributes or content. The only exception to this would be if the general XML processor insisted on having schema information for every namespace it might come across. In that scenario it would be able to tell if an attribute value of "abc:b" is really a string literal, or a reference to a namespace identifier (QNAME data type), where the namespace is whatever the current "abc" prefix is bound to, and the identifier is "b".

But obviously we don't want to add full schema support for a simple implementation, so we need to keep the mapping information around, just in case the application needs it. We also cannot easily offer nice features like changing a document to use preferred prefixes for certain namespaces, unless we also keep any prefixes that are used in values that could be interpreted as QNAMES, just in case they actually are, but our processor does not know, because it has omitted schema support for simplicity (or perhaps it included schema support, but does not have a schema available for some namespace).

And that is just the complexity that stems from one fairly small quirk in how XML works.

You also have no idea if an element content needs to preserve whitespace or not if you don't know the schema, and don't happen to have an xml:whitespace attribute present. Thus if you want to re-indent arbitrary xml for readability safely you could end up with something like this:

    <abc
        ><def
            >5</def
        ></abc
    >

http://harmful.cat-v.org/software/xml/

Around that time it was pretty nice passing around XML, as I was forced to work with VB.Net which also had an XML literal syntax on the backend and Flash/AS3 on the UI.

I had built a POC with E4X that was VERY similar to React/Redux over a decade before React, but the other browser vendors didn't have it... At the time IE and Chrome were shifting towards JSON.

The closest thing we have right now I think is Spritely Goblins, though that is Scheme. (Not coincidentally, one of the other Electric Communities co-founders is also a Spritely Institute co-founder: https://spritely.institute/about/)

We’re not using anything else from Prisma, but if we had to implement something else in JS to talk to a database, that would be a contender for our database interface layer (there are only a couple of others that are even remotely usable, having suffered through the disaster of a Sequelize implementation). We’re more likely to use Elixir and Ecto.

I don't know that I can lay the blame on either one of them directly, mind. But the industry definitely suffered from the bad faith cooperation of those companies.

  {
    "someSetting": true
    "comment": "TODO change to false when ready"
  }

- If you are describing hierarchal data, JSON is great

- If you are describing text with markup, especially extensible markup, for machine generation and consumption, XML is great.

- If you are describing a graph, neither have broadly accepted standards so you are kinda on your own.

Depending on your requirements, a recipe collection might be better in XML or in a flavor of markdown. A comprehensive data schema and software support for recipes could be challenging/limiting, compared to marked-up text.

Having the same tags many times means the file can be nicely compressed, it's being XML means it can be verified independently with a schema (and the schema can be defined as a remote location over HTTP if needed be), too.

You can always store data more efficiently with binary formats, but XML DOM parsers allows to access arbitrary parts of the tree instantly, so working with it is both easy and fast at the same time.

At this level they are both about equal in complexity: JSON has data types that XML doesn't, and XML has attributes and CDATA that JSON doesn't. JSON syntax is more succinct, but XML syntax is more regular.

If you are just worried about data loss, having null allowed in text segments is already begging for failure, as C programs will almost certainly get them wrong.

If you are transferring binary, base64 or similar will already cover you.

And again, if this is a strike on xml, how do you represent NaN in a JSON document? Do what DynamoDB does and wrap all numbers in quotes?

I don't get these types of arguments.

There's zero reason you can't write code that parses a date in an expected format (and throws an error if the date is formatted incorrectly) and then checks that the date is in the past.

Yes, it does mean you'll spend time writing more code (You know, the job you're being paid to do?), and it would be nice if your data format supported such automatic checking functionality out of the box, but to say "It can't be done!" is just plain silly.

It's still a text bound serialization format, you still have to parse a tree for it.

Is it just particularly mature libraries?

What broke me were: plain string and empty node handling.

Here is a fun quiz. Which of these two documents or both or neither are valid. With explanation ofc.

Yaml#1

     :

    :

Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in ways that is frustrating.

As for "looks horrible"... well yeah, I always feel that xml looks "spikey" somehow. But I've been programming in curly-brace languages for 30+ years and I still find json harder to read than xml: I think my brain tries to interpret it as code, not data. I find xml easier to read (even when its unformatted) precisely because the close-tokens kind of document what element they're closing.

Each to their own I guess. At least we're not stuck using ASN1.

Like, if I were there when XMPP was created, yes I would have insisted on JSON. XML was a plainly bad choice. Edit: Oh, JSON didn't exist until a little later. Maybe something similar did.

    new XMLSerializer().serializeToString(new DOMParser().parseFromString("<a>hello < </a>", "text/html")) 

You are correct that if you tell it that that is xml, the browser will throw it back at you. Just as the JSON parser will barf on JSON.parse("{'test':'value'}").

Some items can even be other forms of xml that have their own schemas dictating what is valid. (Thinking SVG here.)

I'll also note that even there, I can see why HTML went with the odd parsing they do. XHMTL tried going with "well formed" documents, but that falls flat for the authors. Is why "sections" of a document are essentially just collecting all of the "h" tags and making an implied tree out of that. As opposed to making the tree directly. To that end, my markup language of choice for Jupyter style things is org-mode in emacs. Yes, it has some warts; but again, all formats that I have ever seen have warts.

Edit: I want to add that I don't intend this as a "correction." I should say that I agree with your post. Complicated field where I doubt I'd have done better than most others. :)

any parser that behaves otherwise is pretty clearly buggy

json has many problems but parsing ambiguity is not really one of them

HTML5 is not XHTML.

<!DOCTYPE html> <title>Title <h1>Heading

expands to

<!DOCTYPE html> <head><title>Title</title></head> <body><h1>Heading</h1></body>