Reinventing XML, one data type at a time.
First thing that came to my mind...
Transit: JSON Data Interchange Format
61–70 of 124 posts
Re: Transit: JSON Data Interchange Format
#62> The extension mechanism is open, allowing programs using Transit to add new elements specific to their needs. Users of data formats without such facilities must rely on either schemas, convention, or context to convey elements not included in the base set,
The extension mechanism is writing handlers in all languages communicated with, since its stated purpose is cross language value conveyance.
In contrast, a schema language allows extensions to be described once, in one language.
I was expecting this to be a sort of macros for data notation (an inline schema language), but it seems more like an extendible serialization library.
Re: Transit: JSON Data Interchange Format
#63Earlier quoted context omitted.
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.
True, 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...
That's not the problem I'm outlining. It is that semantics around type handling are implied rather than specified by schema.
Re: Transit: JSON Data Interchange Format
#64Reinventing XML, one data type at a time.
My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?
XML is eXtensible (via DTD or XS), but JSON is a better Object Notation than any Markup Language.
Re: Transit: JSON Data Interchange Format
#65Not sure I like the idea of cramming ASCII type tags in to the encoded JSON.
I'm more partial to the way Avro does it, where the encoded JSON remains type-tag and cruft free, and a separate schema (also JSON) is used (and required) to interpret the types, or encode to the correct binary encoding.
Re: Transit: JSON Data Interchange Format
#66I can't help but wonder if it isn't simpler just to use gzipped JSON. I'd be interested to see a size comparison of the two. It seems like they're going to an awful lot of work to hand-roll a suboptimal text compression scheme here.
It's the whole FAST/FIX clusterfuck all over again. Use a binary format and stop cocking around. You can't serialise/deserialise it faster and JSON is a string based mess. No low latency path can absorb it. Even influxdb have removed JSON support because it was their slowest part of their critical path that could not be optimised. Complete lack of mechanical sympathy + laziness is why JSON is popular outside of the w…
Easy there tiger ;)
What does it even mean that something is string based?
Here: https://github.com/eishay/jvm-serializers/wiki a JVM bench where JSON is pretty competitive with binary formats [and results would be event better if project owners actually merged PRs ;( ]
Re: Transit: JSON Data Interchange Format
#67Earlier quoted context omitted.
My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?
I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays. And now with Schemas and editor support for them, I think it is an acceptable replacement personally.
Explicit arrays are what I consider the most important advantage of JSON over XML. In XML, every element is repeatable by default and only out-of-band specification can restrict cardinality. Two bytes extra per array, that convey so much structural self-documentation that is just not there in an XML document.
So JSON succeeded because XML is not verbose enough? Really did not see that one coming.
Re: Transit: JSON Data Interchange Format
#68Earlier quoted context omitted.
I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays. And now with Schemas and editor support for them, I think it is an acceptable replacement personally.
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.
It's hardly answers the question, as strictly speaking there's no such thing as "metadata". Everything you can pass to another person can be described as "data", whether it is a color of your coat or the statement that you are describing the color of your coat. Basically, you can think of any attribute of an object as "metadata" as long as it can be only one per object and doesn't have any attributes itself, and both things can change easily and depend on the point of view.
On the contrary, I don't remember one single case when the object was described easily using "node/attribute" separation, but couldn't be described as easily using JSON. In fact, I don't even think it's possible, as you can always make two children for each object: "attributes" and "nodes".
So I guess it actually is unnecessary complication and not the benefit of using XML over JSON.
Re: Transit: JSON Data Interchange Format
#69Earlier quoted context omitted.
JSON is pretty great to parse in a variety of (web-relevant) languages. And it's a good data exchange format if you're okay with its loose typing. But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…
Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?
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.
Re: Transit: JSON Data Interchange Format
#70Earlier quoted context omitted.
True, 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...
That's not the problem I'm outlining. It is that semantics around type handling are implied rather than specified by schema.
I 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.