Page "EDIF" Paragraph 67

In designing EDIF 3 0 0, the committees were well aware of the faults of the language, the calumny heaped on EDIF 2 0 0 by the vendors and the frustration of the end users.

So, to tighten the semantics of the language, and provide a more formal description of the standard, the revolutionary approach was taken to provide an information model for EDIF, in the information modeling language EXPRESS.

This helped to better document the standard, but was done more as an afterthought, as the syntax crafting was done independently of the model, instead of being generated from the model.

Also, even though the standard says that if the syntax and model disagree, the model is the standard, this is not the case in practice.

The BNF description of the syntax is the foundation of the language inasmuch as the software that does the day-to-day work of producing design descriptions is based on a fixed syntax.

The information model also suffered from the fact that it was not ( and is not ) ideally suited to describing EDIF.

It does not describe such concepts as name spaces very well at all, and the differences between a definition and a reference is not clearly describable either.

Also, the constructs in EXPRESS for describing constraints might be formal, but constraint description is a fairly complicated matter at times.

So, most constraints ended up just being described as comments.

Most of the others became elaborate formal descriptions which most readers will never be able to decipher, and therefore may not stand up to automated debugging / compiling, just as a program might look good in review, but a compiler might find some interesting errors, and actually running the program written might find even more interesting errors.

( Additionally, analogous EXPRESS compilers / executors didn't exist when the standard was written, and may not still exist today!