6 ms·
Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several langua
by togusa 11y ago
Enterprise here. We like XML because it's explicit.
{ number: 1.0000000000000000000000000000001 }
Try parsing the above JSON consistently in several languages without a consistent schema definition.
- progx 11y agoFeel free to write a schema definition for json data (or use the existing). Why should this not be possible?
- togusa 11y agoWell 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.
- Tepix 11y agoOn Firefox, the maximum number of digits that yield values different to 1 are: javascript:alert(1.000000000000001);
- tel 11y agoOtoh, 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.
- orless 11y agoWell, the `xs:decimal` example is quite interesting. In the XML Schema specification on xs:decimal (http://www.w3.org/TR/xmlschema-2/#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".
- togusa 11y agoJSON 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.
- orless 11y agoI 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.
- nadam 11y agoThen use this instead: { number: "1.0000000000000000000000000000001" } How is it worse than XML?
- togusa 11y agoSee: https://news.ycombinator.com/item?id=10385610 https://news.ycombinator.com/item?id=10385610
- nadam 11y agoOk, now I see that you are complaining that the JSON Schema language is not strong enough. In this case I think people should create better new schame languages for JSON, as I find that the JSON syntax is better suited to data than XML, which is better suited to marked up text. (maps, arrays and atomic literals are fundamental data concepts, while tags, attributes, free text are closer to mark-up. )
- togusa 11y agoThe thing with XML is it's actually much lower level. There are no types inferred by an XML document. It's literally just chunks of data. JSON defines strings, boolean, maps, arrays, numbers. It's conceptually easier to think about JSON with simple data sets but it's terribly inflexible and you have to think about how things are represented inside strings. A couple of thought exercises on JSON: 1. How do you represent an image inside JSON? 2. How do you represent a reference to another part of the data in JSON (consider a DAG for example)? 3. How do you represent an ordered set or an unordered set in JSON? 4. How do you represent an unsigned value in JSON?
- deleted 11y ago[deleted]
- zamalek 11y agoAs 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 the job.
- neoeldex 11y agoTry creating that number is several languages. #/usr/bin/python n = 1.0000000000000000000000000000001 print n # 1.0 //Javascript n = 1.0000000000000000000000000000001; console.log(n); // 1
- icebraining 11y agofrom decimal import Decimal n = Decimal("1.0000000000000000000000000000001") just because float is the default, doesn't mean you have to use it. JSON doesn't have anything else, though.
- orless 11y agoJSON does not have float (nor double) either. JSON has JSONNumber.
- aldanor 11y agoIt's not valid JSON to start with.
- deleted 11y ago[deleted]
- togusa 11y agoI know. This was intentional and I'm glad someone noticed it finally. Run it through JSON lint ( http://jsonlint.com/ http://jsonlint.com/ ), then fix the error (unquoted number text), then run it again and watch the data loss occur due to my original point...
- oneeyedpigeon 11y agoTrue, any problem domain that requires accuracy to 31 decimal places might not be best suited to JSON. I wonder how many decimal places would be required to represent the percentage of projects that would actually be affected by that...
- togusa 11y agoThat's not the problem I'm outlining. It is that semantics around type handling are implied rather than specified by schema.
- oneeyedpigeon 11y agoI don't understand your point. The semantics around type-handling are very clearly defined in the JSON spec: a number is simply a series of digits (plus decimal point, - sign, etc.). If you choose to interpret that JSON in a language with less than infinite precision, then you need to accept that some data loss can occur. That will happen if you're mushing an XML string into a number type, too.
- orless 11y agoI'm also not sure I'm getting you. In JSON, types can be unambiguously deferred by syntax/via gramar. You can't mistake JSONString for JSONNumber/JSONNullLiteral/JSONBooleanLiteral, the type is absolutely clear from the syntax. So I don't see how a schema would help here. What would the schema express? Surely not "this is a number" as it is clear without the schema. What then? And what exactly do you mean by "semantics around type handling are implied", especially in `{ number: 1.0000000000000000000000000000001 }` case?
- deleted 11y ago[deleted]