Hacker News Reader

Comment by progx | Hacker News Reader

Feel free to write a schema definition for json data (or use the existing). Why should this not be possible?

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:alert(1.0000000000000000000000000000001);

So where can we go here. Yep:

   { number: "1.0000000000000000000000000000001" }

which means we then break the encapsulation boundary of the metadata. Then we have a wire contract that says "this is a string" and a separate semantic contract that says "this is a decimal".

XML:

   <number>1.0000000000000000000000000000001</number>

Schema:

   <xs:element name="number" type="xs:decimal"/>

This is just one example. We can also serialize and deserialize complex self-relational composite types transparently at both ends of the channel.

This is a real world problem we encounter in the financial sector every day.

On Firefox, the maximum number of digits that yield values different to 1 are:

javascript:alert(1.000000000000001);

Otoh, what's the difference between

    { "number": "1.0000000000000000000000000000001" }

along with

    { "number": { "type": "ModelReal", precision: 64 } }

versus

    <number>1.0000000000000000000000000000001</number>

along with

    <xs:element name="number" type="xs:decimal"/>

In each case you have text data given meaning by an external semantics enforced via a schema. The real and unavoidable downside is that JSON actually contains a really lousy primitive. It wouldn't be bad except practically every implementation of JSON automatically performs a lossy coercion to IEEE floats.

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, according to spec, actually free to drop everying after 17th place after comma in this case.

You say "constraints of the type are undefined". I don't see how "double-precision 64-bit format IEEE 754 value" from ECMAScript spec is lesser defined than "decimal numbers with a minimum of 18 decimal digits".

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.

Reply on news.ycombinator.com