<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Dear all, <br>
</p>
<p>Just to summarize the discussion on the new identifier we expect
to use for publishing ObsTap services :</p>
<p>let me reformulate what I understood from the discussion : <br>
</p>
<p>1- for existing Tapregext registry records defining ObsTAP
services following ObsCore1.0 <br>
</p>
<p>We do not expect to change existing registry records: the data
model IVOAID remains : <br>
</p>
<pre wrap=""><dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel></pre>
<p> </p>
2- for new services following Obscore v1.1 specifications <br>
<br>
Tapregext should contain : <br>
<pre wrap=""> <dataModel ivo-id="ivo://ivoa.net/std/ObsCore#core-1.1">ObsCore-1.1</dataModel>
</pre>
following the new specification on IVOA Identifiers , version 2.0.<br>
As a few changes happened in names, types, ucd in the TAP-SCHEMA
tables with addition of new terms for axes length, <br>
ObsCore1.1 supersedes the previous version of ObsCore.<br>
Then only one <dataModel ... > tag should appear.<br>
<br>
The <font face="Courier New, Courier, monospace" size="-1">#core-1.1
extension</font> allows adding extra tables to the Tap schema if
necessary<font face="Courier New, Courier, monospace">,</font>like :<br>
<pre wrap="">ivo://ivoa.net/std/ObsCore#cube-1.2 as in Pat's example
ivo://ivoa.net/std/ObsCore#Prov-1.1 if we would like to bind a TAPschema table with simple provenance information, for instance.
</pre>
If we could agree on this, I would be able to give a final editing
step to the spec. <br>
<br>
Many thanks for your comments and suggestions already given , <br>
Mireille <br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Le 21/06/2016 à 18:54, Patrick Dowler a
écrit :<br>
</div>
<blockquote
cite="mid:CAFK8nrpnznKAcLtOKLcV2nb+EizVkFnC6q9aTUoXVKdwRUB7DQ@mail.gmail.com"
type="cite">
<pre wrap="">I might call that thing #core-1.1 so that if we defined more tables
they could have their own #symbol.
eg the ObsFile and ObsPart stuff I showed in Sesto, or
eg possibly dataproduct_type-specific tables that could be joined to
ObsCore, eg ObsCube (#cube-1.2) or ObsTimeSeries (#time-1.3) since
those were alternative solutions we discussed in the context of
extending ObsCore for the cube use cases.
Not saying we would do those, but #core-1.1 seems appropriately specific.
Pat
On 21 June 2016 at 09:46, Patrick Dowler <a class="moz-txt-link-rfc2396E" href="mailto:pdowler.cadc@gmail.com"><pdowler.cadc@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I agree with this. Keep compat but do it right from here on.
Pat
On 14 June 2016 at 01:38, Markus Demleitner
<a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear DM,
On Thu, Apr 28, 2016 at 09:04:57AM +0200, Laurent Michel wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The RFC period for Obscore 1.1 is started. It will cover a 6 weeks period from
now until May 15th.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
Ahem. Sorry that Registry hasn't put in their opinion yet. I
promise it's not going to take much longer. However, there is one
point I'd like to make here with my Registry chair hat on to see if
fixing this would cause problems for anyone, and that's the standard
identifier (sect. 5).
The current standard says:
The standard identifier for the ObsCore model described here is
ivo://ivoa.net/std/ObsCore/v1.1.
This is somewhat suboptimal, as it implies that for every ObsCore
version there's going to be a separate StandardsRegExt record --
remember, an ivoid is supposed to resolve in the Registry, and we in
the Registry WG intend to be a bit stricter in this in the future.
It is for this reason that Identifiers 2.0 recommends to have
standard identifiers of the form
ivo://ivoa.net/std/<standard name>/<something>-<version>
where <something> is a particular aspect of the standard; that's a
good idea because many standards at some point needed several
different concepts versioned. For Obscore, this would mean we'd like
the standard id to be
ivo://ivoa.net/std/ObsCore#table-1.1
Sure, this will look a bit odd because we cannot fix the standard id
for version 1.0, and so, further down on p. 27, it will have to say:
Since ObsCore-1.1 is a superset of 1.0, TAP services that support
ObsCore-1.1 also support ObsCore-1.0 and should include both
'dataModel' elements, e.g.:
<dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel>
<dataModel ivo-id="ivo://ivoa.net/std/ObsCore#table-1.1">ObsCore-1.1</dataModel>
This will allow clients looking for ObsCore-1.0 to find and use...
Not particularly pretty, but I think it's still better keeping
churning out one registry record per version.
So -- does anyone object to fixing this this late in the process?
Cheers,
Markus
</pre>
</blockquote>
<pre wrap="">
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>