4 ms·
Array is a more complex issue. The biggest issue is whether it can break existing parsers or not. Additionally, the extra typing for things like heterogeneous o
by snarf21 10y ago
Array is a more complex issue. The biggest issue is whether it can break existing parsers or not. Additionally, the extra typing for things like heterogeneous or nested arrays will require application code that understands the typing instead of leaving that up to the parser. I think the simplest rule for now would be to only allow homogeneous arrays. This is quite an interesting problem. (Other suggestions to send along a JSONSchema seem unrealistic and the beauty of JSON is its simplicity and brevity, nobody wants another XML)
{ homog1$ai : [2, 3, 4] }
{ homog2$as : ["a", "b", "c"] }
I don't love $ but _ is so much more likely to be used in a key name for clarity like first_name. I also doubt that many people end their keys with $type so there is unlikely to be a conflict. If they do, it is probably a code standard they are using internally anyway for a similar purpose. Personally, I think that things like jQuery, etc. have trained people to see $ as a marker for "identifier" that I think it feels pretty natural, at least at this point. Again, just my $0.02 and you're mileage may vary....
- bascule 10y agoPlease see this issue for homogenous typing of arrays: https://github.com/tjson/tjson-spec/issues/23 https://github.com/tjson/tjson-spec/issues/23 Also based on the feedback I've received, I'm putting together a full proposal for moving all type information to object keys, and fully typing all non-scalars (and nested non-scalars) in a way that will be friendlier to statically typed languages. That said, I don't think the "$" thing is going to happen.
- bascule 10y agoI've made a concrete proposal for moving type signatures exclusively to a postfix tag on object keys here: https://github.com/tjson/tjson-spec/issues/30 https://github.com/tjson/tjson-spec/issues/30