The formula looks very wrong.
Moreover, the description seems to assume normalized weights
and discusses weights in a non-conventional way (E_i vs w_i).
Density Prob. Distributions and Discrete Prob. Distributions are confusingly mixed-up.

The words (and, or, not) are cluttering the formulas for the gates.

Currently, the discrete distribution is simulated with a histogram distribution.
This approach is clunky
because the input processing/visualization/analysis tools cannot tell
that the histogram is actually not a histogram but a discrete distribution.
Moreover, analysis tools could use more efficient approaches for truly discrete distributions.

at-least would capture the correct spelling.
atleast is being flagged by many tools and API usages.

Why is 'atleast' favored?

The "unit" attribute and values of parameters (and mission time)
are underspecified, raising many questions, such as:

1. Is it just for informational purposes?
2. Is it meant to give types for expressions (related to #39)?
3. Does the standard imply proper unit conversions in expressions?
4. What happens if units don't match?
5. What is the default unit for parameter and mission time?

Let's say, we have parameter lambda in inverse years
and assume that mission-time is in hours:

    <define-parameter name="lambda" unit="years-1">
        <float value="1e-7"/>
    </define-parameter>

Should there be implicit unit conversion (from years-1 to hours-1)
upon the parameter use?
Or mixing these parameters is an error?

    <exponential>
        <parameter name="lambda"/>
        <system-mission-time/>
    </exponential>

What happens if at the reference site, the parameter unit is different?

    <exponential>
        <parameter name="lambda" unit="hours-1"/>
        <system-mission-time/>
    </exponential>

Should units be checked for all expressions?
Probability should have no units, so should the following fail?

    <define-basic-event name="pump">
        <parameter name="lambda"/>
    </define-basic-event>

Moreover, for some reason (maybe for question 2),
the MEF "units" have bool, int, float,
which are not units of measurement.

The automatic conversion may be lossy,
so manual editing is required to ensure correctness.

• Separate chapters into files
• Verify the equality

Latex/sphinx table head styling issues:
sphinx-doc/sphinx#2832

From the MEF Fault Tree description (chapter 4, section 1):

If a variable or a parameter is declared more than once,
tools should emit a warning
and consider only the last definition as the good one (the previous ones are just ignored).

This is strange for a declarative modeling language
since now the order of declarations matters.
It is more like assignments of imperative languages.

As tested with XFTA,
it doesn't allow 'redefinition'.
I went this direction as well with SCRAM.

I could imagine many subtle analysis discrepancies
due to the allowance of redefinitions.
Imagine working with multi-file models.
Now if the order of files is changed or not remembered,
the analysis may be inconsistent
if it contains redefinitions spread across files.

What are the semantics of referencing only one gate node in the define-gate node?

<define-gate name="Line1.VI.vfRightFlow_false" >
    <gate name="TK.vfOutFlow_false" />  
</define-gate>

I generated a Fault Tree (FT.xml) containing the above fragment using the example from the tutorial .
After sorting it out, I found:

• Basic Events
  

• Line1 & Line2 Fault Trees
  

• Reactor Fault Tree
  

• Similar to the fragment list mentioned earlier

<define-gate name="Line1.VO.vfRightFlow_false" >
    <gate name="Line1.P.vfOutFlow_false" />
  </define-gate>
<define-gate name="Line1.P.vfOutFlow_false" >
    <gate name="Line1.P.vfInFlow_false" />
  </define-gate>
<define-gate name="Line1.P.vfInFlow_false" >
    <gate name="Line1.VI.vfRightFlow_false" />
  </define-gate>
<define-gate name="Line1.VI.vfRightFlow_false" >
    <gate name="TK.vfOutFlow_false" />
  </define-gate>

<define-gate name="Line2.VO.vfRightFlow_false" >
    <gate name="Line2.P.vfOutFlow_false" />
  </define-gate>
<define-gate name="Line2.P.vfOutFlow_false" >
    <gate name="Line2.P.vfInFlow_false" />
  </define-gate>
<define-gate name="Line2.P.vfInFlow_false" >
    <gate name="Line2.VI.vfRightFlow_false" />
  </define-gate>
<define-gate name="Line2.VI.vfRightFlow_false" >
    <gate name="TK.vfOutFlow_false" />
  </define-gate>
<define-gate name="TK.vfOutFlow_false" >
    <gate name="TK.vsIsEmpty_true" />
  </define-gate>
<define-gate name="TK.vsIsEmpty_true" >
    <basic-event name="TK.evGetEmpty" />
  </define-gate>

Question

How to connect Reactor Fault Tree to Line1 and Line2's Fault Tree? Which key information in the fault tree file did I ignore?

Since the grammar inside of the standard is described with the EBNF,
this transition would only require swapping the DTD with RNC in Appendix B.
Additionally, it would need appropriate wording in introduction to justify the EBNF.

The MEF specification doesn't discuss or implicit about
Expressions' parameter and return value types.

Example 1.

<parameter name="type-unsafe">
    <div>
        <int value="42"/>
        <bool value="true"/>
    </div>
</parameter>

Strictly, Example 1 expression doesn't make sense.
This would produce type errors in strongly-typed system (e.g, Haskell);
however, weakly-typed languages would succeed with implicit bool->int conversion.

Example 2.

<parameter name="integer-div">
    <div>
        <int value="42"/>
        <int value="4"/>
    </div>
</parameter>

<parameter name="float-div">
    <div>
        <float value="42"/>
        <float value="4"/>
    </div>
</parameter>

Example 2 is overloading with integer division returning integer
and float division returning float;
Note that these overloads return different values (10 vs. 10.5)
and have different semantics
even though the argument values are equal.

Example 3.

<parameter name="implicit-cast">
    <ite>
        <int value="42"/>  <!-- This is condition -->
        <float value="1.0"/>
        <int value="1"/>
    </ite>
</parameter>

Examples 3 would produce type errors in strongly-typed system,
weak system would convert 42 into true and succeed;
moreover, due to type mismatch in different arms of the expression,
the return type is float.

The simplest solution from specification and implementation points of view
is to adopt the weak typing of the C language with no overloading.
If an Expression needs to be generic (e.g., div, mul),
the parameter and return types can be float.

I suspect that the MEF authors being C programmers
assumed the C-type system for numbers but forgot to mention it :).

As it is currently specified, the custom "include" specification is completely redundant.
The difference between native XML directives and the custom opsa-mef include
is worded to be only in that opsa-mef doesn't require the file to be physically included within context
but "loaded".
This feature actually makes automatic validation with schema extremely hard;
that's why both XML entity include and XInclude actually physically include the snippet.
Given today's availability of computing power and memory,
the reasoning for the custom "include" feature seems outdated.
The current XML tools can handle opsa-mef models with 1 million basic events/gates with 1 GiB memory without much problem.

Alternatively, conforming tools should be able to accept multiple files at once for analysis.
Why should the whole model be described with a single file?

If this custom feature was intended to mimic the run/analysis configuration file for software
(that is, providing a set of input files),
then it should be specified that way.

The specification of the Histogram distribution suggests
converting Cumulative distribution to its corresponding probability density histogram.
The approach is cumbersome
if one considers transferring the output of one analysis as input to another.

The piecewise linear distribution provides more general/flexible facility
to express cumulative and other distributions.
It could also be used to approximate continuous/complex distributions if needed
as an alternative to the histogram distribution.

However, if the piecewise linear distribution is not dedicated to cumulative distributions only,
the dual role (pdf and cdf) for the same construct is ambiguous.
The MEF can specify a special attribute for this distribution
to discern between the distribution types (density vs. cumulative).

• PDF
• html
• LaTeX

This is probably an error of omission. ambigious
The "model-data" container is not specified to be located within <opsa-mef></opsa-mef>
as the other containers (fault tree, etc.).
The model diagrams, BNF, and the original DTD have the "model-data" separate from the opsa-mef declaration.
If this is the intended specification,
the reasoning is not clear (why is it outside of "opsa-mef"?).
If it is an error omission,
should it be specified to be located just like other containers, i.e.,

opsa-mef = element opsa-mef { (fault-tree-defition | event-tree-definition | ... | model-data)* }

or should there be only one model-data per input file

opsa-mef = element opsa-mef { (fault-tree-definition | ...)*, model-data? }

Issues with sphinx by default not generating section numbers in titles.
sphinx-doc/sphinx#3210

The description of the Log-Normal distribution in the MEF is given specifically for one level only
without providing a general formula for all levels.
If the EF is defined only for 95% level, why does the MEF provides the "level" variable?

In fact, the EF parameter is very strange to me because I haven't seen this parameter in the definition/description of the log-normal distribution in statistics.
This EF factor seems to be defined in PRA/PSA literature only.
Honestly, this EF feels like another misnomer (e.g., fault tree, cut set) coming from the PRA.
Let me explain why I have the suspicion.

1. How on Earth, the 95% z of the standard normal distribution is 1.654 (Safety and Reliability: Proceedings of ESREL 2003, European Safety ..., Volume 2) (http://nrcoe.inl.gov/radscalc/Pages/AboutHTMLFiles/Distributions.htm) ?
   It must be 1.96.

2. Why is the general formula/theoretical discussion absent?

This is my guess for the general formula:

So the EF description in the MEF would be for 90% level.

Please destroy me!

The current specification for random deviates allows
parameters of the deviates to be random deviates themselves.
I am not sure whether this was intended.

Should the parameters be restricted to non-deviate expressions,
or should random deviates be specified to use the mean value of their arguments?

Contractions are the closest thing to hip talk I can use without just sounding silly.
-- Paula Poundstone, There's Nothing in This Book That I Meant to Say. Three Rivers Press, 2006

The current specification for MEF attributes functionality
does not explicitly state whether it allows duplicates or not.
Is it implicitly unique? (like XML attributes or Object attributes/properties)

The situation with duplicates would be complicated
because variables can inherit and override container attributes.

Consider the following example:

<opsa-mef>
  <define-fault-tree name="tree">
    <attributes>
      <attribute name="room" value="42"/>
      <attribute name="room" value="13"/> <!-- Error? -->
    </attributes>

    <define-basic-event name="pump">
      <attributes>
        <attribute name="room" value="66"/>
      </attributes>
    </define-basic-event>
  </define-fault-tree>
</opsa-mef>

If duplicate attributes were allowed,
which 'room' attribute would event 'pump' override? (all of them?)

An analogy for the dilemma can be set vs. multiset.
It is just not clear/explicit what the MEF wants.

This issue came up because handling of non-coherent models by some popular software packages
is such a joke that it is not even funny. Seriously.

Unfortunately, the current standard does not formally specify MCS or PI.

Since it was noted in the past
that tools tend to approach non-coherent models differently
and produce disagreeing, inconsistent, or different results,
a precise specification of MCS and PI terms
would help the community with:

- cross-validation
- quality assurance
- unfounded reliance on approximations

Fortunately, Antoine Rauzy has already done
the hard part of mathematically defining the notions of MCS and PI:

A. Rauzy, "Mathematical foundation of minimal cutsets,"
IEEE Trans. Reliab. Eng. Syst. Saf., vol. 50, no. 4, pp. 389-396, 2001

The only thing left is to translate it properly into the human language
or reference these definitions in the MEF standard.

As the result of the clear specification,
a non-conforming software needs to precisely state
in what aspects it differs from the standard, mathematical definition;
otherwise, it would be misinforming the analysts
and shouldn't call the result MCS/PI
(call it degenerate-MCS, if it wishes, but not MCS).
In other words,
this specification would be a reference point for approximations.

Also, use ellipses (...) only for omissions.

Built-Ins:Extern functions:

The Model Exchange Format should provide a mean to call extern
functions. This makes it extensible and allows linking the PSA assessment tools
with complex tools...

From the specification, I am assuming
that the Extern functions have a similar nature to C "extern" functions
to enable calls to functions from other libraries;
however, it is not clear how to specify the source tool/library.
In my understanding, this feature requires the name of a library with the function
to be loaded dynamically.
In case of dynamic loading,
what should the expected function type be?
(double(double, double, ...) or float(float, float, ...) or some other types)

I couldn't find any citations in the MEF text,
and the References seem to be more like Bibliography
(the material to have been or to be consulted, such as handbooks and regulations).
Moreover, the References is being numbered X for section,
as if it were a part of the format specification to be referenced.

ne seems to be more common as an operator to signify 'not-equal'. Bash comes into mind.
neq is, for example, used in LaTeX.
Where does df come from?