Transit: JSON Data Interchange Format • Hacker News Board

Re: Transit: JSON Data Interchange Format

#111

Post by andyjohnson0 » Wed, Oct 14, 2015, 6:04 PM UTC

dragonwriter wrote: post #89

andyjohnson0 wrote: post #31

Earlier quoted context omitted.

Nodes for data, attributes for metadata. I think you made a good argument, although I personally prefer the more mature XML tooling and metadata support for versioning.

> Nodes for data, attributes for metadata. Its a nice soundbite, but it ends up being less than useful in practice, because all metadata is data, and almost any data can be viewed as metadata, a distinction which is both subjective and strongly influenced by the use to which a consumer is putting the data rather than being determined on the basis solely of the inherent nature of the data.

Its a rule of thumb (heuristic). Judgement is still required.

(A soundbite is something altogether different.)

Re: Transit: JSON Data Interchange Format

#112

Post by togusa » Wed, Oct 14, 2015, 6:16 PM UTC

orless wrote: post #109

togusa wrote: post #26

Earlier quoted context omitted.

Well in this case, JSON schema doesn't specify any more fundamental types other than "number". On the receiving end of a wire or network contract, how do we pick a storage type for "number"? We can't because the constraints of the type are undefined. Ergo JSON schema isn't a strong schema language. Be explicit is really important when defining contracts. Type this in your address bar for an illustration: javascript:a…

Well, the `xs:decimal` example is quite interesting. In the XML Schema specification on xs:decimal ( http://www.w3.org/TR/xmlschema-2/#decimal ), you'll see the following note: All minimally conforming processors must support decimal numbers with a minimum of 18 decimal digits (i.e., with a totalDigits of 18). You have 32 decimal digits in 1.0000000000000000000000000000001, so "minimally conforming processors" are, a…

JSON doesn't define the number format or precision which is a major issue. It's not IEEE754, its a string of digits. What you have done is prove the point that it's implementation specific, in this case JavaScript.

You're right about decimal precision however so I conceded there but the precision and capability is defined.

Re: Transit: JSON Data Interchange Format

#113

Post by togusa » Wed, Oct 14, 2015, 6:19 PM UTC

orbitur wrote: post #107

zamalek wrote: post #43

Earlier quoted context omitted.

As soon as you are making a schema for JSON you've eliminated XML with no good justification. More and more, people are re-inventing XML on top of JSON: schemas, namespace, the works. JSON is great because when you don't need all the things that XML solves it's extremely succint and readable. Use any single copied feature from XML and it turns out being more verbose and less readable than XML. Use the right tool for…

"As soon as you are making a schema for JSON you've eliminated XML with no good justification" Sure, if you don't consider "human-readable" a good justification. Some of us do.

People moan about XML readability somehow forget that it uses approximately the same syntax as HTML. Imagine HTML in JSON. Nope...

Re: Transit: JSON Data Interchange Format

#114

Post by orless » Wed, Oct 14, 2015, 6:23 PM UTC

togusa wrote: post #112

orless wrote: post #109

Earlier quoted context omitted.

Well, the `xs:decimal` example is quite interesting. In the XML Schema specification on xs:decimal ( http://www.w3.org/TR/xmlschema-2/#decimal ), you'll see the following note: All minimally conforming processors must support decimal numbers with a minimum of 18 decimal digits (i.e., with a totalDigits of 18). You have 32 decimal digits in 1.0000000000000000000000000000001, so "minimally conforming processors" are, a…

JSON doesn't define the number format or precision which is a major issue. It's not IEEE754, its a string of digits. What you have done is prove the point that it's implementation specific, in this case JavaScript. You're right about decimal precision however so I conceded there but the precision and capability is defined.

I just see no big difference between xs:decimal and JSONNumber. None of them is defined precisely enough to guarantee unambiguous handling of numbers like 1.0000000000000000000000000000001.

Re: Transit: JSON Data Interchange Format

#115

Post by dragonwriter » Wed, Oct 14, 2015, 6:25 PM UTC

togusa wrote: post #113

orbitur wrote: post #107

Earlier quoted context omitted.

"As soon as you are making a schema for JSON you've eliminated XML with no good justification" Sure, if you don't consider "human-readable" a good justification. Some of us do.

People moan about XML readability somehow forget that it uses approximately the same syntax as HTML. Imagine HTML in JSON. Nope...

> People moan about XML readability somehow forget that it uses approximately the same syntax as HTML

No, they don't.

> Imagine HTML in JSON.

Yes, sure, JSON is a crappy text markup language, and would be much less readable than HTML for that purpose.

OTOH, readability when used as a markup language for content consisting largely of prose text and readability when used as a structured serialization format for data that doesn't mostly consist of large blocks of annotated prose isn't necessarily the same thing.

Re: Transit: JSON Data Interchange Format

#116

Post by orless » Wed, Oct 14, 2015, 6:32 PM UTC

dragonwriter wrote: post #115

togusa wrote: post #113

Earlier quoted context omitted.

People moan about XML readability somehow forget that it uses approximately the same syntax as HTML. Imagine HTML in JSON. Nope...

> People moan about XML readability somehow forget that it uses approximately the same syntax as HTML No, they don't. > Imagine HTML in JSON. Yes, sure, JSON is a crappy text markup language, and would be much less readable than HTML for that purpose . OTOH, readability when used as a markup language for content consisting largely of prose text and readability when used as a structured serialization format for data t…

The point is, XML is quite good for unstructured, semi-structured and strongly-structured data and is more versatile from this point of view.

Re: Transit: JSON Data Interchange Format

#117

Post by dragonwriter » Wed, Oct 14, 2015, 6:36 PM UTC

orless wrote: post #116

dragonwriter wrote: post #115

Earlier quoted context omitted.

> People moan about XML readability somehow forget that it uses approximately the same syntax as HTML No, they don't. > Imagine HTML in JSON. Yes, sure, JSON is a crappy text markup language, and would be much less readable than HTML for that purpose . OTOH, readability when used as a markup language for content consisting largely of prose text and readability when used as a structured serialization format for data t…

The point is, XML is quite good for unstructured, semi-structured and strongly-structured data and is more versatile from this point of view.

> The point is, XML is quite good for unstructured, semi-structured and strongly-structured data

That's a highly-subjective and controversial point.

(To me, XML is the Java of data languages -- its a lot worse than the best alternative considered on its own for almost any purpose -- though the best alternative will vary by purpose -- but it has a fairly wide range of uses for which its not intolerably bad, and its often a better choice than its inherent features would suggest because of the strength and maturity of the ecosystem around it.)

Re: Transit: JSON Data Interchange Format

#118

Post by dec0dedab0de » Wed, Oct 14, 2015, 7:14 PM UTC

prodigal_erik wrote: post #82

dec0dedab0de wrote: post #69

Earlier quoted context omitted.

I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.

Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multip…

But no matter what format any bit of data is in, it should still be documented. Then any consumers of the data are going to have to convert it into a format that suits their language and application.

Re: Transit: JSON Data Interchange Format

#119

Post by zamalek » Wed, Oct 14, 2015, 7:47 PM UTC

dragonwriter wrote: post #117

orless wrote: post #116

Earlier quoted context omitted.

The point is, XML is quite good for unstructured, semi-structured and strongly-structured data and is more versatile from this point of view.

> The point is, XML is quite good for unstructured, semi-structured and strongly-structured data That's a highly-subjective and controversial point. (To me, XML is the Java of data languages -- its a lot worse than the best alternative considered on its own for almost any purpose -- though the best alternative will vary by purpose -- but it has a fairly wide range of uses for which its not intolerably bad, and its of…

> best alternative

For 100% of the XML feature-set I don't actually know of a viable alternative. If you are using XML for the right reasons and the right way (rare) there is currently little or nothing that can replace. That being said, there are a vanishingly small amount of problems that actually require XML - namespaces and extensibility are two of them.

Re: Transit: JSON Data Interchange Format

#120

Post by dragonwriter » Wed, Oct 14, 2015, 8:53 PM UTC

zamalek wrote: post #119

dragonwriter wrote: post #117

Earlier quoted context omitted.

> The point is, XML is quite good for unstructured, semi-structured and strongly-structured data That's a highly-subjective and controversial point. (To me, XML is the Java of data languages -- its a lot worse than the best alternative considered on its own for almost any purpose -- though the best alternative will vary by purpose -- but it has a fairly wide range of uses for which its not intolerably bad, and its of…

> best alternative For 100% of the XML feature-set I don't actually know of a viable alternative. If you are using XML for the right reasons and the right way (rare) there is currently little or nothing that can replace. That being said, there are a vanishingly small amount of problems that actually require XML - namespaces and extensibility are two of them.

> For 100% of the XML feature-set I don't actually know of a viable alternative.

Real problems rarely need 100% of the XML feature set to solve. The breadth of the feature set is why there are lots of problems for which XML is a tolerable solution based on its inherent features (which in turn is a big factor in why it has such a large ecosystem), but they often don't make it the best solution (especially before considering the ecosystem, which is important in choosing a tool, but not a reason to avoid developing a new alternative, since any new alternative is going to start with an ecosystem disadvantage, but with adequate inherent value should be able over time to gather an ecosystem of tools.)