The whole thing seems to be dead. There is one blog post from 2019 (https://internetobject.org/the-story/) and the Twitter account also was active only in 2019 (https://twitter.com/InternetObject).
Internet Object – A JSON alternative data serialization format
41–50 of 83 posts
Re: Internet Object – A JSON alternative data serialization format
#42Since strings don't need to be quoted, what happens during deserialization if you want the string "T"? Does this lead to the equivalent of the Norway-Problem of YAML [0]? Is the space between the key and the type necessary? If not, how to distinguish between objects and types? Does the validation offer some form of unions or mutual exclusion? [0]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
YAML and its "Arrays" are really broken. The problem I see with Internet Object is that it's also implying this kind of mechanism. Every time I read about new formats, they seem to get either the 1-n relations or the n-n relations implemented well, but not both. I guess that's what's so hard about map/reduce... Regarding YAML: somebody on HN mentioned his project DIXY a couple years ago, and it's much much _much_ eas…
> YAML and its "Arrays" are really broken.
Agreed. YAML does have some use cases. I find it useful when I want to manually write lots of JSON data for test scripts. But the format, because it tries to be concise, ends up to be hard to manually parse.
I don't consider YAML a good serialisation format.
Re: Internet Object – A JSON alternative data serialization format
#43Chuck Severance has a nice interview about JSON with Doug Crockford where Crockford argues that one of the main reasons his baby has been so successful is that it's unversioned. No new versions, no new features, no bloat, no compatibility issues
Re: Internet Object – A JSON alternative data serialization format
#44Are comments allowed in this format?
I would vote for that feature.
Also field-names which don't contain whitespace should not need to be quoted.
Re: Internet Object – A JSON alternative data serialization format
#45Since strings don't need to be quoted, what happens during deserialization if you want the string "T"? Does this lead to the equivalent of the Norway-Problem of YAML [0]? Is the space between the key and the type necessary? If not, how to distinguish between objects and types? Does the validation offer some form of unions or mutual exclusion? [0]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
The so-called "Norway Problem" of YAML is really the No-Way Problem of YAML. /s
Re: Internet Object – A JSON alternative data serialization format
#46I'm sceptical about the value proposition of this without seeing much more than a simple example that offers little over existing hypermedia+json/csv practices. If a compact columnar representation is what you're after to avoid having to repeat every field name in an array of objects (which CSV is good for) but you don't want to give up the ability to include metadata in your JSON, there are a ton of different ways f…
Looked for a spec, but couldn’t find it, so here’s a _guess_: there’s significant whitespace between the colon and the opening brace:
age:{int, min:20},
address: {street, city, state}
Of these two, I like neither, but would opt for the latter.
I also considered that min:20 implied the previous had to be a type, but I don’t see how that’s consistent with
active?:bool
tags?:[string]Re: Internet Object – A JSON alternative data serialization format
#47This is a very real problem being addressed here and I am intrigued by all the great comments in this thread.
In the Zed project, we've been thinking about and iterating on a better data model for serialization for a few years, and have concluded that schemas kind of get in the way (e.g., the way Parquet, Avro, and JSON Schema define a schema then have a set of values that adhere to the schema). In Zed, a modern and fine-grained type system allows for a structure that is a superset of both the JSON and the relational models, where a schema is simply a special case of the type system (i.e., a named record type).
If you're interested, you can check out the Zed formats here... https://github.com/brimdata/zed/tree/main/docs/formats
Re: Internet Object – A JSON alternative data serialization format
#48This is a very real problem being addressed here and I am intrigued by all the great comments in this thread. In the Zed project, we've been thinking about and iterating on a better data model for serialization for a few years, and have concluded that schemas kind of get in the way (e.g., the way Parquet, Avro, and JSON Schema define a schema then have a set of values that adhere to the schema). In Zed, a modern and…
Also, if any of you find problems with the Zed spec(s), we'd love to hear about them. "Now" would be a good time to make changes / fix flaws.
Re: Internet Object – A JSON alternative data serialization format
#49Since strings don't need to be quoted, what happens during deserialization if you want the string "T"? Does this lead to the equivalent of the Norway-Problem of YAML [0]? Is the space between the key and the type necessary? If not, how to distinguish between objects and types? Does the validation offer some form of unions or mutual exclusion? [0]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/
It seems to be a typed CSV, so whether `T` is interpreted as a string or a boolean presumably depends on the schema. That sounds slightly better than YAML, though it can easily break when you allow heterogeneous types (say, string or boolean).
T is quite dumb. The author should had at least used #t and #f from Scheme.
Re: Internet Object – A JSON alternative data serialization format
#50This is a very real problem being addressed here and I am intrigued by all the great comments in this thread. In the Zed project, we've been thinking about and iterating on a better data model for serialization for a few years, and have concluded that schemas kind of get in the way (e.g., the way Parquet, Avro, and JSON Schema define a schema then have a set of values that adhere to the schema). In Zed, a modern and…
Also, if any of you find problems with the Zed spec(s), we'd love to hear about them. "Now" would be a good time to make changes / fix flaws.
I'd like to see more examples and probably data serialized as zed.