Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON vs. XML

corecursive.com

Post reply on HN
Print view View original

141–150 of 252 posts

Re: JSON vs. XML

#141

Post by treis »

dragonwriter wrote: post #103
treis wrote: post #99

Earlier quoted context omitted.

Where XML shines is when you pass more complex data types than numbers and strings. If you repeated your example for an array of dates, as an example, strictly speaking you can't even generate the JSON. We'd first have to agree on what string representation of a date we want to use. For XML it's built into the spec.

Okay, so the point at which you need to adopt a schema language in toy examples is earlier with JSON, but in most practical cases you’ll want to do that in either JSON or XML (because, even if you are only using built-in types, you’ll still want to communicate the shape), so this objection is kind of meaningless.

Well, no. Because JSON & by extension OpenAPI lack a Date type you can't easily add validations about dates to those schemas. Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. The best you can do is a regex on the strings you call dates but that falls apart pretty quick.

Re: JSON vs. XML

#142

Post by hot_gril »

andyjohnson0 wrote: post #126
hot_gril wrote: post #119

Earlier quoted context omitted.

Even that is more complicated than JSON.

Care to elaborate?

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible.

  
    Led Zeppelin IILed Zeppelin999
    La BriseArax999
or

  
    
      Led Zeppelin II
      Led Zeppelin
      999
    
    
      La Brise
      Arax
      999
vs something like

  [
    {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},
    {"title": "La Brise", "artist": "Arax", "price": 999},
  ]
You can probably do better using XML attributes. But then you're using more features.

Re: JSON vs. XML

#143

Post by jsmith45 »

mdaniel wrote: post #114
rewgs wrote: post #93

Earlier quoted context omitted.

Absolutely agree. TOML is far and away the best for config files.

You can't be serious; I can't stand having to guess what kind of crazy markup is required to express things in toml. As a concrete example I converted my local kubeconfig (which is yaml) and here are the completely random characters indicating some kind of hierarchy apiVersion = "v1" current-context = "" kind = "Config" [[clusters]] name = "my-cluster" [clusters.cluster] certificate-authority-data = "LS0tL..." server…

It is really just arrays of objects/dicts that get complicated with TOML. For dictionary properties not inside an array, you can either fully specify the path `foor.bar.baz = 7`, or use a header like `[foo.bar]` and specify `baz=7`.

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"
If k8s was designed with TOML in mind, it probably have been structured differently, such that "Contexts" for example might be just a dictionary mapping names to an object that has the values from the "context" property (The existing pattern of an array of objects where each object has a name, but store most of their properties in a property whose name matches the object's type is already weird, but doesn't look terrible in yaml.)

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"

Re: JSON vs. XML

#144

Post by hot_gril »

wongarsu wrote: post #39
adamc wrote: post #26

Earlier quoted context omitted.

JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.

That depends on what you want it to be. For a data interchange format, having no comments is arguably a strength. For a config file format, having no comments is a big weakness.

Just do

  {
    "someSetting": true
    "comment": "TODO change to false when ready"
  }
Though really text-based protobufs are better for config.

Re: JSON vs. XML

#145

Post by taeric »

adamgordonbell wrote: post #14
meepmorp wrote: post #9

Earlier quoted context omitted.

I remember a meeting where a consultant from an MCP excitedly told our mutual client that the XP in the upcoming version of Windows stood for 'XML Protocol.' More innocent times.

Scala had XML literals as part of the language! Apparently Philip Wadler was the person who told them needed it, because the future was XML. ( Walder is big Haskell/PL person)

The irony, to me, is how it is viewed as a bit of a mistake that they had XML in Scala. Hard to square that with how instrumental JSX was in getting some of the modern JavaScript frameworks as far as it has.

Re: JSON vs. XML

#146

Post by taeric »

hot_gril wrote: post #142
andyjohnson0 wrote: post #126

Earlier quoted context omitted.

Care to elaborate?

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

If we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant.

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.

Re: JSON vs. XML

#147

Post by hot_gril »

taeric wrote: post #146
hot_gril wrote: post #142

Earlier quoted context omitted.

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

If we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant. 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…

Writing that JSON example by hand wasn't tedious. The XML example was, and the result is unreadable. It's important to be able to debug things easily. I'm going to manually type JSON when I'm testing an API, and I'm going to read the response.

If you absolutely don't care about human interface, no reason to use XML either. It's meant to be more verbose. The XML tags will often dominate the size of the payload with things like `Who`, so you have to start thinking about shorter names. Yes JSON has a similar problem, but at least it's halved and you don't have to instruct everyone to call each list element "e". If you super care about size, you'll use protobufs or something.

Re: JSON vs. XML

#148

Post by [deleted] »

hot_gril wrote: post #142
andyjohnson0 wrote: post #126

Earlier quoted context omitted.

Care to elaborate?

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

[deleted]

Re: JSON vs. XML

#149

Post by goatlover »

taeric wrote: post #57

> Turned out JavaScript was the first language to give us lambdas, and that was an amazing breakthrough. I mean... with charity I can see the context and get it. But. What!? Overall fun read through history, even if definitely from Doug's perspective only. (As evidence by JavaScript being an originator of lambdas...) I do find the idea that JSON was as novel as history says it was kind of odd. I remember inlining jav…

Crockford mentions Scheme right before that, so he's aware lambdas originated with Lisp, presumably. I guess he means JS was the first mainstream language to popularize them?

Re: JSON vs. XML

#150

Post by [deleted] »

billyhoffman wrote: post #58

I've met Douglas a few times at JS Conferences, and he is an excellent engineer (read up on his work on the NES version on Maniac Mansion). However this passage about starting a company and trying to raise capital from VCs demonstrates that even excellent software engineers can be surprisingly myopic, dismissive, and naive about software businesses. > Douglas: For me, the most difficult thing was raising money. You’r…

[deleted]
Post reply on HN