emelendez-csn
commented
7 years ago Hi there,
In my recollection, the "include" feature was thought as a means of making life easier for conversion of CAFTA files. In the normal setup, CAFTA models define a '.psa' file that points to the various 'eta' (event trees), '.fta' (fault trees). '.rr', databases, etc. Thus, ideally, one could make independent tools for converting each of the file types to the OPSA-MEF and produce a master XML that would represent the '.psa' file and include the rest.
However, software implementations can very well handle this in a transparent way with little additional effort. Moreover, the use of a '.psa' file is by no means mandatory, and in fact has been seldom, if ever used for CAFTA PSAs for Spanish plants.
IMHO, the include feature can be safely dispensed with.
ENrique
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.