On Mon, Dec 2, 2013 at 5:48 PM, Nico Williams
<nico(_at_)cryptonector(_dot_)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/