RegTAP document suggestion

[Markus Demleitner]

Hi Marco, hi all,

On Mon, Mar 11, 2013 at 11:16:59AM +0100, Marco Molinaro wrote:
> Subsection 7.3 (res_detail table) contains a 3-page long list of
> metadata (utypes) coming from current REC registry extension docs.
> Since this list seems to me long enough to mess up thoughts while
> reading and considering the items in the list belong to other docs and
> will be expanded in future reg-extension ones I'm wondering if it
> would be better to move it in an appendix of the draft.

This sounds reasonable to me, although more for reasons of avoiding
thought-messing than of later expansion; as planned, registry
extensions would define their own lists, so such utypes wouldn't end
up here (plus changing an appendix is as hard as changing the main
document).

Anyway, unless someone protests I'd probably go ahead and make the
move in the next revision (before it becomes WD?).

> I also suggest to mark more clearly MUSTs and SHOULDs in the list,
> rather then a "!" at the end of the item we can sort by requirement or
> put some more visible label in front of each utype.

I'm not very enthusiastic about sorting by requirement level; I felt
the natural order here is by source schema, since that is how I'd
expect people would go about while implementing things.  

Marking things more clearly (maybe gray out the optional ones?)
sounds more attractive to me.  Any suggestions as to the typography
are welcome.

But I'm fairly easily swayed even on the sorting question (after all,
considering two tables isn't much harder than considering one).  If
someone else speaks up for splitting up the list into MUST and SHOULD
(and nobody against), I'd do it.

> Moreover, since the list comes from external docs and will be extended
> in external docs, would it be useful to have a web page/small service
> maintaining it up to date and referred to in all the relevant
> documents?

Possibly, but of course this kind of maintenance is always difficult
to guarantee, and it would be to some extent a duplication of efforts
with http://www.ivoa.net/Documents/ and
http://www.ivoa.net/xml/index.html.  If there were an extremely
lightweight way of doing this (e.g., a wiki page linking into the
"official" IVOA repositories), I'd be all for it, but I'm not sure
I'm convinced that this kind of convention should be in the standard;
say the standard says you MUST keep such a repository and it doesn't
happen -- what or who exactly is in violation of the standard then?


Somewhat related to what I think Marco's intention here is is whether
something like the table in http://docs.g-vo.org/ridraft/#qnameatts
(mapping prefixes to actual namespace URLs) should be part of the
relational registry. It would let clients discover the XSD files
without having to consult ivoa.net, and it would be machine readable.
However, I'm always a bit skeptical about creating database tables
that will, in honest expectation, change at frequencies below 10
nHz...

Cheers,

       Markus