Hi Mike, But I definitely need to re-do the documentation. http://plc4x.apache.org/developers/code-gen/protocol/mspec.html
I had started writing it before I did a big extension and refactoring … I really hope I finally will get the chance to work on this again very soon. Chris Von: "Beckerle, Mike" <mbecke...@tresys.com> Datum: Mittwoch, 30. Oktober 2019 um 17:32 An: Christofer Dutz <christofer.d...@c-ware.de>, Julian Feinauer <j.feina...@pragmaticminds.de>, "d...@plc4x.apache.org" <d...@plc4x.apache.org> Betreff: Re: ASN.1 ECN Chris, Thanks for this. Very useful. When I look at that ASN.1 ECN definition I have the same reaction to it that I'm sure many non-XML people have to XML Schema and DFDL, which is there is much to learn, and so little of it seems relevant to the immediate problem. As soon as a description gets complex enough, it starts to lose its declarative value. I think intellectually, we need to find a small, but representative piece of data and schema that has what you refer to as the "parsing semantics" of the message - the interesting calculations that are fundamental to really expressing *all* of the format information. Then we need to express it in DFDL and in ASN.1 ECN best we can so we can have a side-by-side comparison that is really helpful. What is the smallest, simplest format that you have seen that you think represents this? Do you have a description of it in MSpec as yet? Thanks Mike Beckerle ________________________________ From: Christofer Dutz <christofer.d...@c-ware.de> Sent: Saturday, October 26, 2019 9:42 AM To: Julian Feinauer <j.feina...@pragmaticminds.de>; d...@plc4x.apache.org <d...@plc4x.apache.org> Cc: Beckerle, Mike <mbecke...@tresys.com> Subject: Re: ASN.1 ECN 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 <j.feina...@pragmaticminds.de> Datum: Samstag, 26. Oktober 2019 um 10:09 An: "d...@plc4x.apache.org" <d...@plc4x.apache.org> Cc: "Beckerle, Mike" <mbecke...@tresys.com>, Christofer Dutz <christofer.d...@c-ware.de> 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" <mbecke...@tresys.com> Datum: Samstag, 26. Oktober 2019 um 06:32 An: Christofer Dutz <christofer.d...@c-ware.de>, Julian Feinauer <j.feina...@pragmaticminds.de> 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
