Re: [hackathon] Formal Languages at the Hackathon

[Carsten Bormann <[e-mail]>]

On Nov 6, 2019, at 17:52, Antoni Przygienda <prz=[e-mail]> wrote:
> 
> enhance GRPC or thrift

There are several of these integrated modeling language + encoding scheme ecosystems we could latch ourselves up to.  Actually we did that already with ASN.1 a long time ago, and it is interesting what people who have used it for a few decades now think about it (*).

Obviously there are some requirements for data modeling (mostly around handling evolution) that are better served by using a mature FDT approach than by graphical representation of various encoding stages (the “box notation” we love from RFC79x etc.).  

When the encoding dominates your thinking, they get in the way (e.g., look at how HTTP/2 is encoded).  So being able to describe an arbitrary bespoke encoding with an FDT (like Quentin’s work or YOUPI do, within the limits of their expressibility) may be useful in those spaces.

When the complexity of the data being modeled dominates your thinking, you want a solid encoding scheme such as XML or JSON or CBOR (or you can do the latch-up alluded to above).
For standards that are expected to live for a while (“design for decades”), I prefer situations where the encoding scheme has a life of its own, independent of the FDT, so you can swap your FDT if the old one is broken (just as we moved from W3C XSD to Relax-NG for most XML work).  The integrated approaches may have their own advantages, especially in the time-to-market department, while usually wedding you to a specific toolchain (or tool ecosystem, as with ASN.1).

Grüße, Carsten

(*) Especially after you compensate for the inevitable occurrence of Stockholm syndrome.