On Mon, Mar 01, 2021 at 05:34:55PM -0800, Larry Masinter wrote: > JSON-LD seems to fit modern needs from an extensibility / simplicity point > of view. I know nothing about JSON-LD. > All the bit-packing goodness of various encodings are dreadful from an > interoperability point of view. > Rich formalisms and separation of syntax and "encoding rules" seem > counter-productive. The nicest thing about XML is XSLT/XPath, and the nicest thing about JSON is jq. Such languages are probably only feasible when you have loose typing, which XML and JSON do. And loose typing does arguably mean dispensing with the formalisms that force static typing. That said, and as much as I love jq, for all the protocols I work on I would much rather have static typing and rich formalisms. Especially in security protocols, I'd rather have rich formalisms. As always, one should use the right tool for the job. (FWIW, I used to maintain jq and might again, and I maintain an ASN.1 implementation.) I don't see how separation of syntax and encoding can be counter- productive: alternative syntaxes are always possible, and transcoding is generally possible, and people often have to do these things for some reason. As to "bit-packing"... have you noticed that every textual encoding eventually evolves a binary adaptation? XML has FastInfoSet. JSON has a multitude of binary encodings (at least three). Parsing textual encodings isn't easy, and much less parsing them efficiently. Parsing dynamically typed data requires more overhead than parsing statically typed data. Parsing JSON efficiently is really hard. Parsing anything without a schema shifts a lot of burden onto the developer, unless the developer is using something like jq. People have devoted a lot of effort to using SIMD to parse JSON more quickly than can be done on a traditional CPU, but IIUC there are no online JSON parsers that use SIMD -- no one would bother doing this for XDR because there is no need. XDR was always simpler to compile or hand-roll codecs for than TLV encodings, and definitely than textual encodings. I've never heard a bad thing uttered about XDR. It turns out that once you've parsed the syntax into an AST it's pretty trivial to generate codecs (possibly bytecoded) regardless of the encoding rules' nature. XDR being so much simpler than TLV types because of the absence of tags and wasteful lengths, was always easy to handle, but what made it easy was not having any crutches and so having to have parsed the syntax defining the types one needed to encode. There's a lot of hand-rolled XDR out there as well, including some I look after, because it's much easier to hand-roll XDR than TLV encodings, and certainly than textual ones. NDR's pointer dedup feature made it much harder to implement, but otherwise it's really similar to XDR. OER and PER are not too dissimilar to XDR, so they're probably comparable to XDR in implementaiton complexity. Nico --
