Merge pull request #23 from pdowler/master

final update to endorsed note

.github/workflows/build.yml

@@ -1,7 +1,7 @@
 name: Check the IVOA document
 
 env:
-  doc_name: Arch
+  doc_name: IVOAArchitecture
 
 on:
   pull_request:
@@ -25,7 +25,7 @@ jobs:
         sudo apt install texlive-latex-base texlive-latex-recommended texlive-latex-extra texlive-fonts-recommended xsltproc
       
     - name: Build the document
-      run: make biblio forcetex
+      run: make archdiag0.pdf archdiag1.pdf archdiag2.pdf biblio forcetex
 
     - name: Check the output
       run: |

Arch.tex → IVOAArchitecture.tex

@@ -2,7 +2,6 @@
 \input tthdefs
 
 \newcommand{\xtype}[1]{\texttt{#1}}
-\newcommand{\ucd}[1]{\texttt{#1}}
 
 \usepackage{longtable}
 \usepackage{listings}
@@ -88,7 +87,7 @@ \section{IVOA Architecture Level 1}
 For completeness, part of the description is repeated  from  the  Level 0, so the  
 Level 1 description can be used as a self-contained block.
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.9\textwidth]{archdiag1.pdf}
 \caption{IVOA Architecture Level 1}
@@ -143,7 +142,7 @@ \section{IVOA Architecture Level 2}
 and recommended (blue boxes with an outer line) while others are still a work in progress
 (blue boxes without an outer line).
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.9\textwidth]{archdiag2.pdf}
 \caption{IVOA Architecture Level 2}
@@ -182,7 +181,7 @@ \section{Authentication and Authorization}
 direct dependencies on them. Implementors of other standards (e.g. Sec.~\ref{dal} and \ref{gws}) 
 ``combine'' these A \& A recommendations where necessary to support local policies and requirements.
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.28\textwidth]{ivoa-arch-auth.pdf}
 \caption{Authentication and Authorization Standards and Dependencies}
@@ -233,7 +232,7 @@ \section{Application and Format Standards}
 important component is a messaging system that enables the applications to share data 
 and take advantage of each other's functionality.
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.48\textwidth]{ivoa-arch-apps.pdf}
 \caption{Application and Format Standards and Dependencies}
@@ -298,7 +297,7 @@ \section{Semantics Standards}
 the case for unit strings and for the Unified Content Descriptors
 discussed below.
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.32\textwidth]{ivoa-arch-semantics.pdf}
 \caption{Semantics Standards and Dependencies}
@@ -337,11 +336,13 @@ \subsection{VOUnits}
 
 \subsection{UCD}
 
-Unified Content Descriptors (UCD) citep{2019ivoa.spec.1007G} are a way to denote astronomical data
+Unified Content Descriptors (UCD) \citep{2019ivoa.spec.1007G} are a way to 
+denote astronomical data
 quantities.  The UCD formalism first defines a list of ``atoms'', in
 effect a controlled vocabulary with a hierarchy implied through dots
 (e.g., \ucd{pos} denotes positions, \ucd{pos.eq} equatorial positions);
-this list is currently maintained as an Endorsed Note.
+this list is currently maintained as an Endorsed Note
+\citep{2021ivoa.spec.0616C}.
 
 The atoms can then be combined into more complex labels containing
 qualifications.  For instance, \ucd{phot.mag;em.opt.V} denotes a
@@ -367,7 +368,7 @@ \section{Registry Standards}
 of said IVOA registry services. (c) A Registry of Registries as the root component of data discovery 
 in the VO. 
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.70\textwidth]{ivoa-arch-registry.pdf}
 \caption{Registry Standards and Dependencies}
@@ -405,7 +406,7 @@ \subsection{Registry Interface}
 The Registry Interface \citep{2018ivoa.spec.0723D} defines the interfaces that support interactions between applications and 
 registries as well as between the registries themselves.  It is based on a general, distributed 
 model composed of searchable and publishing registries. The specification has two main components: 
-(a) an interface for searching and (b) an interface for harvesting.  Finally, Registry Interface 
+(a) an interface for searching and (b) an interface for harvesting.  Finally, the Registry Interface 
 details the metadata used to describe registries themselves as resources using an extension of the 
 VOResource metadata schema.
 
@@ -459,7 +460,7 @@ \section{Data Model Standards}
 between heterogeneous providers and users through a standard structure, semantics, and formats; 
 data models are the foundation for this exchange.
 
-\begin{figure}
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.62\textwidth]{ivoa-arch-dm.pdf}
 \caption{Data Model Standards and Dependencies}
@@ -473,7 +474,7 @@ \subsection{VO-DML}
 these to be used in a homogeneous manner and allows a consistent definition of reuse of one 
 model by another. The particular language defined here includes a consistent identification 
 mechanism for model which allows these to be referenced in an explicit and uniform manner 
-also from other contexts, in particular from othe IVOA standard formats such as VOTable. 
+also from other contexts, in particular from other IVOA standard formats such as VOTable. 
 The language defined in this specification is named VO-DML (VO Data Modelling Language). 
 VO-DML is a conceptual modelling language that is agnostic of serializations, or physical 
 representations. This allows it to be designed to fit as many purposes as possible. VO-DML 
@@ -658,7 +659,7 @@ \section{Data Access Standards}
 concepts to allow access to simulated data collections.
 \end{itemize}
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.90\textwidth]{ivoa-arch-dal.pdf}
 \caption{Data Access Standards and Dependencies}
@@ -810,7 +811,7 @@ \section{Infrastructure Resource Standards}
 or sanction industry standards or provide a common abstraction for users that can be implemented 
 on top of industry standard infrastructure.
 
-\begin{figure}[h]
+\begin{figure}[ht]
 \centering
 \includegraphics[width=0.54\textwidth]{ivoa-arch-gws.pdf}
 \caption{Authentication and Authorization Standards and Dependencies}
@@ -845,6 +846,7 @@ \subsection{VOSpace}
 second RESTful version of the interface. It specifies how VO agents and applications can 
 use network attached data stores to persist and exchange data in a standard way. 
 
+\pagebreak
 \section{Acronym Lookup Table}
 
 \begin{longtable}[t]{l l}

Makefile

@@ -1,26 +1,26 @@
 # ivoatex Makefile.  The ivoatex/README for the targets available.
 
 # short name of your document (edit $DOCNAME.tex; would be like RegTAP)
-DOCNAME = Arch
+DOCNAME = IVOAArchitecture
 
 # count up; you probably do not want to bother with versions <1.0
 DOCVERSION = 2.0
 
 # Publication date, ISO format; update manually for "releases"
-DOCDATE = 2021-09-14
+DOCDATE = 2021-10-29
 
 # What is it you're writing: NOTE, WD, PR, or REC
-DOCTYPE = NOTE
+DOCTYPE = EN
 
 # Source files for the TeX document (but the main file must always
 # be called $(DOCNAME).tex
 SOURCES = $(DOCNAME).tex
 
 # List of pixel image files to be included in submitted package 
-FIGURES = archdiag0.pdf archdiag1.pdf archdiag2.pdf
+FIGURES = 
 
 # List of PDF figures (for vector graphics)
-VECTORFIGURES = 
+VECTORFIGURES = archdiag0.pdf archdiag1.pdf archdiag2.pdf
 
 # Additional files to distribute (e.g., CSS, schema files, examples...)
 AUX_FILES = 

archdiag-full.xml

@@ -70,7 +70,7 @@ of the various sections) to have the box centered.
 	<rec name="SODA" x="681" y="430" w="38"/>
 	<rec name="ObsCore" x="619" y="180" w="52"/>
 	<prerec name="EPN-TAP" x="617.5" y="205" w="55"/>
-	<prerec name="ObsLocTAP" x="612" y="230" w="66"/>
+	<rec name="ObsLocTAP" x="612" y="230" w="66"/>
 
 	<!-- Data Models: x=430..580, y=250..400 -->
 	<prerec name="VODML-Map" x="440" y="355" w="72"/>