diff --git a/en_us.ascii.add.spl b/en_us.ascii.add.spl
index 52a5be8..cefeefc 100644
--- a/en_us.ascii.add.spl
+++ b/en_us.ascii.add.spl
@@ -123,3 +123,6 @@ LAnguage
XSD
REgular
Schematron
+XInclude
+xmlns
+href
diff --git a/mef/model_organization.rst b/mef/model_organization.rst
index 916b4cb..0a6c3e9 100644
--- a/mef/model_organization.rst
+++ b/mef/model_organization.rst
@@ -56,10 +56,16 @@ Splitting the Model into Several Files
======================================
So far, we have written as if the model fits completely into a single file.
-For even medium size PSA models this assumption not compatible with Quality Control.
+For even medium size PSA models, this assumption is not compatible with Quality Control.
Moreover, such a monolithic organization of data would be very hard to manage
when several persons work together on the same model.
+One option would be to require tools accept multiple input files
+and treat them as if all the constructs were in one large file.
+Even though this approach is simple,
+(a) the grouping format for multiple input files would be left tool-specific,
+and (b) the mechanism is coarse and not as flexible as the options discussed bellow.
+
A first way to split the model into several files is to use the XML notion of entities:
in any XML file, it is possible to declare file entities in the preamble,
and to include them in the body of the document.
@@ -84,20 +90,52 @@ This mechanism is exemplified below.
This mechanism, however, has the drawback
that XML tools have to actually include the files into the document,
hence, making its manipulation heavier.
+Moreover, the individual files are not valid MEF files but arbitrary XML snippets.
+
+Alternative (W3C Candidate Recommendation) approach is to use XInclude,
+general purpose XML Include,
+which is flexible and powerful enough
+to make our custom specification seem redundant.
+
+.. code-block:: xml
+
+
+
+ ...
+
+ ...
+
-The Model Exchange Format proposes another simple mechanism to achieve the same goal:
+The Model Exchange Format proposes another simple mechanism
+to achieve the same goal in a portable and convenient way:
the tag include.
-This tag can be inserted at any place in a document.
-Its effect is to load the content of the given file into the model.
+This tag can be inserted at specific places in a document.
+Its effect is to load the context-specific content of the given file into the model
+as if the select content were textually included
+(i.e., the included content is evaluated in the context of the including container).
+Moreover, only constructs relevant to the including container
+are selected from the given file, ignoring irrelevant constructs.
+For example, fault trees pick model-data (basic events, etc.) but ignore event trees.
+In other words, the included file is treated as a database.
+
+The following are sufficient requirements
+to make include directives portable and easy to validate:
+
+1. The referenced files to be included shall be valid MEF files by themselves
+ enough to pass automatic validation against the MEF schema.
+2. Relative paths in include directives shall be resolved
+ with respect to the location of the current including file.
.. code-block:: xml
...
+
...
+
Organization of a Model
=======================
diff --git a/mef/schema/mef.rnc b/mef/schema/mef.rnc
index 74f4e9f..aa24945 100644
--- a/mef/schema/mef.rnc
+++ b/mef/schema/mef.rnc
@@ -9,7 +9,7 @@ reference =
include-directive =
element include {
- attribute file { xsd:string }
+ attribute file { xsd:anyURI }
}
include "model.rnc"