On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams <nico@cryptonector.com> wrote: > On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote: > > 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. > > But it can be part of the on-the-wire description. See below. > > > 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. > > Self-description is a continuum. Some ASN.1 encoding rules can encode > 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/
Received on Tuesday, 3 December 2013 00:08:00 UTC