Took me an embarrassingly long time to figure out you could scroll that list
Your comment made me realize that you can scroll past the list on mobile. I didn’t see Autocompletion section yesterday.
Wonders of modern “clean” design.
JSON Schema Store
51–60 of 150 posts
Re: JSON Schema Store
#52JSON 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.
Re: JSON Schema Store
#53It 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.
It's very easy to understand why people prefer JSON.
95% of developers know exactly what JSON is without ever having read anything technical about it. It's obvious.
XML on the other hand... Who here can say they actually know anything substantial about XML besides the syntax? My guess is <10%.
Re: JSON Schema Store
#54Earlier 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.
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?
Re: JSON Schema Store
#55Earlier quoted context omitted.
XML suffers from too many options and useless bells and whistles. E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, especially if the source and target are object oriented and/ or a relational db. What's the point? Then there are namespaces, sure there are probably lots of places where you need to use them. But I never encountered a place where they are really needed, but beca…
Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML nam…
> Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything?
Two reasons:
1) Because it's unnecessary complexity. When you add unnecessary complexity into fundamental technology that everything uses, you've now made everything worse. It's like polluting the lake, and then ignoring the fact that beginners need to learn how to boil the water properly drinking it.
2) Because that prevents the technology from being adopted. Whether you think it's justified or not, beginners will choose the tech that's easier to use, and it will succeed.
The market of technology adoption forces us to make things simple for beginners, and in the end, that's good for all of us.
Re: JSON Schema Store
#56JSON is the version of XML we deserve.
Nobody deserves XML! In all seriousness I get the idea behind XML and I have used a couple of SOAP services which were absolutely brilliant, but as someone who has spent a decade “linking” data from various sources in non-tech enterprise… Well… let’s just say that I’m being kind if I say that 5% of the services which used XML were doing it in a way that was nice to work with. Which is why JSON’s simplicity is such a…
>In all seriousness I get the idea behind XML
followed by
>and I have used a couple of SOAP services which were absolutely brilliant
makes me doubt the first part of the statement.
If I were to guess what it means is you understand the point of SOAP, and also understand the limitations and problems especially as it relates to uses of XSD in SOAP and the various stack of Web Service specs, but you probably have not had much experience with non-XSD based validation of XML, you do not have any experience with document formats as opposed to data formats, you probably are not familiar with larger international standards like UBL, and not familiar with XML formats that are not so much data or document oriented - SVG, XSL-FO (which admittedly sucks more than is reasonable), GraphML and so forth...
A lot of the commenters here are standing up for the value of XML, and I'm not actually with this comment, there are a lot of benefits for using JSON especially when you are using JavaScript all over the place. But saying XML sucks because XSD and SOAP sucks indicates a potential lack of knowledge about the whole subject (perhaps only caused by infelicitous phrasing)
Re: JSON Schema Store
#57Re: JSON Schema Store
#58It 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.
It's very easy to understand why people prefer JSON. 95% of developers know exactly what JSON is without ever having read anything technical about it. It's obvious. XML on the other hand... Who here can say they actually know anything substantial about XML besides the syntax? My guess is <10%.
[deleted]
Re: JSON Schema Store
#59Earlier quoted context omitted.
I prefer JSON's strictness. A Boolean cannot be confused for a string. In yaml: country: no Now your country is Boolean(false) Now, I still prefer yaml overall. Also, I hate that GitHub actions don't support anchors.
In YAML 1.2 that gives the string "no".
So that's been the spec since 2009???
Re: JSON Schema Store
#60Earlier 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?
if you are making JSON data to use in your language and application you will probably not have any problem. But as in any thing there can interoperability issues between implementations and programming languages - especially if your JSON is being generated and consumed by your JavaScript site
some potential issues https://bishopfox.com/blog/json-interoperability-vulnerabili...
on edit: not parent commenter of course, just what I think they might have meant.