HiPS 1.0 Proposed Recommendation: Request for Comments
Public discussion page for the IVOA
HiPS 1.0 Proposed Recommendation.
The latest version of the
HiPS specification can be found at:
Reference Interoperable Implementations
Comments from the IVOA Community and TCG members during RFC period: 2016-12-15 - 2017-01-26
Comments from Markus Demleitner
p. 16, "Each line is ended by CR..." Are you sure you want what this is
saying? The only platform I'm aware of that ever used single CRs as
line separators was the classic Mac, and AFAIK with OS X they migrated
to having just LF as a line separator as $DEITY had originally intended.
So, essentially what you're specifying here will make everyone
equally unhappy. Note that the IETF somewhere requires anything with a
text/ major media type to use CRLF as line separator. So, much as I'd
like to see single LFs here, I guess you should just require CRLF as line
separator throughout and be done with it. (Incidentally, on p.22,
there's mention of "property1\nkey1"; \n is the conventional escape for
LF rather than CR, so whatever you do, this would need reconciliation).
p. 17, point 3. First, there's "image His" rather than "image
HiPS".
Then -- Obscore 1.1 now has "measurements" as dataproduct_type instead
of "catalog". Everyone will be grateful if we keep terminology uniform
between standards, and given that
ObsCore was there first, I guess
HiPS
would have to bite the bullet and change.
p. 18, point 6. What should catalog
HiPSes put into hips_file_format?
p. 18, point 8: hips_frame. For equatorial, you should mention in the
specification that you're assuming the ICRS reference frame (you do,
don't you?).
p. 18, table header: I suppose "Rec or Should" should be "Req or
Should", no? Linguistically more consistent would be "Must or Should",
but since you'd have to change all the letters in the table then I'd say
it's not worth the effort.
p. 18, "obs_description". You're saying this contains "one paragraph",
which people would probably take to mean "a couple of (perhaps physical)
lines", which of course is outlawed by the basic metadata format. To
reduce the risk of confusion, I'd suggest writing something like "longer
free text description of the dataset"
p. 20, "Catalogue
HiPS metadata": Are you sure we can't just require
metadata.xml? If I were to write a client and all I had to work with
are the column labels from the TSV, I'd be cross with you.
Also, two typos:
p. 12 "The mean method is appropriated": -> appropriate
p. 19, hips_order: Deeper -> Deepest (or perhaps Highest?)
--
MarkusDemleitner - 2016-12-15
Comments from TCG members during the TCG Review Period: 2016-12-15 - 2017-01-26
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or do not approve of the Standard.
IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )
Applications Working Group ( _Pierre Fernique, Tom Donaldson )
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
Registry Working Group ( _Markus Demleitner, Theresa Dower )
(1) 4.4.2.1 Is there a terribly strong reason to require 7-bit ASCII in the
TSVs? This would make Registry's life quite a bit harder when we
produce a
HiPS of the Registry (once we have enough coverages), as our
authors and titles can potentially contain all kinds of odd characters.
My take is: Just allow UTF-8. There's few platforms where that's a
problem these days, and UTF-8 doesn't clobber Tabs, so there's probably
little that can go severly wrong.
(2) While I like the term obs_regime in the table on p. 18, I have to
mention that the same concept, with essentially the same terms (but
different spelling -- ugh) is called waveband within
VODataService's
vs:Coverage element. Now, the different concept names probably are not
really dramatic, but the differences in the terms contained are fairly
painful, and that pain will only increase as we may extend the list with
neutrinos, gravitational waves, or whatever. So, here's what the
VODataService creators came up with about ten years ago:
"Radio" | "Millimeter" | "Infrared" | "Optical" | "UV" | "EUV" | "X-ray" | "Gamma-ray"
Couldn't you just adopt this list or even better, defer to
VODataService's vs:Waveband type so future additions will just pull
through? I realise it's a pain given the installed base, but perhaps
clients can contain a mapping for a while to ease transition?
(3) Thanks for making the implemented global
HiPS list something of an
epiphenomenon of a proper registration -- much appreciated. Since, on
the other had, I suspect that all actual clients go through that global
list exclusively, I think either sect. 6 should say somewhere
that that service exists and how to use it (probably in a non-normative
section) or there should be an appendix discussing that. Except, of
course, if you actually have plans to phase out that service. But if, as
I suspect, it is what clients are expected to do for the forseeable
future, it should IMHO be documented in this standard.
--
MarkusDemleitner - 2016-12-15
Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )
Time Domain Interest Group ( _John Swinbank, Dave Morris )
Data Curation & Preservation Interest Group ( Françoise Genova )
Operations Interest Group ( _Tom McGlynn, Mark Taylor )
Knowledge Discovery Interest Group ( Kaï Polsterer )
Theory Interest Group ( _Carlos Rodrigo )
Standards and Processes Committee ( Françoise Genova)