Disallow arbitrarily nested Boolean formulae

[rakhimov]

The MEF allows writing complex, nested Boolean formulae to define gates.
It is indeed very general and powerful,
but do the MEF and model developers need this power?
There is no reasoning in the standard justifying this complexity.

I can't find any FTA software currently supporting this MEF feature
except for SCRAM.
Having implemented this "feature" in SCRAM,
I concluded that this approach requires
a fundamentally different treatment of gates and input events.
It is peculiar to the MEF and confusing to users.
It is hard/impossible to represent graphically with traditional methods
without unconventional approaches
(phony gates/circuits/textual formula).

I reckon wiser people already avoid such complexity.
Excerpt from XFTA manual:

Nothing prevents to use nested formulae
(such as a ‘and’ of ‘or’ of events).
However, a best practice recommended by all safety standards is
to introduce an intermediary event per logical gate.
The only exception to this rule is negations,
as illustrated in our example...

Following the wisdom,
the MEF schema is modified to allow
only events or negations of events -- not formulas --
as Boolean formula arguments.
Note this only requires a schema/grammar change,
no specification wording is needed
because the original nested-formula is not specified in the first place.

[cfolleau]

Our computation engine handle it, but our user interface contains only "usual" gates, since no human behing use gate with formula.
But I am not sure it can be deleted without asking everybody, especially people generating fault tree from other models.

[rakhimov]

There's one place the MEF implicitly assumes nested formulas:
event tree collect-formula instruction.

The collection of a top event consists in a Boolean product of the formula
associated with the sequence and a copy of the fault tree rooted with the top event.
In the Model Exchange Format,
the operation is performed by means of the instruction "collect-formula".

However, this collection approach can be left as an implementation detail.
For example, the collected nested formula can always be turned into "phony" (internal) gates,
which actually aid logging and debugging.
Anyway, the collected formulas are unlikely to be comprehensible by users in their final form.