I was on the
ASN.1 ISO/ITU-T working group for a while (during the development of
XER), and I felt there was perhaps a bit of pressure from WG members who
had successful businesses selling ASN.1 tools to keep it complicated so
that tools would be required :-)
I'm glad to hear you have background in it, and I hope you think my radical simplification not of ASN.1 DER itself but of all the stuff around it to match dynamic languages makes sense.
I think a general scheme-value interchange format needs to have some
idea of how common SRFI abstract types are encoded - from timestamps to
hash tables and so on. Not even s-expressions really have that!
Exactly.
Perhaps
if the Scheme community takes data portability more seriously, it will
become the norm for the SRFIs for those types of things to also define
s-expression and binary encodings, and the reference implementations
will be expected to register codecs for s-expression and binary
representations of them (with the thorny issue of how to ensure there's
no conflicts in the "type codes" used).
Fortunately, such a registry could easily be maintained by the SRFI editor. Beyond a subset of those standardized by X.690, right now I am proposing to allocate 16 of the 31 available 1-byte codes (C0-DE) for binary data, and 9 of the 31 available 1-byte codes (E0-FE) for compound data. Beyond those there are 97 2-byte type codes of each kind available (DF or FF followed by 1F through 7F). That's a LOT of data structure SRFIs.
(Arthur, would you in fact be amenable to maintaining my spreadsheet permanently if and when the time comes? It would just mean adding rows when new SRFIs specified that they should be serializable to a binary format.)
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgWhile staying with the Asonu, I met a man from the Candensian plane,
which is very much like ours, only more of it consists of Toronto.
--Ursula K. Le Guin, Changing Planes