111–120 of 150 posts
JSON is the version of XML we deserve.
A catchy but a meaningless phrase. JSON is a dumpster on fire. Probably in even more ways than XML is. Maybe you deserve it... I feel like I'm being punished by the stupid people who make me use it in a way similar to the sham court hearings from The Planet of Apes.
What's the use-case and what alternative would you prefer?
Earlier quoted context omitted.
You're complaining about people encoding dates in string and at the same time you encode numbers in string. That's funny. There's standard to encode dates to string. It's called ISO-8601 and it's supported everywhere. Also JSON poses no particular limits which would force anyone to encode string as number.
> You're complaining about people encoding dates in string and at the same time you encode numbers in string. That's funny. No. I'm complaining that JSON is too limited. And that it's "type system" is lacking so much that I have to resort to hacks like encoding numbers in strings. Which I think is embarrassing for an industry. > There's standard to encode dates to string. It's called ISO-8601 and it's supported every…
I have yet to see Time be easy. Anywhere. At all. From daylight savings being state-dependent, system times resetting to rand, right down to CPU monotonic timing.
Using Time handling as a criticism to JSON's architecture doesn't hold water.
Earlier quoted context omitted.
A catchy but a meaningless phrase. JSON is a dumpster on fire. Probably in even more ways than XML is. Maybe you deserve it... I feel like I'm being punished by the stupid people who make me use it in a way similar to the sham court hearings from The Planet of Apes.
>I feel like I'm being punished by the stupid people who make me use it What's the use-case and what alternative would you prefer?
* You could want to have a universal tool that can examine and understand the contents of the message (for debugging purposes), but you could also want not to send meta-information about the message (s.a. types or sizes etc.) that is essential for parsing the message. And you cannot have both at the same time.
* You could want a message format that maps onto the primitive types of a particular language well, but at the same time you may want it to be universal and map to many other languages well. But this is impossible because different languages will have different primitive types and the need to be generic will act against the need of being specific.
* You may want to be able to stream data, but this works against hierarchic data organization.
* You may want to be able to write messages into pre-allocated memory buffers w/o having to re-calculate the amount of memory necessary to encode a message, but this makes it very hard / impossible to add custom fields and types.
---
Given all this, I don't think that JSON is a good match for any use-case it's currently commonly used for. If I want data transfer, I'd go for something like SQL. If I want configuration, I'd go for Datalog. But then I see value in optimizing the transfer of multiple similar records, whereas someone else may see value in optimizing transfer of hierarchically structured data, which isn't necessary repeating. I tried many formats of this kind, and am yet to find a good one. I'm inclined to think that maybe trying to arrange hierarchical data with different constraints on its organization is just a bad approach to data transfer, that the organization and constraints of such data shouldn't be encoded as part of the format, but interpreted by the users of the format. But, if I really had to do this the best way I can image, I'd still go for Datalog.
Earlier quoted context omitted.
JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.
Neither did XML originally. XML schema was sort of bolted on via some conventions of defining a schema in the root element. The XML 1.0 spec doesn't mention those. XML Schema is a separate standard that came later. Likewise namespaces are a separate specification as well and not part of the XML specification. The XML specification does have Document Type Definitions (DTD), which were sort of inherited from SGML. This…
I know, and I'm not talking about XML Schema at all (partly because it hurts my brain to even mention the absolute worst specification ever written).
I mean just the complexity of the XML data model itself, including namespaces, entity references and the ridiculously convoluted URI spec. That's more than enough to make XML far more complex than JSON.
To be fair, XML solves problems that JSON doesn't solve. JSON is not a better XML. JSON's creators simply decided that many of problems that XML solves don't need solving or should not be solved by a data format specification.
Earlier quoted context omitted.
There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far f…
>I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break It's not about the time it takes to learn about namespaces. I'm talking about the complexity that namespaces and entities add to the data model and the requirement to actually handle them throughout the entire stack. You can normalise and compare arbitrary pieces of JSON using only information availa…
I've worked a lot with XML, and I have no idea what complexity are you talking about. This just wasn't complex / difficult. Once you've learned what this was about, this was your second nature. Eg. I spent a lot of time working with MXML -- that is an XML format for Adobe Flex markup similar to XAML and a bunch of others of the same kind. It used XML namespaces a lot. But that was the least of my problems using it...
Again, I've never had anyone who learned how and why to use XML namespaces complain about it. All complaints about this feature were coming from people discovering it for the first time.
> You can normalise and compare arbitrary pieces of JSON
Dream on. No, you cannot. It depends on parser implementation. For example, you have two 20-digit numbers where 15 most significant digits are the same. Are these numbers the same number or a different number in JSON?
The fact that it's 5 pages means nothing... it's 5 pages that define a bad language that creates a lot of problems when used. So what if it only took 5 pages to write it? You can probably squeeze Brainfuck definition into half a page? -- So what, it's still a lot harder to use than JavaScript.
Earlier quoted context omitted.
Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away. Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML). JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.
JSON and XML both support UTF-8. Neither supports embedding arbitrary binary data directly, especially if that data is not valid in your current character set
Lots of comments here about XML vs. JSON... but there are areas where these two don't collide. I'm thinking about text/document encoding (real annotated text, things like books, etc). Even though XML is still king here (see TEI and other norms), some of its limitations are a problem. Consider the following text: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dol…
Earlier quoted context omitted.
There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far f…
I don't understand the problem you're describing. When would using JSON lead to data loss/corruption?
So, for a while there weren't too many objects, ids appeared to be all different... until they weren't. It's easy to see how this led to data corruption, I suppose?
---
Here's a hypothetical example: few people are aware that JSON allows key duplication in "hash-tables", also, even if they consider such a possibility they might not know that JSON doesn't prescribe which key should win, should there be many of them. They might assume that the definition requires that the first chronologically wins, or last, or... maybe some other rule, but they hope that it's going to be consistent across implementations.
Obviously, to screw with developers, JSON doesn't define this. So, it's possible that two different parsers will parse the same JSON with the same fields differently. Where this could theoretically explode? -- Well, some sort of authentication which sends password with other data that can be added by user, and the user intentionally or accidentally adds a "password" field, which may or may not later be overriden and may or may not later be interpreted on the other end as an actual password.
---
There are many other things, like, for example, JSON has too many of the "false" values. When different languages generate JSON they may interpret things like "missing key" and "key with the value null" as the same thing or as a different thing. Similarly, for some "false" and "null" are the same thing, while for others it's not.
It is interesting that people love json (now with schema), but hate XML while loving HTML at the same time. It is all pretty boring and largely the same imo.
The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: true versus 1 Some systems require the token "true", others will only treat 1 as the boolean true. For example, MS claims that for exchange ASD boolean values must be integer 1 o…
XML is a language for marking up text. SVG uses attributes for all vector data, because the vector points are not meant to be presented to a user as raw data.
If I embed a SVG into a XHTML document and the browser does not understand SVG, the text within the graphic is still presented to the user.
> Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently:
This is not a responsibility of XML, which deals in a common well-formed markup format for various document format.
It sounds like you are dealing with a tool that has defined an XML-based data interchange format, and that they may have inconsistent tooling for their format.
Lots of comments here about XML vs. JSON... but there are areas where these two don't collide. I'm thinking about text/document encoding (real annotated text, things like books, etc). Even though XML is still king here (see TEI and other norms), some of its limitations are a problem. Consider the following text: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dol…
I would argue that the inline way of annotating things in XML is actually ok-ish if one absolutely needs human edit-ability, but otherwise bad design. {text: "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.", annotations: [{tag: "sometag", ranges: [{from: 12, to: 26}]}, {tag: "sometothertag", ranges: [{from: 21, to: 39}]} Note that this also…
also, as I get older I have a deeper and deeper appreciation that "offset" and "text" are words that are fraught with peril