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

41–50 of 150 posts

Re: JSON Schema Store

#41

Post by brabel »

HdS84 wrote: post #35
fauigerzigerk wrote: post #32

Earlier quoted context omitted.

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

Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?

Re: JSON Schema Store

#43

Post by pbourke »

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…

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 like JSON. It’s a very complicated document format that is validated with reference to an external spec.

I think XML is a great fit for a document format that can become arbitrarily complex yet still easy to author and validate. It’s obviously a really poor fit for a wire transport protocol.

Re: JSON Schema Store

#44

Post by HdS84 »

brabel wrote: post #41
HdS84 wrote: post #35

Earlier quoted context omitted.

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

Hey, I work with Java, at work no one has ever complained about a var. Must be your inner circle only?

Quite possibly. We would need to look through a few OSs projects to determine what's a common style.

Re: JSON Schema Store

#45

Post by crabbone »

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

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 wasn't perfect. But JSON isn't really better. It sucks in a slightly different way because people keep inventing these formats w/o much thinking, and once discover problems, don't fix them.

Re: JSON Schema Store

#46

Post by crabbone »

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…

Try using UTF-8 encoding for XML, and your problems with zero byte encoding will go away.

Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML).

JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.

Re: JSON Schema Store

#47

Post by danbruc »

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.

Well, it's the same in XML, more or less. [1] The difference is that XML cleanly separates types and data, all the type information is in the schema and there is no type information in the data, so without a schema you can not properly type the data.

JSON on the other hand does not separate types and data, the types are implicitly contained in the data. So you can get type information from the data without a schema, at least up to the point where JSON's simple type system is no longer expressive enough, then you need - just as with XML - a schema to get the correct type information, for example to distinguish actual strings from dates.

If you really need this, nobody stops you from including type information in XMLs, true attributes on elements or "strings" but not numbers 123 and use that. You will of course have to do this on your own, that is just not the way XML is supposed to be used.

[1] Let me clarify this a bit. If you handle XML, you usually have a schema and therefore the type information. If you have a non-trivial JSON, you also need a schema for the types. You can only get away without a schema for simple JSONs where the implicit type information is good enough. But then you could do almost the same with XML, just parse the content and see like what type it looks. You will not get quite to what JSON can do in a sane way but it might be good enough just as JSON without a schema is sometimes good enough.

Re: JSON Schema Store

#48

Post by crabbone »

fauigerzigerk wrote: post #32
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 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.

There are many ways in which something can be simple. I believe that the most relevant metric for simplicity of something like JSON isn't the number of language elements it has (this would mean that, eg. Brainfuck is simpler than JavaScript), but the amount of work necessary to produce a correct program. JSON is an endless pit of various degrees of difficulties when it comes to writing real-world programs. It's far from simple in that later case.

I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break, but working around JSONs bad decisions when it comes to number serialization or sequence serialization will probably take days in the best case, with a side-effect that this work will most likely have to be done on an existing product after a customer complained about corrupting or losing their data...

Re: JSON Schema Store

#50

Post by crabbone »

HdS84 wrote: post #34
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.

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

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 namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion.

Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.

Post reply on HN