JSON vs. XML

Post by chimeracoder » Thu, Apr 06, 2023, 9:53 PM UTC

tuukkah wrote: post #23

adamgordonbell wrote: post #14

Earlier quoted context omitted.

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)

Was it far from JSX?

  // XML literals (to be dropped)
  val mails1 = for (from, to, heading, body) 
      {from}{to}
      {heading}{body}
    
  println(mails1)

  // XML string interpolation
  val mails2 = for (from, to, heading, body) 
      ${from}${to}
      ${heading}${body}
    """
  println(mails2)

Post by preseinger » Thu, Apr 06, 2023, 10:10 PM UTC

taeric wrote: post #171

hot_gril wrote: post #157

Earlier quoted context omitted.

Don't you also have to escape stuff in XML? Like &gt, which is even worse.

Yes, though many languages have lenient parsers. Most browser parsers, for example, will probably only be lenient if parsing "HTML." new XMLSerializer().serializeToString(new DOMParser().parseFromString(" hello ", "text/html")) The above in my console does as expected there. And again, entities are a very dangerous part of XML and friends. You are correct that if you tell it that that is xml, the browser will throw i…

Post by hot_gril » Thu, Apr 06, 2023, 10:38 PM UTC

andyjohnson0 wrote: post #189

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},…

Thanks. I get your point about the close element including the tag name - but that's the kind of detail I leave to the serialisation library, in the same way that the close scope token in json is different to the start scope token. 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 t…

Post by taeric » Thu, Apr 06, 2023, 11:03 PM UTC

preseinger wrote: post #203

taeric wrote: post #171

Earlier quoted context omitted.

Yes, though many languages have lenient parsers. Most browser parsers, for example, will probably only be lenient if parsing "HTML." new XMLSerializer().serializeToString(new DOMParser().parseFromString(" hello ", "text/html")) The above in my console does as expected there. And again, entities are a very dangerous part of XML and friends. You are correct that if you tell it that that is xml, the browser will throw i…

per specifications, json parsing is not lenient, html parsing is lenient

Post by user3939382 » Thu, Apr 06, 2023, 11:24 PM UTC

Sohcahtoa82 wrote: post #185

user3939382 wrote: post #13

If it's not obvious, the issue is that standardizing a data format is going to have trade offs. Interoperability, leveraging tooling universally so all effort is going in the same direction, awesome. The problem is that some uses cases for the format are going to be insanely complex, which will make the standard and tools unnecessarily complex for the simple cases. JSON is simpler and easier for many cases, but then…

> you're going to end up translating JSON XML which isn't fun. Not fun? It's not even possible in the general sense. If you have XML that looks like: cheese How would you convert that to JSON without knowing how the JSON consuming application expects it to be formatted? Where do you put the "breakfast" and "count" attributes? You'd need to manually write a translator for each potential translation.