/tech/ - Technology★

Show us its true power then, faggot

>>926985 (OP)

In a world in which YAML exists, why do I want XML? DTD's aren't very useful to me.

>>926991

And if you don't like YAML, S-expressions are a very fine alternative.

You're right that I don't understand its true power. That's why I don't use it. I usually want something that's easy to reason about, and XML is not that.

I expect there are a lot of cases in which it's the right choice, but I haven't tried to deal with one yet.

>>926992

S-expressions are too simple, though. They can't even cleanly express a mapping, because an a-list is ambiguous and could just be a list that happens to have that structure. It's important to be able to get back the exact same thing you put in, and JSON manages to do that for a lot of languages while still fitting on a bookmark.

They sit in a range of complexity and power between csv and JSON, and I don't think there's enough room there to justify the fragmentation.

>>927020

>They can't even cleanly express a mapping

Correct, you have to annotate it if you want to imply specific data structures.

>>926985 (OP)

What can XML do that JSON can't?

>you're not smart enough to understand its true power

Armchair Philosophy Off Topic Crap:

Of all things in this world, "true power" is the easiest to understand. In true power lies no subtlety. True power is as obvious as a wasp's warning colors. True power makes itself felt when it's near you. It intimidates you when it's hostile, and it gives you courage when it's friendly. XML is shit, there's no true power in it. This be a troll thread. And mind you, I prefer XHTML to HTML5.

>>927024

Wouldn't that make it de facto more complex than JSON for most things people do with JSON? The O stands for Object for a reason.

>>927028

Object doesn't matter here. It just happens that JSON is expressive enough to map very generally to data structures common to almost every language. Of course, it doesn't specify implementations of key-value tables, so it's not universally perfect for serialization, so S doesn't stand on it's own. Of course, the J is there for a reason, and puts everything into tho context of Javascript, and then it all makes sense.

>>927027

>What can XML do that JSON can't?

Attributes

Parsing anything just absolutely sucks though. You'd think JSON would be quite simple to get right, but it's not. http://seriot.ch/parsing_json.php

I honestly don't understand it NOW. I feel like when it comes to serialized formats you need to go 1 extreme or the other. Human readable or binary, XML feels between. A good effort for sure, but I think JSON and YAML are winning on the human readable front, where things like protobuf, and other shit is winning on the binary front.

The craziest thing to me is that human readable still exists at all though, you'd really think that everything would be some form of binary that is composeable INTO something human readable, that's the whole purpose after all.

>>927085

If some web endpoint serves JSON you can curl it or open it in your browser and have a rough idea what it's doing even if the tool you're using doesn't know what JSON is.

If it serves a binary format that's a lot more tedious.

>>927087

I know how some people feel about Unix but shouldn't we strive to just make standard tools that are essentially just `cat` with a decoder, much like `jq`?

Most browsers already style raw XML and JSON to make it more pretty to humans, I feel like at that point we should just go all in. Make choose a binary format and make the render pretty. Same on the command line, `curl ... | prettyfy-output`.

Maybe that's too extreme but the half measures have me confused. Like in your example, if you're encountering the raw data and the tool doesn't support it by itself, someone else will probably also encounter that. Seems better to just flesh out the tools than this. But I guess that's additional work, but then again, it's not like software libraries don't exist, once it's solved, it's solved.

>>927092

These are some of the ways in which I might directly look at JSON:

- in my web browser

- output from curl or cat or some other tool that can output arbitrary data

- printed for debugging purposes in any of a dozen programming languages

- inserted into the middle of a webpage or other document by a misbehaving program

- inserted doubly-encoded into other JSON data

Occasionally I even hand-write it, and it's nice to be able to do that directly without running it through an encoder first.

Keeping it human-readable is just too useful in most cases.

BUT WHAT ABOUT BSON?

Can we combine JSON with CSV-like table into a new type of format?

What about BSON? Or other Binary JSON formats?

BSON, what about it?

>>927105

JSON is also really easy to write. There was a time when I had to keep track of a number of purchases over a period of several months, and whipping up a JSON file in a couple of seconds gave me a solution which I can write to in any text editor, eyeball easily and I can parse it programmatically in pretty much any programming language out there. My workflow was to add new entries in my text editor and use a small script to process it into a PDF that looked nice to the eyes. A binary format would have been much harder to maintain manually.

Of course I could have set up an SQLite database, but for something this simple it would have been too much work to come up with a schema, and changing it later would have been much more work when I can only interact with the database using a language that makes me vomit, or a GUI client. On the other hand, going from a JSON file to a database is easy. Maintaining and transforming a JSON file allows me to have a fluid initial phase when I might not even know what my database should look like.

>>927114

>>927158

Can BSON do anything MessagePack cannot?

https://msgpack.org/

>>927166

>Can BSON do anything MessagePack cannot?

Being compatible with JSON is a start.

>>927400

I'm too scared to ever look at the internals of MongoDB.

>>927400

>Size and parsing speed are the same thing

>>927350

>>927400

Is there an alternative to BSON that is compatible with JSON for binary data?

>>926985 (OP)

You like it because you're not smart enough to understand that its ostensible true power is still dog shit.

>>927418

What about CSV-like tables, how are those handled in UBJSON?

This fucking thread.

>I like pointy braces

<Curlys are better!

Not in this thread:

- parser complexity

- length of the specification

- neat features like zero copy

- support for types

- etc. etc.

>>927518

See >>927400 and >>927418

>>927518

> Not in this thread:

> - parser complexity

> - length of the specification

> - neat features like zero copy

> - support for types

> - etc. etc.

MessagePack has all of those, and it's so easy, even I was able to write an implementation of it. It's one of those listed on the MessagPack website.

>>927663

Okay, what about Tables and Byte Strings?

>>927663

How does it compare to protocol buffers, cap'n proto, flat buffers etc.?

>>927664

Both are supported by the spec:

> Tables

https://github.com/msgpack/msgpack/blob/master/spec.md#map-format-family

> Byte Strings

https://github.com/msgpack/msgpack/blob/master/spec.md#bin-format-family

>>927843

I read that as schemales. I just want everyone to know that.

>>927843

Daily reminder that schemaless just means that a poorly specified error prone scheme exists in the code itself.

>>928002

ffs *schema

>>927863

MessagePack vs UBJSON vs BSON. Pro-con list when?

>>927663

XML and JSON are so easy, even I was able to write parsers for them :^)

>>927401

You really don't want to.

>>928266

Racket's reader is Racket-specific, so it's not an option if you want to share data between applications.