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

When XML Beats JSON: UI Layouts

engineering.instawork.com

Post reply on HN
Print view View original

271–274 of 274 posts

Re: When XML Beats JSON: UI Layouts

#271

Post by vbezhenar »

tasogare wrote: post #167
vbezhenar wrote: post #74

Earlier quoted context omitted.

> Numbers can be expressed, they just have to be parsed on the client. But client has to know that they're numbers. So you can't just parse XML into JavaScript object without any knowledge about its structure. > For array, child elements are ordered and form an array naturally. But you can't express array of 0-length this way without explicit knowledge about structure. And you can't distinguish array of 1-length from…

> without explicit knowledge about structure That's why XML Schema exists. So, everything you listed is possible in XML if you don't put aside some specifications on purpose. And JSON is so self-describing that someone came with... JSON Schema.

Yes. And that's my point: you don't need schemas to work with JSON. JSON Schema exists, of course, it would be strange if someone did not invent it, as it's an obvious idea. But I've yet to see anyone using it.

Re: When XML Beats JSON: UI Layouts

#272

Post by weberc2 »

yellowapple wrote: post #207
weberc2 wrote: post #143

Earlier quoted context omitted.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pret…

I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language.

If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like.

> That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this.

I'm not really familiar with this. I'll have to read up.

Re: When XML Beats JSON: UI Layouts

#274

Post by patsplat »

patsplat wrote: post #273
Mikhail_Edoshin wrote: post #257

Earlier quoted context omitted.

It's funny that YAML spec is three times as long as XML 1.0.

The XML bloat is on the processing side.

Or rather, was. At the time one could either:

- write a sax event based parser that scaled but was low level

- use a DOM parser with a fairly convoluted API. The combination of attributes and children makes for wordy accessors.

Both YAML and JSON provide formats that more readily deserialize into native map / list / string / number types which at the time was quite convenient.

Post reply on HN