Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolve #90 (ObsCore example) and resolve #91 (relax content-type) #93

Merged
merged 7 commits into from
Feb 7, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 17 additions & 13 deletions DataLink.tex
Original file line number Diff line number Diff line change
Expand Up @@ -423,7 +423,7 @@ \subsection{DataLink MIME Type}
application/x-votable+xml;content=datalink
\end{verbatim}
to denote that the response from that URL is a DataLink response.
This is also the MIME type for the \blinks\ response
This is also the preferred MIME type for the \blinks\ response
(see \ref{sec:successfulRequests})
unless the caller has explicitly requested a specific value
via the RESPONSEFORMAT parameter (see \ref{sec:responseformat}).
Expand Down Expand Up @@ -504,7 +504,7 @@ \subsection{List of Links}
\end{itemize}

To facilitate consumption of large datalink results in streaming mode, all links
for a single ID value MUST be served in consecutive rows in the output.
for a single ID value {\bf must} be served in consecutive rows in the output.

If an error occurs while processing an ID value, there should be at least
one row for that ID value and an error\_message. For example, if an input
Expand Down Expand Up @@ -707,9 +707,10 @@ \subsection{Successful Requests}
with some additional details below.

Unless the incoming request included a RESPONSEFORMAT parameter requesting
a different format, the content-type header of the response MUST be
``application/x-votable+xml'' with the
``content'' parameter set to ``datalink'',
a different format, the content-type header of the response MAY be any value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Markus, MAY doesn't make sense here, should be SHOULD (or possibly MUST)

allowed by the VOTable specification, which at the time of this writing includes
``application/x-votable+xml'' and ``text/xml''. The former value is preferred
and SHOULD be augmented with the ``content'' parameter set to ``datalink'',
with the canonical form given in \ref{sec:mime}
strongly recommended. Contrary to
all other uses of the string given in \ref{sec:mime},
Expand All @@ -735,19 +736,22 @@ \subsubsection{VOTable output}
The name and UCD attributes for FIELD elements in the VOTable
(and the units in one case) are specified above (see \ref{sec:listOfLinks}).

The DALI specification states that a standardID INFO element with
name ``standardID'' and the actual standardID string as a value SHOULD
be provided. It is recommended to include such an element to help users
and applications to identify VOTables as results of DataLink services
this way:
The DALI specification states that VOTable output should include an
INFO element with \attval{name}{standardID} and the standardID string as a value.
\begin{verbatim}
<RESOURCE type="results">
...
<INFO name="standardID" value="ivo://ivoa.net/std/DataLink#links-1.0"/>
...
<TABLE>
...
</TABLE>
...
</RESOURCE>
\end{verbatim}

As of this version, the {links} response {\bf must} include this INFO element
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest replacing "As of this version" with "From version 1.1 of this standard". Otherwise the text is likely to remain in future revisions and be confusing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also: DALI 1.1 4.4.3 says "The standardID of a service specification is the IVOA resource identifier for the StandardsRegExt record not including capability-specific fragments." Does that mean that the value attribute in this example should be value="ivo://ivoa.net/std/DataLink" instead of value="ivo://ivoa.net/std/DataLink#links-1.0" ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, that's true of the standardID of the specification as used in a StandardsRegExt document. Here is is the standardID of the links endpoint itself, which is defined within that spec.

So I think it's OK.

so that a table of links is easily identified by users and applications when
initially received from the service and if saved for later use.

\subsubsection{Other Output Formats}

Expand Down Expand Up @@ -945,12 +949,12 @@ \subsection{Example: Service Descriptor for the \blinks\ Capability}
the FIELD element describing this column of the table
{\bf must} include an XML ID attribute
that uniquely identifies the FIELD (column).
For example, a response following the ObsCore-1.0 data model
For example, a response following the ObsCore-1.1 data model
would use the following:
\begin{verbatim}
<FIELD name="obs_publisher_did" ID="primaryID"
utype="obscore:Curation.PublisherDID"
ucd="meta.ref.url;meta.curation"
ucd="meta.ref.ivoid"
datatype="char" arraysize="256*" />
\end{verbatim}
where the ID value {\em primaryID\/} is arbitrary.
Expand Down