Merge branch 'u/womullan/tidy' into u/ctslater/reorder

acronyms.tex

@@ -7,6 +7,7 @@
 CI & Cyber Infrastructure \\\hline
 CSV & Comma Separated Values \\\hline
 DM & Data Management \\\hline
+DML & Data Manipulation Model \\\hline
 DMTN & DM Technical Note \\\hline
 DPDD & Data Product Definition Document \\\hline
 FITS & Flexible Image Transport System \\\hline

intro.tex

@@ -1,8 +1,9 @@
 
 \section{Introduction}
 
-The Science Data Model (SDM) specification is a machine-readable specification for the physical data model for the publicly released science data products of the LSST Project.
+The Science Data Model (SDM) specification is a machine-readable specification for the physical data model for the publicly released science data products of the Rubin Observatory Project.
 Meanwhile the \DPDD  represents an "idealized" data model that cannot directly be used as a recipe for the construction of a physical database schema and is not a full, precise definition of a data model.
-It should be treated as a requirements document for the data model and schema rather than itself defining them. However will not cover the evolution of the DPDD in this note.
+
+It should be treated as a requirements document for the data model and schema rather than itself defining them. However we will not cover the evolution of the DPDD in this note.
 
 

myacronyms.txt

@@ -7,3 +7,4 @@
 #   MIA:Missing In Action
 
 SDM:Science Data Model
+DML:Data Manipulation Model

schemaman.tex

@@ -4,8 +4,7 @@ \section{Schema Management}
 How do we manage changes in a controlled manner which do not break our systems?
 Can we do that and still remain flexible enough for a large organisation to develop with relative ease?
 
-The DPDD is a project-level change-controlled document; procedures for modifying it are outside the
-scope of this document.
+The DPDD is a project-level change-controlled document it shall remain subject to the RFC and DM CCB pr procedures for modifying it.
 
 The ``specification'' schema in LDM-153 should be updated whenever necessary to reflect any changes
 in DM's planned data products at the end of construction. Evolution of the LDM-153 schema is
@@ -16,7 +15,7 @@ \section{Schema Management}
 in the \texttt{sdm\_schemas} repository. Procedurally, \texttt{baselineSchema.yaml} should be
 treated like any other LaTeX input for a change controlled document: changes to it may be merged to
 master via a normal ticket, but are not ``official'' until an approved RFC releases a new version of
-the LDM document.
+the LDM document.  This allows some flexibility in development while maintaining control of the official version.
 
 The \texttt{hsc.yaml} schema in \texttt{sdm\_schemas} is a ``concrete'' schema that is not subject
 to change control, but the \texttt{ci\_hsc} integration tests verify that the outputs from that