Updates towards the first WD for 1.3

Makefile

@@ -7,7 +7,7 @@ DOCNAME = VODataService
 DOCVERSION = 1.3
 
 # Publication date, ISO format; update manually for "releases"
-DOCDATE = 2024-01-12
+DOCDATE = 2024-11-13
 
 # What is it you're writing: NOTE, WD, PR, REC, PEN, or EN
 DOCTYPE = WD
@@ -22,21 +22,18 @@ FIGURES = role_diagram.svg
 
 # List of PDF figures (figures that must be converted to pixel images to
 # work in web browsers).
-VECTORFIGURES = resclasses.pdf
+VECTORFIGURES = resclasses.tikz.svg
+
+SCHEMA_FILE=VODataService-v1.3.xsd
 
 # Additional files to distribute (e.g., CSS, schema files, examples...)
-AUX_FILES = VODataService-v1.2.xsd
+AUX_FILES = $(SCHEMA_FILE)
 
 AUTHOR_EMAIL=msdemlei@ari.uni-heidelberg.de
 
-%.pdf: %.psfig
-	ps2pdf -dEPSCrop $*.psfig $*.pdf
 
-%.psfig: %.texfig
-	tex $<
-	dvips $*
-	ps2epsi $*.ps $*.psfig
-	rm $*.ps
+%.pdf: %.texfig
+	pdflatex $<
 
 -include ivoatex/Makefile
 
@@ -45,5 +42,10 @@ ivoatex/Makefile:
 	@echo
 	git submodule update --init
 
+STILTS ?= stilts
+
 test:
-	@echo "No tests defined yet"
+	@$(STILTS) xsdvalidate $(SCHEMA_FILE)
+	@$(STILTS) xsdvalidate \
+		schemaloc="http://www.ivoa.net/xml/VODataService/v1.1=$(SCHEMA_FILE)" \
+		ipac-resource.xml

VODataService.tex

@@ -7,6 +7,9 @@
 \lstloadlanguages{XML}
 \lstset{flexiblecolumns=true,tagstyle=\ttfamily,showstringspaces=False}
 \usepackage{amsmath}
+\usepackage{tikz}
+\hbadness=4000
+\tolerance=3000
 
 \iftth
 \newcommand{\tapschema}{TAP\_SCHE\-MA}
@@ -156,7 +159,7 @@ \subsection{The Role in the IVOA Architecture}
 \end{figure}
 
 Fig.~\ref{fig:archdiag} shows the role VODataService plays within the
-IVOA Architecture \citep{2010ivoa.rept.1123A}.
+IVOA Architecture \citep{2021ivoa.spec.1101D}.
 
 VODataService directly depends on the following other VO standards
 (unless specified otherwise, the dependency is on the major version of
@@ -182,7 +185,7 @@ \subsection{The Role in the IVOA Architecture}
 defined here into a relational structure.  In that sense it is the
 user interface to what is specified here.  RegTAP will need an update
 to support the space-time constraints added here.
-\item[MOC, v1.1 \citep{2019ivoa.spec.1007F}] Multi-Order coverage maps
+\item[MOC, v2.0 \citep{2019ivoa.spec.1007F}] Multi-Order coverage maps
 are used by VODataService to communicate spatial coverage.
 \end{description}
 
@@ -197,7 +200,7 @@ \subsection{Purpose}
 were observed or modeled to create the data.  Another important aspect
 is the detailed metadata for tables underlying the resource, including
 names, types, UCDs
-\citep{2005ivoa.spec.1231D}, units,
+\citep{2023ivoa.spec.0125C}, units,
 and textual descriptions for the columns making them up.
 
 Resource records using VODataService types are commonly used to register
@@ -393,7 +396,7 @@ \subsection{The Schema Namespace and Location}
 Authors of VOResource instance documents may choose to
 provide a location for the VOResource XML Schema document and its
 extensions using the
-\xmlel{xsi:schemaLocation} attribute.  While authors are free to
+\xmlel{xsi:schema\-Location} attribute.  While authors are free to
 choose a location (as long as it resolves to the schema document), this
 specification
 recommends using the VODataService namespace URI as its location URL
@@ -453,9 +456,9 @@ \subsubsection{Auxiliary Classes}
 data providers should define separate records for them as described in
 sect.~\ref{sect:discoverdata}.
 
-VODataService further defines a specialized interface type
-(inheriting from \xmlel{vr:Interface}) called
-\xmlel{vs:ParamHTTP}.  This type is used to describe
+VODataService further defines a specialized interface type called
+\xmlel{vs:ParamHTTP}.  It inherits from \xmlel{vr:Interface}.
+This type is used to describe
 straightforward HTTP interfaces directly operating on
 arguments encoded as
 \emph{name=value} pairs.  Such interface declarations can
@@ -475,7 +478,7 @@ \subsubsection{VODataService Resource Classes}
 \label{sect:rescls}
 
 \begin{figure}
-\includegraphics{resclasses.pdf}
+\centerline{\tikzfigure{resclasses}}
 \caption{The four major resource classes in VODataService and their
 derivation tree}
 \label{fig:rescls}
@@ -512,7 +515,7 @@ \subsubsection{VODataService Resource Classes}
 are deprecated in version 1.2.
 Resource record authors are requested to migrate or discard resource
 records using these deprecated types.  If all such records have
-disappeared from the VO by version 1.3 of this specification, their
+disappeared from the VO by version 1.4 of this specification, their
 type declarations may be removed from the schema.
 
 \subsubsection{Discovering Data Within Other Services}
@@ -625,8 +628,8 @@ \section{The VODataService Metadata}
 \subsection{VODataService Resource Types}
 \label{sect:resext}
 
-For an overview of the systematics of the following resource types,
-please see Sect.~\ref{sect:rescls}.
+Sect.~\ref{sect:rescls} already gave a general overview of the
+systematics of the following resource types.
 
 \subsubsection{DataResource}
 \label{sect:DataResource}
@@ -906,7 +909,7 @@ \subsubsection{StandardSTC}
 data model was never promoted to an IVOA recommendation, there also is
 no properly standardised way of creating such records.  Since no such
 records ever existed in the Registry, this type will probably be removed
-from the schema in version 1.3 of this specification.
+from the schema in version 1.4 of this specification.
 
 
 
@@ -920,7 +923,7 @@ \subsection{Coverage in Space, Time, and Spectrum}
 In addition, there is the \xmlel{waveband} element that originally
 contained a qualitative indication of the location of the resource's
 coverage on the electromagnetic spectrum.  As more resources cover
-non-electromagnetic messengers, the element's meaning has somewhat
+non-elec\-tromagnetic messengers, the element's meaning has somewhat
 shifted, and it now admits values from an extendable vocabulary of
 messengers\footnote{\url{http://www.ivoa.net/rdf/messenger}} that, for
 instance, includes Neutrinos.
@@ -983,7 +986,7 @@ \subsection{Coverage in Space, Time, and Spectrum}
 Deviating from common VO practice (which currently fairly consistently
 uses wavelengths of electromagnetic waves in vacuum), spectral limits are
 given in Joules of messenger energy.  This is intended to allow seamless
-integration of non-electromagnetic messengers.  The reference position
+integration of non-elec\-tromagnetic messengers.  The reference position
 for the spectral axis is the solar system barycenter.  Again, discovery
 use cases on a level where the difference between reference frames of
 ground-based observatories versus the solar system barycenter matters
@@ -1688,7 +1691,7 @@ \subsubsection{Unique Names for Tables}
 
 The definitions of the \xmlel{tableset} elements used in
 the \xmlel{vs:DataCollection} and
-\xmlel{vs:Catalog\-Ser\-vice} types
+\xmlel{vs:Cat\-alog\-Ser\-vice} types
 constrain certain names to be unique.  In particular, all schema names
 within a \xmlel{tableset} element must be unique, and all
 table names within a \xmlel{schema} element must be
@@ -2820,6 +2823,8 @@ \subsection{Changes since REC-1.2}
 \item Adding a \xmlel{productTypeServed} child to \xmlel{DataService};
 this is intended to replace the previous practice of choosing product
 types by service types.
+\item Postponing the drop of StandardSTC and DataCollection to version
+1.4.
 \end{itemize}
 
 \subsection{Changes since PR-20210223}

resclasses.tikz.tex

@@ -0,0 +1,24 @@
+\usetikzlibrary{positioning}
+
+\begin{tikzpicture}[
+class/.style={bottom color=blue!20,
+  top color=blue!20,
+  node distance=5mm and 20mm,
+  rounded corners=1mm,
+  minimum height=6mm,
+  thin,draw=black!50,align=center,
+  node font=\footnotesize
+}]
+
+\node (svc) [class,text=black!60] {vr:Service};
+\node (dres) [class, below= of svc] {DataResource};
+\node (dsvc) [class, right= of dres] {DataService};
+\node (cres) [class, below= of dres] {CatalogResource};
+\node (csvc) [class, below= of dsvc] {CatalogService};
+
+\draw [black,->] (svc) to (dres);
+\draw [black,->] (dres) to (dsvc);
+\draw [black,->] (dres) to (cres);
+\draw [black,->] (cres) to (csvc);
+
+\end{tikzpicture}