*DataLink *IVOA follow up session: Thursday May 28 - 13:00 UTC Participants: 20 L. Michel, M. Molinaro, J. Dempsey, M. Demleitner, F. Bonnarel, C. Rodrigo, P. Dowler, M. Taylor, X. Wu, M. Louyse, R. Savalle, J. Salgado, M. Mancini, H.Heinl, D. Morris, T. Jaffe, S. Derriere, Y. Grange, J. Juaristi Campillo, T. McGlynn Agenda: DataLink issues to discuss, taken from https://github.com/ivoa-std/DataLink/issues. Issue #33 not discussed/already agreed upon issue #45: how MAXREC works in DataLink MAXREC: Should we have in in Datalink at all? Probably not, because the client controls the number of ids to generate links for anyway, and aborting in the midst of links for a single id is out of the question. However, we should be clear that if a service overflows, it should be setting query_status=overflow (but query_status=ok we probably don't need to required in datalink). issue #42: mime-types completion by dataproduct_type * RFC2045 provides restrictions to adding paramters to mime-types * So we could add extra parameters to say votable but couldn't do that to e.g. fits * [MD] Do we need a separate column after all? * [PD] Spirit of it is that it should be a separate field * [MT] Standard requires that clients ignore unknown parameters, but agree it is against the spirit * [MD] Column would often be empty, but that's not so bad. Difficulty is in transition from 1.0 to 1.1 - clients would need to check if the column was present. * [PD] Column should optional in 1.1, can make mandatory in 2.0 (MD - column could be mandatory in 1.2) * Mireille L : I also agree the dataproduct property is different from the format , Mime-type What is the disadvantage of adding a new column ? if the productype vocabulary increases with several levels ( hierarchy), then the concatenation will be difficult anyway) * [FB] Would be adding a column that is already in ObsCore * [PD] Referring to the ObsCore DataProductType vocabulary rather than including the same column * General discussionon on which vocabulary (if any) to use * [MD] Prefer to keep it simple initially to solve the use case of what application to open the lnk in. * [PD] Could expand later to allow expansion by allowing vocab to be specified * [MD] There are solutions for specifying vocabs in semantics already #44 looking into Ada's proposal [FB] recursive DataLink over the levels of semantics terms as a solution? [PD] putting multiple terms, white-space separated? [MD] breaking change [TMcG] why is this breaking? [MD] referring to clients, servers can live with this change in semantics field [MT] depends on the client, if the client simply shows it to the user, it won't break. access_url templating Issue #27 https://github.com/ivoa-std/DataLink/issues/27 * DL usage is dramatically growing up: it shouln't be restricted by things easy to specify * Making easier the connexion with non VO services * Gregory DF use case: using FIELD values to build URLs * vos://cadc.nrc.ca~vault/pdowler/ivoa/virtual2020a/${wonderfulSession}.mp4a * Using inputParams with another form than '&name=value' or out of the query part * Selecting either sync or async in a TAP URLs * http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-source=7223&Name===${2QZ} >> prefix '==' * http://vizier.u-strasbg.fr/viz-bin/VizieR-5?-info=XML&-source=PFr&-c=${RAJ2000}${DEJ2000},rs=5 >> suffix ',rs=5" * http://www.eso.org/~jliske/mgc/data/pstamps/MGC${MGC}B.fit.gz * https://vizier.u-strasbg.fr/viz-bin/Cat?${catid} >> Example of real catid value: III/135A * MD: What happens if catid is foobar&x=y&b=c? * https://cdsarc.unistra.fr/viz-bin/cat/${catid} * ftp://cdsarc.u-strasbg.fr/pub/cats/${catid} * http://tapvizier.u-strasbg.fr/TAPVizieR/tap/${synOrasync}?REQUEST=doQuery&LANG=ADQL&MAXREC=20000000&QUERY=SELECT+TOP+200+*+FROM+%22${catid}%22 * MD: what happens if catid is ab's? * We could also figure out something like this ${proto}://cdsarc.unistra.fr/... * MD: what happens if proto is https://endpoint.of.whatever?retrieve_for_me=vos? * ... or like that http://cdsarc.unistra.fr/my-image.fits${gzOrNot}... MD: I still don't see why you don't these URLs into your links response -- that would be so much simpler and would provide much better user experience: They'll have useful metadata for these links rather than just the links. PD: I do like the limited idea of substituting path elements... MD: wellwell... the datalink curse has always been that there have been too many ways to achieve about the same thing. I'd (not?) still like to to exacerbate that without a strong reason (and I've still not seen a use case that would not have won by just putting the link in question into a links response. XW: I want to point out the encoding issue already exists in the VOTable link. Is it data provider's responsibility or the client's? My opinion: if param value is embedded in the accessURL: provider -- if it is an inputParam: client ( should clarify in doc) Should we use the same standard for templating? IIRC, a param value needs to be url-encoded once... variable subs mean that part of something is being encoded... also, path elements can be encoded/decoded, but frameworks do not decode them automatcially like they do for param values, so that's a pain. Worst case scenario: try to describe a vospace transfer negotiation with variable "target" vos URI :-) Hint: templated XML document that the client has to POST to an async (UWS) job list and then do something with. We have some data in vospace (community projects). In the end, it's better to just tell them the vos URI so they can use a vospace client tool. RFC6570 -> put link to document in issue #27's comments, so people can more easily get to that [DONE] https://www.rfc-editor.org/rfc/rfc6570.txt