Minor modification of Completeness criterion conditions

Before this commit, condition (1) for the Completeness criterion was
referring to POSIX compliance. POSIX is a very detailed dynamic standard
which goes under revision continuously and not a lot of operating systems,
GNU/Linux included are completely/officially POSIX-compliant. Furthermore,
not all sections of the huge 4000 pages standard are really important
specifically to the current Maneage functionality.

With this commit, condition (1) has been replaced by a looser condition of
execution within a Unix-like OS. Also since the term environment might have
been mistaken with the term "Operating Environment", it was replaced by the
unmistakable term "environment variables" in conditions (3) and (5). Last
but not least, condition (2) was made more restrict by adding ASCII
encoding as the condition for storing the plain text files.

TO-DO:
POSIX could contain valuable ideas regarding portability of programming
practices. These can be taken advantage of later in providing necessary and
sufficient conditions for project completeness. Another idea could be to
make LFS construct or something else as a sharp definition for what we mean
by minimal Unix-like OS.

1 files changed, 6 insertions, 6 deletions

diff --git a/paper.tex b/paper.tex
index e8b7cc9..6bfdb97 100644
--- a/paper.tex
+++ b/paper.tex
@@ -217,15 +217,15 @@ We argue and propose that workflows satisfying the following criteria can not on
 
 \textbf{Criterion 1: Completeness.}
 A project that is complete (self-contained) has the following properties.
-(1) No dependency beyond the Portable Operating System Interface (POSIX, \new{a minimal Unix-like standard that is shared between many operating systems}).
-POSIX has been developed by the Austin Group (which includes IEEE) since 1988 and many OSes have complied.
-(2) Primarily stored as plain text, not needing specialized software to open, parse, or execute.
-(3) No impact on the host OS libraries, programs or environment.
+(1) \new{No \emph{execution requirements} apart from a minimal Unix-like operating system.
+Fewer explicit execution requirements would mean higher \emph{execution possibility} and consequently higher \emph{longetivity}.}
+(2) Primarily stored as plain text \new{(ASCII encoded)}, not needing specialized software to open, parse, or execute.
+(3) No impact on the host OS libraries, programs and \new{the existing environment variables}.
 (4) Does not require root privileges to run (during development or post-publication).
-(5) Builds its own controlled software for an independent environment.
+(5) Builds its own controlled software \new{with independent environment variables}.
 (6) Can run locally (without an internet connection).
 (7) Contains the full project's analysis, visualization \emph{and} narrative: including instructions to automatically access/download raw inputs, build necessary software, do the analysis, produce final data products \emph{and} final published report with figures \emph{as output}, e.g., PDF or HTML.
-(8) It can run automatically, with no human interaction.
+(8) It can run automatically, \new{without} human interaction.
 
 \textbf{Criterion 2: Modularity.}
 A modular project enables and encourages the analysis to be broken into independent modules with well-defined inputs/outputs and minimal side effects.