From 708ec3bfc447583433e12258133be506e6b0e02a Mon Sep 17 00:00:00 2001
From: Boud Roukema <boud@cosmo.torun.pl>
Date: Thu, 23 Apr 2020 00:46:20 +0200
Subject: 4.3.5 Project analysis - downloads

Reduction by about 7 words.

I added "internet security" as an extra reason for having all the
downloads in a single file. Modularity and minimal complexity in
themselves generally contribute to internet security, but in this
case, it's obvious that having all the communication with the
outside world managed through a single file makes internet security
management much simpler.

I replaced the "fake URL" by the real one, because at least in the
present format, the URL fits in nicely. So both `paper.tex` and
`tex/src/figure-src-inputconf.tex` are modified in this commit.
---
 paper.tex | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

(limited to 'paper.tex')

diff --git a/paper.tex b/paper.tex
index 4e0d177..1ee0bbd 100644
--- a/paper.tex
+++ b/paper.tex
@@ -578,20 +578,19 @@ The input files (which come from outside the project) are all \emph{targets} in
 
 The \inlinecode{download.mk} subMakefile is present in all projects, containing common steps for importing the input dataset(s).
 All necessary input datasets for the project are imported through this subMakefile.
-Irrespective of where the dataset is \emph{used} in the project's lineage, it helps to maintain relation with the outside world (to the project) in one subMakefile (see the modularity and minimal complexity principles \ref{principle:modularity} \& \ref{principle:complexity}).
+Irrespective of where the dataset is \emph{used} in the project's lineage, the relation between the project and the outside world is maintained in this single subMakefile, aiming at modularity and minimal complexity (\ref{principle:modularity} \& \ref{principle:complexity}), and internet security.
 
-Each external dataset has some basic information, including its expected name on the local system (for offline access), the necessary checksum to validate it (either the whole file or just its main ``data'', as discussed in Section \ref{sec:outputverification}), and its URL/PID.
+Each external dataset has some basic information, including its expected name on the local system (for offline access), a checksum to validate it (either the whole file or just its main ``data'', as discussed in Section \ref{sec:outputverification}), and its URL/PID.
 In Maneage, such information regarding a project's input dataset(s) is in the \inlinecode{INPUTS.conf} file.
 See Figures \ref{fig:files} \& \ref{fig:datalineage} for the position of \inlinecode{INPUTS.conf} in the project's file structure and data lineage, respectively.
-For demonstration, we are using the datasets of M20 which are stored in one \inlinecode{.xlsx} file on bioXriv.
-Figure \ref{fig:inputconf} shows the corresponding \inlinecode{INPUTS.conf} where the necessary information are stored as Make variables and are automatically loaded into the full project when Make starts (and is most often used in \inlinecode{download.mk}).
+We demonstrate this with the datasets of M20 stored in one \inlinecode{.xlsx} file on bioXriv.
+Figure \ref{fig:inputconf} shows the corresponding \inlinecode{INPUTS.conf} where the necessary information is stored as Make variables and is automatically loaded into the full project when Make starts (and is most often used in \inlinecode{download.mk}).
 
 \begin{figure}[t]
   \input{tex/src/figure-src-inputconf.tex}
   \vspace{-3mm}
   \caption{\label{fig:inputconf} The \inlinecode{INPUTS.conf} configuration file keeps references to external (input) datasets of a project, as well as their checksums for validation, see Sections \ref{sec:download} \& \ref{sec:configfiles}.
     Shown here are the entries for the demonstration dataset of \citet{menke20}.
-    The original URL is \url{\menketwentyurl}.
   }
 \end{figure}
 
-- 
cgit v1.2.1

