On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:But it can be part of the on-the-wire description. See below.
> Since we are talking about a serialization format, the distinction between
> unordered sets and lists cannot occur at the wire level and this is where
> we need interoperation.
Self-description is a continuum. Some ASN.1 encoding rules can encode
> One of the things I think we have learned from JSON is that a
> self-describing format only needs to specify the abstract type of the datum
> and not the representation.
quite a bit of a schema on the wire -- clearly there's a point at which
the resulting redundancy causes problems. But it's also true that
having a large subset of the schema in the serialization can be useful
(e.g., for generic "dump" tools).
Given the prevalence of languages like Python, a "set" type will no
doubt seem useful to some! Heck, the ability to use non-string values
as keys (names) for objects would be nice too -- anyone who's spent much
time with Python and JSON has wished for these things. JSON alone is
insufficiently expressive for "pickling" Python values; JSON with a fair
bit of convention layered on gets closer to being good enough for
pickling Python values.
Well that is a rather different situation, the language allows for polymorphic typing and does not have a clue what the native data type of the entries it exchanges is.
I agree that there is a utility in that information for pickling data values but it is not an approach I would like to see in an application protocol.
The way I would approach this if necessary would be to add in a tag that could be used to annotate the data with additional type hints.
Website: http://hallambaker.com/