Update ObsCoreExtensionForRadioData.tex

ObsCoreExtensionForRadioData.tex

@@ -240,7 +240,6 @@ \subsection{Visibility data }
 \section{ObsCore attributes definition valid for radio data}
 \label{sec:ObsCoreRadDef}
 
-%Some mandatory or optional parameters will have peculiar estimation for visibility data.
 For radio data some of the definitions on ObsCore data model attributes need to be adjusted
 to fit the peculiarity of metadata for datasets partition, \emph{uv} space, etc.
 Here is a list of common ObsCore parameters already available for the radio data discovery.
@@ -320,7 +319,7 @@ \subsection{dataproduct\_type and dataproduct\_subtype}
 
 \section{ObsCore extension specific for radio data}
 
-Table \ref{tab:ExtensionAtt} shows the %additional
+Tables \ref{tab:ExtensionAtt} and \ref{tab:ExtensionAtt_instrumental} shows the %additional
 querying parameters we propose to add to ObsCore in order to better describe radio single dish and visibility data.
 The last column indicates if the attribute is useful for all radio datasets or only for visibilities, beam forming, or single dish data.
 
@@ -456,7 +455,7 @@ \section{The ivoa.obscore\_radio table}
 %Which columns these are is site-specific.
 
 To ensure that all compliant services can execute the same queries,
-all columns in table~\ref{tab:ExtensionAtt} must be present in such a
+all columns in tables~\ref{tab:ExtensionAtt} and \ref{tab:ExtensionAtt_instrumental} must be present in such a
 table, although any may be NULL. At least a foreign key into \verb|ivoa.obscore| will typically
 make the extension table user-visible. Additional free columns (such as f\_min, f\_max) may also
 be added.\footnote{can we make rules such that such additional columns