RegTAP post-RFC edits

[Gretchen Greene]

Hi Markus,

One additional request is to add a diagram that illustrates the relational data model,  at least at the table level with associations between tables.    This was a general TCG request for any data model development due to the complexity, etc.  

This is not a full detaled diagram,  i.e. schema,  but a visual aid to the reader.  I know we have a drawing tool that can snap shot such a view from our Registry DB,  which can be edited,  we may be able to provide this from our system implementation if you don't have a model view.

-Gretchen 
________________________________________
From: registry-bounces at ivoa.net [registry-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Thursday, June 05, 2014 10:27 AM
To: registry at ivoa.net
Subject: RegTAP post-RFC edits

Dear Registry activists,

There's been some public and quite a few private comments on RegTAP
during RFC and the interop.  I've tried to work them all into the PR,
except for one point that's pending clarification over at DAL (that's
whether of not the type names in TAP_SCHEMA should have an adql:
prefix).

This then leads to the following list of changes (from the doument):

* Added a /full details xpath from VORegistry (this had been
  forgotten due to limitations in the makeutypes stylesheet).
* Added a /capability/interface/securityMethod/@standardID details
  xpath from vr:Interface.
* Added requirement to implement the ivo_string_agg user defined function.
* Added a section specifying the treatment of non-ASCII characters
  in RegTAP columns.
* New rules on string normalization: strings must be
  whitespace-stripped, empty strings must be mapped to NULL.
* Dropped requirements that the _index columns are integers (let
  alone small integers); added a section discussing in what sense they
  are implementation defined.
* Now declaring a precedence of xpaths generated by rules over the
  list in Appendix A
* Clarified translation of column/@std and param/@std
* Now recommending to contrain on intf_type (rather than intf_role,
  as before) when locating standard interfaces.
* Redactional changes from RFC (e.g., in column descriptions, some
  clarifications, typo fixes)

Many of these really concern corner cases or are somewhat minor, but
they do have impact on implementations.  I could therefore understand
if people wanted to put this through another round of RFC before TCG
review.  On the other hand, I think the case for that is marginal, as
IMHO none of the changes are fundamental in any sense of the word.

I'll be on vacation for the next two weeks -- if there's no request
for another RFC until then, I'd try to figure out how to get RegTAP
into TCG review.

Implementors -- I'd be really grateful if you could try the changes
or at least try to get a feeling for how bad they'll affect you.
The svn log might be useful for that (I've tried to keep commits
fairly atomic):

svn log -r 2481:2649 https://volute.googlecode.com/svn/trunk/projects/registry/regtap

I've already added tests exercising some of the changes to the
validation suite at

http://svn.ari.uni-heidelberg.de/svn/gavo/regtap-val

Some items aren't yet exercised (in particular, non-ASCII and
whitespace normalisation) -- I'll add tests for those (hopefully
tomorrow) and send another announcement when they're in --
suggestions for additional tests are, incidentally, always welcome.

Thanks,

        Markus