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?
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:
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.