DataLink-1.0 Next

This topic collects proposals for modifications of the DataLink-1.0 specification in order to improve the next revision of the specification.

Errata to the DataLink-1.0 recommendation can be found on the devoted DataLink-1.0 Errata page.

Possible Errata

The following are acknowledged mistakes in DataLink-1.0. Errata could be pushed through, or they could just get fixed at the next version.

  • sec 4.3 'GROUP name="input"' should read 'GROUP name="inputParams"'. See mailing list (at the end of that message).

  • Bibliography entry [4] points to the wrong place, should be RFC2045(?). See mailing list.

Implementation feedback from TOPCAT

These points were (mostly) taken from a presentation in Victoria 2018, written up here as requested by the DAL chair. They can be taken into account when preparing a subsequent version of the standard, though not all of them necessarily should lead to changes.

Service Descriptor Context
Service descriptors come in two different contexts:
  1. {links}-response: explicitly referenced from a row of a {links}-response table
  2. standalone: implicitly referenced from all rows of a generic VOTable
They have to be treated differently in the different cases (neither is a special case of the other), since in the standalone case the service descriptor applies equally to all rows, while in the {links}-response case it only applies to those rows from which it is explicitly referenced. This makes it somewhat complicated to handle them since you need to determine the context first, but there's probably nothing that can be done about that while maintaining backward compatibility. However, it would be useful to spell out this distinction in the document; it took me quite a while to work it out. See mailing list.

Standalone Example
The document discusses {links}-response documents in some detail, and implies but does not give much explicit discussion of Service Descriptors in standalone VOTable documents. I think an additional example with a title like "Per-row service reference" along the lines of what is generated by the ARI-Gaia TAP service (see example) would help. In some sense the same ground is covered by the existing examples 4.2 "Service descriptor for the {links} capability" and 4.5 "Custom Access Data Service". However, given the context of the document, 4.2 looks like it is specific to {links} services (though the pattern isn't really) and 4.5 looks a bit daunting. I personally think that decorating generic VOTables with service descriptors to indicate associated parameter-less per-row services in this way is one of the most useful things about the DataLink document.

Service Descriptor metadata
If you have a standalone service descriptor in a generic VOTable document, clients will typically need more metadata than the accessURL, standardID and resourceIdentifier discussed in sec 4.1. shown in the existing examples, to communicate to the user what's going to happen if they follow the implied link. This is especially true if there are multiple such service descriptors per table. A name and description of such services can be included by using the name attribute and DESCRIPTION child of the service descriptor RESOURCE element. That is permitted given the VOTable schema, but not mentioned in this document. I suggest to include such usages in the examples given here, and to encourage service descriptors to add these items where appropriate. I further suggest adding an (optional) name="contentType" PARAM alongside the existing ones in table 3 to supply MIME type where known.

DataLink Recognition
A pattern suggested by the document (and used, e.g. by the ESA gaiadr2.gaia_source catalogue) is to include a column in certain tables that contains a URL pointing to a {links}-response table corresponding to that row. But there is no way in VOTable to mark up such a column so that clients know that's what it is. Not sure what to do about this; it's actually a more general problem about marking up URL-bearing VOTable columns with content types. See mailing list.

Service Descriptor positioning
There is no prescription in the document for how to arrange service descriptor and result table RESOURCEs within a VOTable document. One difficulty is that if streaming VOTables, it is sometimes necessary to know about the Service Descriptors before the table rows are encountered. Given that, it would be nice to require or recommend putting the service descriptor RESOURCE(s) before the table RESOURCE. Another is that in the case of more than one TABLE per document, there is no way in general to tell which service descriptors correspond to which table. This latter point may however be out of scope for this standard.

Row Correspondence
It would be useful to be able to identify a row in one {links}-response table that "corresponds" to a row in another, related, {links}-response table. For instance, if a user is browsing a (parent) table for which each row references a different {links}-response table, and has selected the 1/4-scale-JPEG-preview link in the {links}-response for one parent table row, it would be convenient to be directed to the 1/4-scale-JPEG-preview link when she selects another parent table row, rather than having to search for it again. Clients can attempt to do this at present, e.g. by looking at the semantics and description columns, but it's a bit haphazard. I suggest a new (optional?) column named something like link_code that can be assessed for equality in order to identify corresponding rows.

-- MarkTaylor - 2018-06-13

Proposed Features

Suggestion for revision of DataLink-1.0, in terms of new features.

Links and Authorization

We could add a non-normative advice to include a column in the {links} resource named "readable" with values true|false. The values predict if the client will (using the current anon or authenticated identity) be allowed to use the link (eg download the data). This saves the clients the annoyance of trying and getting a 403 Permission Denied.

-- PatrickDowler - 2019-05-16

Edit | Attach | Watch | Print version | History: r18 | r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2019-05-16 - PatrickDowler
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback