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

71–80 of 150 posts

Re: JSON Schema Store

#71

Post by andyjohnson0 »

seanp2k2 wrote: post #3

JSON is the version of XML we deserve.

Whenever two or more are gathered together, they shall argue about JSON vs XML.

Personally I like the simplicity of JSON and also the expressive power of XML. But then I tend to only use each for the task it was primarily intended: application data-on-the-wire in JSON and "documents" in XML. It seems like a lot of the recurrent discussion around these technologies happens when they're pushed to do things outside their comfort zone. And I wonder if some of this is down to siloing of developer knowledge.

There was a comment on HN a few days ago (not by me, and I can't find it now) to the effect that web development has historically attracted self-taught developers or those who have come to it by routes like bootcamps. It went on to say that they perhaps consequently lack some knowledge of existing techniques and solutions, and therefore tend to recreate solutions that may already exist (and not always well). And this drives the well-known churn in webdev tech: of which bolting schemas onto JSON is arguably an example.

I wonder what people think of this? Personally I think it has some merit, but that the "churn" has also generated (along with much wheel-reinvention) some great innovations. And I say that as someone who works mainly on back-end stuff.

Thoughts?

Re: JSON Schema Store

#74

Post by masklinn »

milliams wrote: post #57
8organicbits wrote: post #27

Earlier quoted context omitted.

Huh, that's a breaking change. yes/y/no/n/on/off are no longer boolean. https://perlpunk.github.io/yaml-test-schema/schemas.html

Yes, it it. However, it's a breaking change that happened 14 years ago.

Except for many yaml implementations either not supporting 1.2 at all (pyyaml, ruby stdlib) or being a weird mix (goyaml) so as to keep working with older files.

So when you’re dealing with objective reality, this is still an issue today.

Re: JSON Schema Store

#75

Post by peoplefromibiza »

k__ wrote: post #65
peoplefromibiza wrote: post #64

Earlier quoted context omitted.

> The second one is a number You mean a float , right?

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 custom code for deserialization.

Re: JSON Schema Store

#76

Post by pasc1878 »

HdS84 wrote: post #69
pasc1878 wrote: post #61

Earlier quoted context omitted.

The issue there is the complexity is necessary for some cases which are not met in trivial cases. E.g. When including element names from two sources. That is not a common use in json but with schemas you will come across it

And that could not be handled by making an optional namespace which can be used when it is actually needed? Even without namespaces, it's trivial to handle { "NamespaceA": {....}, "NamespaceB": {....}, } There is seldom need to mix it in the same object, and if you need that, you should think long and hard if you are on the right track.

Isn't that what XML did - you only put the namespace in if it was needed.

As for multiple ones in the same object it makes sense if you want to reuse a definition used elsewhere e.g. to add an address using a predefined address type. It is like using structures/records in programming languages but with no pointers for composition.

Re: JSON Schema Store

#77

Post by samwillis »

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…

You are absolutely right that XML is better for document structures.

My current theory is that Yjs [0] is the new JSON+XML. It gives you both JSON and XML types in one nested structure, all with conflict free merging via incremental updates.

Also, you note the issue with XML and overlapping inline markup. Yjs has an answer for that with its text type, you can apply attributes (for styling or anything else) via arbatary ranges. They can overlap.

Obviously I'm being a little hypabolic suggesting it will replace JSON, the beauty of JSON is is simplicity, but for many systems building on Yjs or similar CRDT based serialisation systems is the future.

Maybe what we need is a YjsSchema...

https://github.com/yjs/yjs/

Re: JSON Schema Store

#78

Post by throwawaymaths »

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.

Which is better xml design for a pure data payload (not textual content)?

    something
Or
When you get back with a coherent universal argument, we'll revisit the json vs xml question.

Re: JSON Schema Store

#79

Post by lenkite »

throwawaymaths wrote: post #78
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.

Which is better xml design for a pure data payload (not textual content)? something Or When you get back with a coherent universal argument, we'll revisit the json vs xml question.

Isn't this very easy ? Short, Succinct and a Simple No-frills string ? Put it in the attribute. Big, Long and Arbitrary Length Data ? Put it in the content of the element. Now gimme money.

Re: JSON Schema Store

#80

Post by devjab »

bryanrasmussen wrote: post #56
devjab wrote: post #30

Earlier quoted context omitted.

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

I’m simply trying to say that I think XML sucks because the people who implement it suck, and not because of any technical reasons. Hell, I’m saying that I think XML sucks because it allows people to suck when they use it, myself included.
Post reply on HN