Discussion on Registry Interfaces Version 2

RegTAP material

RegTAP is now in RFC. Any further discussion on RegTAP goes there.

The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Also: There is now a validation suite; see http://svn.ari.uni-heidelberg.de/svn/gavo/regtap-val

There is a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)

All this is an attempt to fulfill RestfulRegistryInterfaceReq.

See also Notes from the RegTAP talk at the Heidelberg Interop.

Related Material

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

Requests for discussion/TODO

This is a list of questions Markus would appreciate input on. Feel free to add discussion points yourself as you see fit.

Please do comment in particular if you disagree with Markus' preference.

• Add strict non-null conditions (rather than and/or in addition to the milder conditions currently imposed by the shoulds on primary and foreign keys)?
  • Pro: In-DB validation might lead to less junk users have to cope with; also, non-null conditions might help implementors
  • Con (Markus' Favourite): don't require anything. What's valid is defined by VOResource anyway, but if people can ingest slightly invalid data without breaking, why punish them (by declaring them in violation of the spec)?
• Should there be a required table containing VOResource XML fragments?
  • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
  • Con (Markus' Favourite): it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH. Also, there's the question of namespace management: Require namespace declarations in all records? Allow them? Forbid them?
• Should we have a table mapping prefixes to namespace URI, i.e., a canonical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc?
  • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
  • Con: These mappings are largely static and are amended fairly slowly. Also note that it is intended that there are going to be multiple URI for a prefix (e.g., vs: already has two), so such a table is less straightforward than you may think