Ignoring our current extensions attribute, which is a map, and data, all other attributes are strings, or some restricted version of a string (like a timestamp or URI). Given that we need to support converting all of our properties (except data) into HTTP headers I wonder if it wouldn't make sense to just require everything to be strings (or restricted strings). Granted, given our current state of the spec, this isn't actually that much of a change but it would mean a few things:
- our type system would go away since we only have one type
- we don't need to worry about extensions that might be numeric and not knowing if an HTTP header of
foo: 1 means { "foo": 1 } or {"foo": "1"} w/o some additional knowledge.
- it forces a more simplistic model by not even considering generic Objects/Any types. However, like HTTP headers, people can encode more complex types as strings if they want, but that's out of scope for our spec to deal with - the spec of that extension would need to define how to (de)serialize things.
What do people think?
Ignoring our current
extensionsattribute, which is a map, anddata, all other attributes are strings, or some restricted version of a string (like a timestamp or URI). Given that we need to support converting all of our properties (exceptdata) into HTTP headers I wonder if it wouldn't make sense to just require everything to be strings (or restricted strings). Granted, given our current state of the spec, this isn't actually that much of a change but it would mean a few things:foo: 1means{ "foo": 1 }or{"foo": "1"}w/o some additional knowledge.What do people think?