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

JSON Schema Store

schemastore.org

Post reply on HN
Print view View original

141–150 of 150 posts

Re: JSON Schema Store

#141

Post by msm_ »

guideamigo wrote: post #138
WirelessGigabit wrote: post #10

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.

This is the only example everyone points out against yaml. For Json, there are several such syntactic problems. Unnecessary double quotes and only double quotes everywhere. No dangling comma.

These are different kinds of problems.

JSON is (arguably) too strict. YAML is (arguably) too loose. One is better for machines, the other is (usually) better for writing by humans by hand. There's no perfect compromise for every use case.

Re: JSON Schema Store

#142

Post by mediumsmart »

euroderf wrote: post #133
wyldfire wrote: post #14

Earlier quoted context omitted.

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've read the opinion that comments were omitted from JSON in order to forestall hacky round-trip conversions to/from other formats (like XML). Can anyone confirm/deny ?

The primary reason why JSON does not support comments is that its creator, Douglas Crockford, deliberately removed them from the format to prevent misuse and keep it as a pure data-only format.

Crockford observed that some people were using comments to store parsing directives, which could break compatibility between different systems. Hence, the decision to remove comments to maintain the simplicity and consistency of the format across various programming languages and environments.

https://www.freecodecamp.org/news/comments-in-json/

I vote for the minimalist heretic.

https://www.infoq.com/presentations/Heretical-Open-Source/

Re: JSON Schema Store

#143

Post by osigurdson »

pbourke wrote: post #43
zdragnar wrote: post #31

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…

XML is only concerned with whether a document is well-formed, not its conformity to a given schema. Schemas like XSD, DTD, etc can be plugged in later. Many systems just have an ad hoc schema. > At least with JSON and HTML, you don't need a separate definition file for basic, primitive data types. Unless I’m missing your meaning, this seems like an apples-to-oranges comparison. HTML is not a general-purpose format li…

I don't see XML and json as different at all - they are both markup languages that describe trees. As long as what you are describing is a tree, either is fine. Of course, I would never do an XML endpoint on a rest http service since no one would expect that and they would assume that you don't know what you are doing and your service sucks.

Re: JSON Schema Store

#144

Post by osigurdson »

zdragnar wrote: post #31
osigurdson wrote: post #28

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…

>> What should be an attribute on a tag, and what should go between tags?

Are you ok with link?

That was kind of my original point, people are fine with html but don't like XML. I think the real reason people don't like XML is it reminds them of Steve Ballmer.

Re: JSON Schema Store

#146

Post by crabbone »

unilynx wrote: post #122
crabbone wrote: post #116

Earlier quoted context omitted.

You wanted to send zero byte. This is how you send zero byte. You are making unrelated claims now that has nothing to do with your original claim.

You can't safely send zero bytes over XML even with UTF-8 encoding. Not in practice: echo ' � ' | xmllint - -:1: parser error : xmlParseCharRef: invalid xmlChar value 0 � ^ printf ' \0 ' | xmllint - -:1: parser error : Premature end of data in tag zero line 1 ^ And not in theory: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-form... Character Range [2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x1000…

I explained how to do it, and yet you didn't follow instructions, have done something irrelevant, and are now complaining that it doesn't work... well sucks being you, I guess.

Re: JSON Schema Store

#147

Post by darrenf »

peoplefromibiza wrote: post #108
darrenf wrote: post #89

Earlier quoted context omitted.

I'm not certain I understand the point you're trying to make regarding `undefined`, or indeed the expectation that `jq` and `JSON.stringify()` follow the same rules. `JSON.stringify()` is documented to behave exactly as you demonstrate, so there's no surprises: undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in…

> undefined, Function, and Symbol values are not valid JSON values that's the point. The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON. Which for the JavaScriptObjectNotation is kinda hilarious. > Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` I would expect `JSON.stringify` to give an error if trying to serialize som…

> The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON.

I don't think I agree with this. `JSON.stringify` isn't producing JSON when it returns `undefined`. Instead...

> I would expect `JSON.stringify` to give an error if trying to serialize something that naturally does not map to JSON, like many other libraries do.

> You have to provide a manual override for those situations.

... `undefined` is an error. As in, there's no meaningful difference between catching an exception and providing "a manual override" for `undefined`, is there?

> But JavaScript and ECMA (`JSON.stringify` is defined in the standard) decided that no, they can ignore the specs for some reason.

What part of what spec is being ignored? `JSON.stringify` conforms to its own spec, as you say; and when it returns JSON, the JSON is valid. Meanwhile the JSON spec itself is very explicit about not declaring rules for serialisation/deserialisation:

The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax. It also intentionally does not define how a valid JSON text might be internalized into the data structures of a programming language. There are many possible semantics that could be applied to the JSON syntax and many ways that a JSON text can be processed or mapped by a programming language. Meaningful interchange of information using JSON requires agreement among the involved parties on the specific semantics to be applied. Defining specific semantic interpretations of JSON is potentially a topic for other specifications.

Re: JSON Schema Store

#149

Post by adamlett »

crabbone wrote: post #45
likis wrote: post #39

Earlier quoted context omitted.

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

> The second one is a number This would've been useful if you knew what kind of number it was... As for what goes into separate elements and what goes into attributes: a typical answer to this is that simple types (as per XSL) go into attributes, complex types go into elements. Compare this to JSON's screwed-up definition of "hash-tables" (the things in curly braces) which doesn't require that "keys" be unique. XML w…

This would've been useful if you knew what kind of number it was...

JSON isn’t ambiguous when it comes to this. Numbers are arbitrary precision decimal numbers[1].

I’m guessing your issue is with how Javascript interprets JSON numbers as 32 bit floats. But that is a (mis-)feature of JavaScript and switching your serialization format to XML would not help, because JavaScript represents all numbers as 32-bit floats.

[1] https://www.json.org/json-en.html

Re: JSON Schema Store

#150

Post by avel »

tinix wrote: post #16
mooreed wrote: post #9

Does anyone know of a typescript translation for each of those validation models? Or maybe even a way to discover related statically typed definitions based on the validation rules? It would be really nice to not define parts of a data model that provide little to no business value - but where you can easily “stub your toe”.

use quicktype: https://quicktype.io/

Awesome tool, thank you for sharing. I made use of it already!
Post reply on HN