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

101–110 of 150 posts

Re: JSON Schema Store

#101

Post by meepmorp »

JodieBenitez wrote: post #68

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…

A strategy I've seen for dealing the inability of XML to handle overlapping tags, is to treat the tagging as an annotation layer on top of the node with the data:

  
  
    This is some sample text.
The start and end are usually byte offsets from the start of the text content in the data node. It still sucks, but at least you could apply the same general stragegy to more than just text data - I've seen it used with audio/video where the offsets are treated as time offsets into the media.

Re: JSON Schema Store

#102

Post by berkes »

peoplefromibiza wrote: post #75
k__ wrote: post #65

Earlier quoted context omitted.

A double-precision 64-bit binary format IEEE 754, if you will!

fun fact: that's JavaScript. JavaScript only supports double-precision 64-bit binary format IEEE 754 . But JSON doesn't disallow arbitrary precision numbers, that's up to the parser implementation. number integer fraction exponent In fact not all implementations support IEEE 754 doubles, and, from my experience, when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use cus…

> when dealing with money and rounding errors, many decide to serialize numbers as exact strings and use custom code for deserialization

That's exactly what I'm doing. And indeed another reason why I feel embarrassed by JSON. I mean, we -the industry- have been doing financial data transport over computer networks, for how long now? fifty years? And we keep "inventing" transport formats that unsolve issues that have long been solved and done. XML had this solved[1]. Hell, even the ancient MT940[2] had this solved.

[1] https://web.archive.org/web/20200618100100/https://deutscheb... (pdf warning) [2] e.g. https://financialdataexchange.org/FDX/About/OFX-Work-Group.a...

Re: JSON Schema Store

#104

Post by albert_e »

can JSON achema be used to describe say the schema of a RDBMS table?

is these some standardization here so I might use a JSON schema that already covers a lot of the fields that are needed to describe columns, constraints etc?

can JSON schema capture relations between fields?

Re: JSON Schema Store

#106

Post by JodieBenitez »

meepmorp wrote: post #101
JodieBenitez wrote: post #68

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…

A strategy I've seen for dealing the inability of XML to handle overlapping tags, is to treat the tagging as an annotation layer on top of the node with the data: This is some sample text. The start and end are usually byte offsets from the start of the text content in the data node. It still sucks, but at least you could apply the same general stragegy to more than just text data - I've seen it used with audio/video…

Good idea. You would have to edit your annotation layer in case the text data changes though.

Re: JSON Schema Store

#107

Post by tristan957 »

albert_e wrote: post #104

can JSON achema be used to describe say the schema of a RDBMS table? is these some standardization here so I might use a JSON schema that already covers a lot of the fields that are needed to describe columns, constraints etc? can JSON schema capture relations between fields?

I would check out the OpenAPI specification[0]. Specifically, look at the "Components" section. It might help you out.

[0]: https://swagger.io/specification/

Re: JSON Schema Store

#108

Post by peoplefromibiza »

darrenf wrote: post #89
peoplefromibiza wrote: post #67

Earlier quoted context omitted.

> you don't need a separate definition file for basic, primitive data types. unless you need something different from JavaScript primitive data types. For example integers . Or null means nothing to you. Or you want a faithful representation of input Welcome to Node.js v20.5.1. Type ".help" for more information. > JSON.stringify(undefined) undefined > JSON.stringify([undefined]) '[null]' but then jq "."

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 something that naturally does not map to JSON, like many other libraries do.

You have to provide a manual override for those situations.

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

Problem is they can't fix it now, because too many applications rely on those wrong assumptions.

Here it is the reason why you can find true and 1

Difference being XML was born to standardize the document format, JSON aspired to be a data format but failed miserably at it, even at the most basic level, like saying an int from a float. The spec is simply too vague and ambiguous to give some guarantee of interoperability, beyond numbers and strings.

Maybe we should all switch to MessagePack

Re: JSON Schema Store

#109

Post by peoplefromibiza »

maskros wrote: post #94
peoplefromibiza wrote: post #66

Earlier quoted context omitted.

> JSON just says do “\0” and calls it a day nope jq "." maybe you mean null , which has a lot of different issues though. jq "."

"\0" is not a valid JSON string escape sequence. However, "\u0000" is.

not according to jq or firefox

   >> JSON.parse("\u0000")
   Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
        debugger eval code:1
at that point "null" looks like a better more compatible option.

Re: JSON Schema Store

#110

Post by geysersam »

bryanrasmussen wrote: post #60
geysersam wrote: post #54

Earlier quoted context omitted.

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,…

That's very interesting! Thanks for the link.
Post reply on HN