Hi Julian and others. Yes I did have a look as ASN.1, however I had the impression that this only specifies the syntax of the packets themselves … it has no means to specify parsing semantics. With MSpec we have the ability to also define these semantics … If we had used ASN.1 it would have generated models and parsers with every bit of information being included in the POJOs. When serializing we would have had to manually handle and prepare all the data.
For example the “implicit” fields … in MSpec we can say “headerLength is calculated by taking the total size in bytes, subtract the payload size in bytes and subract 2 more” with ASN.1 we would have had to do these caltulations ourselves. Same with the discriminated types … here some data is implicity specified by the type itself (discriminators) … also the handling of optional fields and how to parse lists/arrays would have been challenging. My evaluation might not have been 100% correct, but definitions like this did sort of scare me: https://www.itu.int/ITU-T/formal-language/itu-t/x/x692/2008/Example3-EDM.html Chris Von: Julian Feinauer <[email protected]> Datum: Samstag, 26. Oktober 2019 um 10:09 An: "[email protected]" <[email protected]> Cc: "Beckerle, Mike" <[email protected]>, Christofer Dutz <[email protected]> Betreff: Re: ASN.1 ECN Hi Mike, thanks fort he question which was also asked at ACEU, thus I’m bringing the discussion to the dev list. Can you comment on that Chris? You did most of the evaluation. Julian Von: "Beckerle, Mike" <[email protected]> Datum: Samstag, 26. Oktober 2019 um 06:32 An: Christofer Dutz <[email protected]>, Julian Feinauer <[email protected]> Betreff: ASN.1 ECN For format description in PLC4X, did you consider ASN.1 Encoding Control Notation? This is an ISO standard. I have not used it, but it checks the boxes of being a standard, being a grammar + rich library of primitives annotated on it, etc. If you did not consider it, or did and found it unsuitable, I'm interested in why. ...mike beckerle Tresys/Daffodil
