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

61–70 of 150 posts

Re: JSON Schema Store

#61

Post by pasc1878 »

toomim wrote: post #55
crabbone wrote: post #50

Earlier quoted context omitted.

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

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

Re: JSON Schema Store

#62

Post by pasc1878 »

LispSporks22 wrote: post #40

Heh I remember we did similar registry for XML things.

but XML allowed an easy way to have distributed schemas not needing a central place. The schema. URI could be made a resource that existed at the URI.

The wording gets complex as the URI does not need to exist on the web and that need for exact wording is I suspect a reason for XML to be perceived as complex

Re: JSON Schema Store

#63

Post by revskill »

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.

Look, with JSX you can put anything as props.

JSON is just pure data.

Re: JSON Schema Store

#64

Post by peoplefromibiza »

likis wrote: post #39
berkes wrote: post #36

Earlier quoted context omitted.

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.

> The second one is a number

You mean a float, right?

Re: JSON Schema Store

#65

Post by k__ »

peoplefromibiza wrote: post #64
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 You mean a float , right?

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

Re: JSON Schema Store

#66

Post by peoplefromibiza »

slaymaker1907 wrote: post #37
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.

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…

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

Re: JSON Schema Store

#67

Post by peoplefromibiza »

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…

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

Re: JSON Schema Store

#68

Post by JodieBenitez »

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 dolore magna aliqua.
Now say you want to qualify a part of it:

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Now say you want to qualify another part, but it's overlapping with previous part:

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Of course, this is illegal XML... so we have to do dirty hacks like this:

    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Which means rather inefficient queries afterwards :-/

Re: JSON Schema Store

#69

Post by HdS84 »

pasc1878 wrote: post #61
toomim wrote: post #55

Earlier quoted context omitted.

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

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.

Post reply on HN