[EXTERNAL] WD-ConeSearch-1.1-20200828 - HTML fixed
Mcglynn, Thomas A. (GSFC-6601)
thomas.a.mcglynn at nasa.gov
Thu Sep 10 18:04:25 CEST 2020
In reading this document, I find the language used is sometimes quite confusing about what is required. Here are a few issues I note.
All of these are just confusing language, not real issues, but I hope this could be clarified.
Tom
Section 2.
“The VOSI capability[, if present,] MUST be a sibling …” I think we need to be careful when stating MUST about an optional feature.
2.1
The wording: “The response, by default, MUST …” is confusing. What does it mean to say that something MUST do something by default.
Maybe “The service MUST support a VOTable response as described in …. Other formats may be supported but are not covered by this standard.”
How about…
“The recommended format for the Simple Cone Search …”
“URLs of the form …. are also permitted but this form is DEPRECATED for new services.”
What does “… MUST treat opaquely …” mean? I haven’t a clue.
2.1.1/2 “Single value” or “Single valued”
2.1.6
Again the statement of what is required is unclear.
“The service SHOULD support an optional RESPONSEFORMAT keyword. If this is not specified or if it is supported and the
user specifies any of the values … then the service MUST return a VOTable as described in section 3. Other values MAY
be supported by a particular service but in this case the response format is not defined herein.”
2.4. I suspect that this is where all statements of the siblinghood of the capabilities resource should be made. I.e., the
text in my first comment belongs here.
3. Another “MUST, by default,” which is very awkward. How about…
“Unless another supported format is specified in the RESPONSEFORMAT keyword, the response shall be in …”
Should there be a statement of what is supposed to happen if an unsupported format is requested? [Possibly
stating that the behavior is undefined.]
Somewhere put “The syntax of other response formats is not defined in this standard”
I believe the wording here is over specific about the content of the returned VOTable and references to “sources” or
any specific content should be deleted.
E.g., there are many cone search services which return observations of positions in the sky, not sources. A clearer and more generic statement
might be “ The returned VOTable SHALL contain all rows of the specified service whose position and/or time fields meet the spatial and/or temporal constraints
specified unless a row limit specified by the user or the service is exceeded. Additional rows that do not meet the constraints MAY be returned.”
3.1 I think it would be clearer if the text went something like:
“There MUST be exactly one FIELD with each of the following U
n ID_MAIN …
n POS_EQ_RA_MAIN
n POS_EQ_DEC_MAIN
I believe that that the requirement that there be a time.epoch;meta.main keyword must be preceded by
“Exactly one FIELD with the following UCDs MAY be present
- time.epoch;meta.main
The current wording which requires a time column invalidates most of the existing cone services.
4. I find this a real mess and I’m not at all sure of what the standard wants…
Are queries that have too many rows errors?
If we are going to talk about OVERFLOWs here, then I think you need to change
the chapter title to something like:
“Query Status and Errors”
Then the content can be something like:
“New services SHOULD provide query status and respond to errors as discussed in DALI. Existing
service MAY report errors using the deprecated syntax described in section 4.1.
A service MUST return an error document (using one of the above choices) in the following circumstances:
A required parameter (RA, DEC, SR) is missing
Any of these required paremeters is unparseable.
Any of these required parameters has an unphysical value.
A service may return an error for too large a value for the SR parameter, errors in optional
parameters, or any other conditions which make it impossible to support the query.
When returning a response in the standard VOTable format, services which truncate a query
based upon user or system query limits SHOULD use the OVERFLOW mechanism described in DALI to
indicate a truncated query.”
4.1 The current draft uses an unqualified MUST . That has to be fixed.
Maybe:
“Existing services MAY use an older syntax to indicate an error. When a error is detected, a VOTABLE which contains a PARAM element or
INFO elements with name=”Error” is returned. The corresponding value attribute should …:”
From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of Molinaro, Marco
Sent: Thursday, September 10, 2020 9:53 AM
To: Theresa Dower <dower at stsci.edu>
Cc: dal at ivoa.net
Subject: [EXTERNAL] WD-ConeSearch-1.1-20200828 - HTML fixed
Apologizing for this again, now there's a proper HTML
version of the ConeSearch WD 1.1 on the ivoa.net/documents<https://urldefense.proofpoint.com/v2/url?u=http-3A__ivoa.net_documents&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=5-rxdVHKk-CZU3ZU-QRslzLsDWf2NC8zdiGorOLqaXo&m=aNTg_ZdqzmgAH7pliq-f0_MCNa4dF-mzegCnUS4o40I&s=B7mNVimapXPkY1ZW-ktfr9g6NkGfbIV1Gz7-1WqEcLY&e=>
repository.
Thanks again Theresa for spotting this!
ciao
Marco
Il giorno mar 1 set 2020 alle ore 17:16 Molinaro, Marco <marco.molinaro at inaf.it<mailto:marco.molinaro at inaf.it>> ha scritto:
Hi Theresa,
thanks for reporting the problem with the .html
(it is so also on the file on my laptop...I'll investigate and fix)
In my view the registry discussion for ConeSearch is still in progress.
Also having it in SimpleDALRegExt only or in both documents or only in
the ConeSearch document is (my opinion) still in discussion.
I hope the GitHub issues can help to find the way, issues #32 and #33
can be seen as a start there.
A (short) discussion on the ConeSearch status will happen tomorrow,
Wednesday 2 September 2020 - 13:00 UTC in the DAL running meeting #3:
(https://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaDAL_RunningMeetings#RM3<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ivoa.net_twiki_bin_view_IVOA_IvoaDAL-5FRunningMeetings-23RM3&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=5-rxdVHKk-CZU3ZU-QRslzLsDWf2NC8zdiGorOLqaXo&m=aNTg_ZdqzmgAH7pliq-f0_MCNa4dF-mzegCnUS4o40I&s=Z_86YDSBiZ1ZwcrvmfT7_Zs5vulTBYdewBDCc4TzJOc&e=>)
it could be another place to discuss this.
Cheers
Marco
Il giorno mar 1 set 2020 alle ore 16:41 Theresa Dower <dower at stsci.edu<mailto:dower at stsci.edu>> ha scritto:
Thanks for sending this around!
A note, it looks like the generated HTML version of the standard (http://ivoa.net/documents/ConeSearch/20200828/WD-ConeSearch-1.1-20200828.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__ivoa.net_documents_ConeSearch_20200828_WD-2DConeSearch-2D1.1-2D20200828.html&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=5-rxdVHKk-CZU3ZU-QRslzLsDWf2NC8zdiGorOLqaXo&m=aNTg_ZdqzmgAH7pliq-f0_MCNa4dF-mzegCnUS4o40I&s=ZT6dalo65l03adJ7l0VCGUHMZ9H9Ekq61eKIY-63MVU&e=>) is cut off after section 2.1. I haven't investigated what the page generation might have got caught up on. The PDF and TeX are fine.
From the Registry end: it seems it may be helpful to add capability/interface information noting time information support, especially in the test query. Note this change would be in SimpleDALRegExt, and included back to the main CS document. Do we think this section is solid enough to work on it now, or do we keep it in mind for later in the WD process?
Cheers,
--Theresa
________________________________
From: dal-bounces at ivoa.net<mailto:dal-bounces at ivoa.net> <dal-bounces at ivoa.net<mailto:dal-bounces at ivoa.net>> on behalf of Molinaro, Marco <marco.molinaro at inaf.it<mailto:marco.molinaro at inaf.it>>
Sent: Saturday, August 29, 2020 6:12:54 AM
To: IVOA DAL
Subject: Working Draft - Simple Cone Search, v.1.1 2020-08-28 - released
External Email - Use Caution
Dear DAL,
This is to announce that a new Working Draft for
the ConeSearch specification has been released.
It's WD-ConeSearch-1.1-20200828 and you can find
it on the IVOA documents repository
http://ivoa.net/documents/ConeSearch/20200828/index.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__ivoa.net_documents_ConeSearch_20200828_index.html&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=5-rxdVHKk-CZU3ZU-QRslzLsDWf2NC8zdiGorOLqaXo&m=aNTg_ZdqzmgAH7pliq-f0_MCNa4dF-mzegCnUS4o40I&s=mbSMFu2k7GOqOCV4scPKP5QGQGr-iOyWhAHgEelNLdw&e=>
as well as on the GitHub repository where the
revision will continue on
https://github.com/ivoa-std/ConeSearch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ivoa-2Dstd_ConeSearch&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=5-rxdVHKk-CZU3ZU-QRslzLsDWf2NC8zdiGorOLqaXo&m=aNTg_ZdqzmgAH7pliq-f0_MCNa4dF-mzegCnUS4o40I&s=73vNxkWJ2y8cQOV0bq2l5o4QK9yRHfawnDLDqSCuCPY&e=>
On the GitHub repo you'll find the full issue list
related to the ongoing works. You're encouraged to
refer to that repository to contribute, comment,
discuss, follow up the specification's revision.
Nonetheless relevant information will be reported
on the DAL mailing list (i.e. here).
Here follows a simplified copy/paste list of the current
issues (relevant to 1.1 revision only):
- Discovery of versioned ConSearch services
- Make TIME aware ConeSearch services discoverable
- HTTP GET/POST w.r.t. endpoints & heritage
- Move Unified Content Descriptors to UCD1+ standard
- Max time span allowed in search
- VOTable response version
- Query parameter for table/catalogue pre-selection
- EPOCH query parameter
- Update .xsd and .vor
- VOTable RESOURCE and TABLE number
- VOTable examples (Appendix A)
- unrecognized custom parameter and optional parameters responses
- All sky search radius (also time filtering relevant)
Cheers
Marco & Ada (as ConeSearch editors)
Marco & James (as DAL coordination)
--
Marco Molinaro
INAF - Istituto Nazionale di AstroFisica
Osservatorio Astronomico di Trieste
email marco.molinaro at inaf.it<mailto:marco.molinaro at inaf.it>
tel. +39 040 3199 152
--
Marco Molinaro
INAF - Istituto Nazionale di AstroFisica
Osservatorio Astronomico di Trieste
email marco.molinaro at inaf.it<mailto:marco.molinaro at inaf.it>
tel. +39 040 3199 152
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20200910/c89feac4/attachment-0001.html>
More information about the dal
mailing list