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

YAML: probably not so great after all (2017)

arp242.net

Post reply on HN
Print view View original

391–400 of 412 posts

Re: YAML: probably not so great after all (2017)

#391

Post by nostalgeek »

tlb wrote: post #382
nostalgeek wrote: post #273

Earlier quoted context omitted.

More like browsers can de-serialize JSON5 natively. writing a JSON5 parser is not difficult. It's just not part of most std libs in most languages, but I would argue that most std libs don't parse YAML either. JSON5 is a good compromise.

Neither Chrome nor Firefox's JSON.parse accept JSON5. I'm not sure what browser API you mean. For example, JSON.parse(`{"foo":"bar",}`) throws a syntax error.

> Neither Chrome nor Firefox's JSON.parse accept JSON5. I'm not sure what browser API you mean.

This is a typo, I meant "can't" not "can". Off course browsers don't support JSON5 or my message makes no sense whatsoever.

Re: YAML: probably not so great after all (2017)

#392

Post by wildrhythms »

lysium wrote: post #380
wildrhythms wrote: post #357

Earlier quoted context omitted.

What's the timezone?

Do you need a time zone for dates?

Consider if I'm storing a user's (local) birthday on my server:

    {..., "birthday": "2018-03-25"}
If my server is located in New York City, and the user is in Sydney, then my server isn't going to wish them happy birthday in time.

So maybe we could do:

    {..., "birthday": "2018-03-25", "location": "Sydney/AU"}
But at this point we might as well use a standardized time format (UTC) with a timezone offset. Maybe I'm thinking too far into it?

Re: YAML: probably not so great after all (2017)

#394

Post by Mikhail_Edoshin »

tannhaeuser wrote: post #83
TillE wrote: post #8

Earlier quoted context omitted.

XML is in that odd middle-ground where it's usually human-readable, but also a huge pain in the ass to write. It's great at what it was intended for, as a data interchange format. For a general-purpose human-writable structured data format, I guess the ugly nonstandard hack that is "JSON with comments" is probably good. It's certainly faster to parse than YAML.

XML wasn't intended as data interchange format, but for replacing SGML as serialization and markup meta-language on the Web (eg. for XHTML, SVG, MathML). It can't be said often enough that markup languages are for authoring and delivering semistructured text data, not for general-purpose data serialization. As in, editing plain text files and have your text treated as content unless marked up with markup and annotate…

Well, what is the purpose of markup languages? Isn't the sole purpose of markup is to be able to process the marked-up content with a computer? Why would you add markup to your favorite verse if it wasn't to somehow feed it to machine for some purpose (analyze, typeset, etc.)?

So when we have text with markup the text part is meant to be there for humans and the markup part is solely for computers. Now let's remove all text; now there's no content for humans at all, only for computers. How is this different from general-purpose data serialization?

(Some of the samples you give, like SVG, may not have any text content at all; it's basically a drawing language.)

Given that XML ecosystem has quite a few tools (e.g. several type description languages or a declarative data transformation language just to name a few) it's a very good general-purpose data serialization format.

Re: YAML: probably not so great after all (2017)

#395

Post by Mikhail_Edoshin »

hyperman1 wrote: post #378
tannhaeuser wrote: post #323

Earlier quoted context omitted.

What problems wrt entities does XML have that it has inherited from SGML and HTML? Do you mean entity expansion attacks such as million laughs? HTML has only character rather than general entity references, and SGML has had the ENTLVL capacity to bound entity reference nesting since the year 1986. Edit: XML is just a proper subset of SGML by definition, hence it didn't introduce a single thing that wasn't there befor…

I'd consider user definable entities a problem, as you can't read a file without knowing the DTD. Million laughs is just a very ugly bonus. XML is more than the part inherited from SGML, it's also the XML culture surrounding it. Namespaces are an example of something that created an XML dialect. And of course SOAP, which actually needs the WS-I standard to explain what parts of the WS-* standards to use or ignore, an…

What's wrong with namespaces? These are simply globally unique identifiers that allow us to define and use our own globally unique names and make them passably human-readable. That is:
can mean a math function, a text file that records what's happening, and a cut-off trunk of a tree and there will be no confusion whatsoever.

(I really don't get how SOAP is relevant here.)

Re: YAML: probably not so great after all (2017)

#396

Post by Mikhail_Edoshin »

DonHopkins wrote: post #255
chx wrote: post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. The…

> "YAML ... is almost as complex as XML"

In fact YAML is probably more complex than XML; the specification of YAML, when I print it into PDF, is about three times as long as that of XML 1.0. (And XML 1.0 also describes DTD, which is kind of a simple type validation for XML and thus includes much more than just serialization syntax.)

Re: YAML: probably not so great after all (2017)

#397

Post by bhaak »

aepiepaey wrote: post #350
bhaak wrote: post #40

Earlier quoted context omitted.

The 013 to 11 issue is pretty obvious to any seasoned programmer. For example C, Ruby, and yes, also Javascript have the same "problem". Octal 13 is decimal 11. JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'. And YAML is backwards compatible to JSON. That's IMO the actual problem of YAML. It could have supported a reasonable subset of JSON and not the whole…

The web console is not a JSON parser. To check if something parses as JSON in the web console you should use JSON.parse, e.g: JSON.parse('{ 013: "11" }') which should produce a syntax error (as already mentioned by siblings to this comment).

Thanks. Yeah, I had mistakenly the believe that JSON is mostly a Javascript hash, not that 'JSON is valid Javascript' which means it's a subset of all possible Javascript hashes.

Re: YAML: probably not so great after all (2017)

#398

Post by fibo »

A few considerations I do not agree with:

> YAML is insecure by default. Loading a user-provided (untrusted) YAML string needs careful consideration.

That is trivial. Everything you execute that come from outside is potentially dangerous.

> It’s pretty complex

I would say, that YAML is more expressive and has more features. On the other hand is true that TOML is a valid alternative in many use cases.

> 3.5.3 gets recognized as as string, but 9.3 gets recognized as a number instead of a string

That is correct, in my opinion, 9.3 is a float while 3.5.3 is a version. If you want both to be strings, use quotes.

Re: YAML: probably not so great after all (2017)

#399

Post by Mikhail_Edoshin »

ajmurmann wrote: post #291
rhacker wrote: post #286

Earlier quoted context omitted.

I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/

I believe Douglas Crockforf used to make the argument that JSON is not meant for human consumption and thus shouldn't be changed to better serve humans. I personally wish hjson ( https://hjson.org ) were to get more traction. I prefer it over both JSON and YAML.

Well, then why not to allow a trailing comma in lists and objects? Computers don't care and they would even be happier, because they can then just pour array and object members with a trailing comma without concerning themselves whether this is the last member or not. (Dijkstra's train toilet problem comes to mind.) Also compare with XML, where each element is self-contained.

And why to model JSON syntax closely after JavaScript literal object syntax (which is actually more convenient, by the way) which, being taken from mainstream programming languages, naturally evolved to be written by humans in small amounts not by computers in large dumps? :)

Re: YAML: probably not so great after all (2017)

#400

Post by pjmlp »

wwweston wrote: post #204
chx wrote: post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

Fully agree with you, I have done so multiple times.
Post reply on HN