UNDESIRABLE? UCDs 'meta.id;meta.ref` resolve entry to the datalink viewer

[kimakan]

Currently, columns with the UCDs main.id;main.ref resolve the entry to /datalink/<datalink_id>/?job=<job_id>.

• First, it only works for the tables in the query results and breaks in the tables provided by /serve/table/<schema_name>/<table_name. In the serve module, it resolves to /serve/table/<schema_name>/<table_name>/NaN.
• Second, I don't think that this behavior is desirable for the most use-cases. Usually, the user would like to click on the ID of the object and go straight to some kind of object viewer that presents all relevant information in a nice form. Personally, I would remove this feature all together. However, maybe there is something I'm missing because I'm not quiet sure why it was done in the first place.

The code in question:

daiquiri/daiquiri/core/static/core/js/table.js

Lines 116 to 130 in 5ae2a14

	if (column.ucd) {
	if (column.ucd.indexOf('meta.ref') > -1) {
	if (column.ucd.indexOf('meta.note') > -1) {
	column.meta = 'note';
	} else if (column.ucd.indexOf('meta.image') > -1) {
	column.meta = 'image';
	} else if (column.ucd.indexOf('meta.file') > -1) {
	column.meta = 'file';
	} else if (column.ucd.indexOf('meta.ref.url') > -1) {
	column.meta = 'link';
	} else if (column.ucd.indexOf('meta.id') > -1) {
	column.meta = 'datalink'
	} else {
	column.meta = 'reference';
	}

[kimakan]

I found another instance where the combination of the ucds meta.id and meta.ref leads to some behavior where I don't see the use for it.

daiquiri/daiquiri/core/generators.py

Lines 96 to 98 in f980bc9

	if field.get('ucd'):
	if 'meta.id' in field['ucd'] and 'meta.ref' in field['ucd']:
	attrs.append('ID="datalinkID"')

Afaik, the attribute ID makes sense only if the record is referenced somewhere else in the same document using the attribute ref. It doesn't seem to be implemented in Daiquiri and as of now, I don't see the point.
Also, the current implementation does not adhere to the XML or VOTable standard. The ID must begin with a letter of underscore. Thus, Gaia's source_id is not a valid ID!

@jochenklar What do you think, can we remove this behavior in both cases?

[kimakan]

Also, the current implementation does not adhere to the XML or VOTable standard. The ID must begin with a letter of underscore. Thus, Gaia's source_id is not a valid ID!

I stand corrected. The identifier name (ID) must begin with a letter or underscore. The ID value, such as Gaia's source_id, doesn't have to follow this requirements. Hence, datalinkID is a valid name.