On 2. Mar 2021, at 05:09, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > There's something I used to call "ASN.1 disease", but it applies equally to XDR, some uses of XML, and a lot of other systems used to define data structures used in communications. This is a complex subject. Trying to do formal description techniques right has been keeping us busy for half a century, and will continue to do so. The observation you make has been made by everyone watching the evolution of these techniques. Once you have a tool that helps you manage complexity, you can use that to mitigate the bad effects of complexity, or (what you call ASN.1 disease) to help you create more complexity. The tool is neutral with respect to that choice! Some real-world problems are complex, so a tool that helps manage that complexity is a good thing. Some of the tools in this space generate their own complexity. E.g., type systems in programming languages often require the addition of complexity to express the actual shape of the data being processed. That brought us the differentiation between information models (which describe the natural complexity of the information at hand) and data models (which describe the complexity of that information mapped into specific data structures). ASN.1 as the first major effort in describing the shape of data for interoperability of course didn’t have the benefit of things we have learned since 1983. The most important difference between data modeling as used in programming languages’ type systems and as used for interoperability is the need to evolve protocols. That need does occur in programming, too, but there is a big difference between evolving a system by a single actor and independently evolving parts of systems that are bound together by protocols. The premier data modeling language that the IETF has is YANG. YANG is still in the process of grappling with some of the issues arising in model evolution, and I’m sure that will be a major driving force for its own evolution. But the fact that the tool helps designers to think about evolution issues may be one of its major contributions. One of the interesting effects that I have seen over time is that experts for a specific modeling tool are often enthusiastic when they manage to express something in that tool that the tool wasn’t designed to support. Even if that way of doing things creates additional complexity, instead of just managing it. This is a bit of a Stockholm syndrome — if you have become the hostage of a description technique, and manage to negotiate a bit of freedom from your hostage takers, you may start to like what they are doing for you, forgetting that they are the hostage takers in the first place. It can be hard to free hostages that have arranged themselves in their hostage situation that way. So lamenting that more complex systems can be built now is like lamenting that society has become more complex because we now have transportation. And something is to be said for arranging things in a way that many things can be done by walking. But it is also important to understand what transportation issues are best solved by adding bicycles, cars, or tanks. (You may now guess where ASN.1 fits into that parable…) Grüße, Carsten
