> JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here.

XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

Yes, except that XML has a schema (XSD).

Ahem. http://json-schema.org/

Quoting http://json-schema.org/latest/json-schema-core.html: "This Internet-Draft will expire on August 3, 2013."

... which, by the way, does not mean that JSON Schema is bad or unusable. I actually quite like it, it has certaint elegance. Just not really standard.

That's an exterior thing. It's perfectly reasonable to talk about XML the schemaless markup language.

History repeats itself, after all.

XML is not schemaless. It was designed to be extensible through schemas. It's in the name, after all: eXtensible Markup Language.

XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Its type system is extensible through schemas.

> XML is not schemaless.

Yes, it is, though there are a variety of schema schemes that can be used with XML.

> It was designed to be extensible through schemas.

It was designed to be extensible through custom tags (in fact, all tags are custom tags); it can be optionally be restricted through the use of schemas, not extended.

> XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has.

Yes, it does, with an even smaller number of types. (Strings, with a couple different representations.)

> Its type system is extensible through schemas.

No, it isn't. Its structure can be constrained through schemas (XML Schema, Relax NG, etc.), which can provide a means of modeling a different type system on top of the data structure supported by XML, but that isn't really "extending" XMLs type system any more than using a Haskell compiler to generate x86 machine code is "extending" the type system of x86 machine code; its just providing a completely separate type system on a different layer.

Also, no matter how you view this, its not a distinction between XML and JSON, since you can do the same thing with JSON, and just as there are a variety of different schema standards that do this for XML, there are a variety that do the same thing for JSON.

Another important feature is stream-oriented caching of values. Essentially some range of opcodes in the stream language are reserved for referring to a cache of recently seen values. It's a "dynamic" encoding feature that's super beneficial for common payloads, like JSON API responses with lots of similar keys. This is something a protobuf/thrift-like should steal, as it can often be more efficient than vanilla field-number + value encoding.

> maps (with arbitrary scalar keys, not just strings)

Floating point keys just seem like a terrible idea.

> Floating point keys just seem like a terrible idea.

I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.

> floating point (with a defined precision)

If it's fixed-precision it's not floating point, it's basically an integer we interpret with a decimal point somewhere when we display it. If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.

> If it's fixed-precision it's not floating point

I'm not referring to fixed point, but fixed-size representation.

> If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.

I don't see what the problem is. Certainly, there's problems if you do certain floating point calculations and blindly look for the result as a key in a mapping, but that's not a problem with floats as keys, its a problem with that particular usage pattern.

> I'm not referring to fixed point, but fixed-size representation.

I'm still not sure what you mean as any IEEE floating point (which in reality all anyone uses) is fixed-size. If you decide to truncate, round, do w/e to this value, you may still not get exactly the same answer for similar computations or even the same computation on different machines. There isn't a reason you can't (well, shouldn't) do float_val == 0.0 -- it won't work in all circumstances.

Please explain your method of making sure float_val == 0.0 while retaining the essence of being floating point (i.e. not using fixed-point).

Even with a defined precision they're weird in that they "ought to" be modeling the reals and therefore lack computable equality.

Which makes it hard to write a well-defined hash.