Live data from Hacker News

JSON Schema Store

schemastore.org

31–40 of 150 posts

Re: JSON Schema Store

#31

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 or 0 [0], but then links to a W3C spec that allows for the tokens true and false [1]

At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types.

[0] https://learn.microsoft.com/en-us/openspecs/exchange_server_...

[1] https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#boolean

Re: JSON Schema Store

#32

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.

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.

Re: JSON Schema Store

#33
There are some YAML based schemas there too. How does this work, is there a canonical YAML->JSON transformation, or does JSON schema spec have explicit YAML support?

edit: skipping the theoretical foundations, there seems to be at least this tool that claims to validate yaml against json schema: https://github.com/json-schema-everywhere/pajv

Re: JSON Schema Store

#34

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.

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 because they are the default you need to work with them or your queries do not work. Super confusing for beginners and annoying as heck.

Re: JSON Schema Store

#35

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.

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.

Yeah, culture is a big one. See dotnet vs java. The latter picked up many of c# feature over the years but is still much more verbose, e.g. because their developers still abhor var

Re: JSON Schema Store

#36

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…

How is your example any better in JSON? { some: true, someOther: 1, another: "true" }

Re: JSON Schema Store

#37

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.

JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a null character even if you escape it (this is allowed in many programming languages). JSON just says do “\0” and calls it a day. I’m not sure if it’s better for users, but it’s certainly easier to work with as a dev.

HTML isn’t trying to serialize abstract data and is doing what XML does best in being a document/GUI format. It doesn’t matter all that much that it can’t represent null characters in a standard way because it isn’t a printable character.

Re: JSON Schema Store

#38

Earlier 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.

That's a false dichotomy. JSON could have comments and not be ambiguous like YAML. In fact: there exists a specification called JSON5 which does include comments. But I agree that it would've been nice if it had comments before it achieved a critical mass of adoption.

I don't think they were saying that's an issue of comments, just an issue of yaml vs json.

Re: JSON Schema Store

#39
post #36

Earlier quoted context omitted.

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…

How is your example any better in JSON? { some: true, someOther: 1, another: "true" }

Only the first one will be treated as a boolean in JSON. The second one is a number, and the third is a string.
Post reply on HN