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

241–250 of 252 posts

Re: JSON vs. XML

#241

Post by halostatue »

bmarkovic wrote: post #231
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.

In JSON the de facto standard for datetime is (because of JavaScript) very much the Unix msec timestamp (which is always in UTC) so while it's not hardcoded in spec you basically need to be an idiot not to do it like that, and removes one huge headache of XML dates which is timezones.

I don’t think that I’ve ever seen msec timestamps passed around because JSON numbers are floats, which means that there’s a limit to the precision available (which is to imply as well that currency amounts should be passed as decimal strings in JSON for safety as well).

Suggesting that msec timestamps resolves timezone issues is naïve at best, because anytime you are passing something that refers to a real time (that is, it is significant to humans) rather than an instant time (that is, it is something like an event log timestamp), you are dealing with time in a particular place, which has human impact — cultural, legal, linguistic.

Passing around timestamps as RFC3339 UTC strings with timezone names and offsets (much like one should be doing in databases) is what would be recommended for real (human) times.

Re: JSON vs. XML

#242

Post by taeric »

slaymaker1907 wrote: post #239
taeric wrote: post #179

Earlier quoted context omitted.

I'm curious what the vulnerability is? Also not clear what the null character is. Any links I can follow? And again, if this is your line in the sand, how do you serialize NaN and Infinity in JSON? Edit: Playing with this a bit, I'd actually assume that allowing \0 would be a vulnerability. I was curious how browsers treat it, so I see that parsing to an html document seems to just drop the characters? Fun little rab…

Yeah, that's why I consider it to be a breeding ground for vulnerabilities. People will probably just assume the XML serializer can handle any strings in their language of choice and not handle those edge cases. What I ended up doing for my use case was to encode nulls as "�" but within a CDATA section so it was interpreted literally (choosing ambiguity over omission). The best way would probably be to have some s…

But what is the vulnerability? And what is a null character doing in a text document?

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?

Re: JSON vs. XML

#243

Post by kcplate »

lowercased wrote: post #111
cglace wrote: post #102

Earlier quoted context omitted.

Did it work with 98?

I wasn't working at the same place in 1998, so I can't verify. The hype around Windows 95 at the time was... incredible. Midnight store openings, hours-long line waits... insanity.

> The hype around Windows 95 at the time was... incredible.

I left one job for another in 1994 simply because the new company had access to the windows Chicago beta program (and it was a 20% salary bump). But the main reason for me choosing g that org was the beta, because I had other offers with similar salary bumps at the same time.

Re: JSON vs. XML

#244

Post by preseinger »

taeric wrote: post #235
preseinger wrote: post #219

Earlier quoted context omitted.

fun doc! it lists many of the undefined behaviors of the spec, and many of the problems in common parsers afaict none of them permit keys or value strings to be expressed with single quotes

Apologies for the, in retrospect, somewhat lazy posting of an article with no comment. I thought that article had a section about how many of them allow single quotes if you don't "enable strict." I am not seeing it on review, though; so either I made that up in my mind, or I'm remembering another article. Either way, apologies. I did find https://github.com/json5/json5 no a quick search that basically says what I as…

no worries mate

Re: JSON vs. XML

#245

Post by preseinger »

goto11 wrote: post #229
preseinger wrote: post #203

Earlier quoted context omitted.

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

To be pedantic, html parsing is not lenient, it is unambiguously specified.

if that were true then browsers would refuse to render text/html responses that didn't include a closing tag, i guess

Re: JSON vs. XML

#246

Post by goto11 »

preseinger wrote: post #245
goto11 wrote: post #229

Earlier quoted context omitted.

To be pedantic, html parsing is not lenient, it is unambiguously specified.

if that were true then browsers would refuse to render text/html responses that didn't include a closing tag, i guess

No, because the closing tag can be omitted according to the current HTML spec. See https://html.spec.whatwg.org/#optional-tags

Re: JSON vs. XML

#247

Post by preseinger »

goto11 wrote: post #246
preseinger wrote: post #245

Earlier quoted context omitted.

if that were true then browsers would refuse to render text/html responses that didn't include a closing tag, i guess

No, because the closing tag can be omitted according to the current HTML spec. See https://html.spec.whatwg.org/#optional-tags

this is exactly my point

html is not precisely defined

Re: JSON vs. XML

#248

Post by xiande04 »

mgr86 wrote: post #31
xiande04 wrote: post #24

Earlier quoted context omitted.

Agreed. That and knowledge representation (ontologies) is another good use case for XML, since JSON can't natively represent attributes (has-a relationships).

I'm in a similar sphere with XML and ontological representation. I've inherited maintenance of an ontology (of sorts) that has been used in social sciences since the 1940s. Can I ask what domain you are in? How do you like to represent your ontologies? SKOS?

Oh, I'm not using ontologies at all hah. Just interested in the idea of knowledge representation.

Re: JSON vs. XML

#249

Post by rewgs »

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…

As the other person who replied to you noted, a converted-from-yaml file wherein the service is designed to use yaml, not toml, it hardly a good example of toml. Of course your example is bad.

At least use a native toml file as an example.

Re: JSON vs. XML

#250

Post by 4rt »

preseinger wrote: post #247
goto11 wrote: post #246

Earlier quoted context omitted.

No, because the closing tag can be omitted according to the current HTML spec. See https://html.spec.whatwg.org/#optional-tags

this is exactly my point html is not precisely defined

I think you're missing the point that it is defined, the current html5 spec says that implies the existence of , implies the end of , body tags imply the end of and the start of etc.

HTML5 is not XHTML.

Title Heading

expands to

Title Heading

Post reply on HN