<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Hi Markus and other registry members,<br>
<br>
My comments to the last WD.<br>
In resume, I totally agree Markus's proposal to resuse official
URI RFC definition for our IVORN specification. This normalisation
effort totally follows our own CDS reflexion about CDS resource
homogeneous identification in the framework of a MOC server
prototype (VizieR tables, Aladin surveys (HiPS), and Simbad =>
<a class="moz-txt-link-freetext" href="http://alasky.unistra.fr/MocServer/query?ivorn=*">http://alasky.unistra.fr/MocServer/query?ivorn=*</a>). I was just a
little bit surprise about the usage of # proposed in the last
point.<br>
<br>
Many thanks Markus,<br>
Pierre Fernique<br>
<br>
------------<br>
<br>
Here the details of my comments on the last WD. =>
<a class="moz-txt-link-freetext" href="http://docs.g-vo.org/Identifiers.pdf">http://docs.g-vo.org/Identifiers.pdf</a> (IVOA Identifiers - Version
2.0 - IVOA Working Draft 2014-08-20)<br>
<br>
page 10 - "<i>Applications are encouraged to present authority
identifiers using all lower-case characters.</i>"<br>
=> Very often, organization names are acronyms. In this case,
the uppercase notation is not only more logic, but sometime
required by the institute internal policy (CDS, NED, ...) - I'm
not sure that we can keep this sentence.<br>
<br>
page 12 - 2.5 "<i>IVORNs can always be resolved to a Registry
record by querying a search-</i><i>able registry</i>" and "<i>If
an IVORN does not resolve in the Registry, clients SHOULD assume
it</i><i> is obsolete and that any IVOID built with it does not
reference an existing</i><i> resource or entity, either.</i>" <br>
=> One consequence will be the registration of all individual
VizieR tables (~15.0000) in the VO Registry (only catalogs are
presently registered). It is a good evolution in the sens that the
catalog level in the registry has been always an issue for
application (server side and client side) which have to querying
and manipulating tables, and not catalogs.<br>
<br>
page 15 - Dataset Identifiers<br>
A little bit difficult to understand this section because it is
very DAL specific. An example would be probably welcome.<br>
Maybe, we could precise that the level of granularity of resources
registered in the Registry depends of the provider policy. For
instance, CDS will not use fragment identifier for distinguishing
bands of a survey, or tables of a catalog, because we record them
individually. So we have:<br>
ex: ivo://CDS/P/2MASS/J instead of ivo://CDS/P/2MASS?J,
ivo://CDS/I/213/table3 instead of ivo://CDS/I/213?table3<br>
<br>
page 16 - Standard Identifiers<br>
The # usage for expressing level of compliance (minor, major
version number, model version...) seems to me a surprising
extension of IVOID usage, and may be a little bit too specific to
Markus RegTAP implementation. In fact, this idea merges ID syntax
and query language facility. I would prefer to separate these two
goals:<br>
<i>standard_id LIKE ’ivo://ivoa.net/std/exampleProto#query-1.%’</i><br>
=><br>
<i>standard_id LIKE ’ivo://ivoa.net/std/exampleProto' WHERE
query...</i><i><br>
</i><br>
Pierre<br>
<br>
Le 29/04/2015 15:20, Markus Demleitner a écrit :<br>
</div>
<blockquote cite="mid:20150429132057.GA21508@ari.uni-heidelberg.de"
type="cite">
<pre wrap="">Dear Registry WG,
On Tue, Jan 27, 2015 at 03:34:16PM +0100, Markus Demleitner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Frankly, I'm not quite sure why we should go into the trouble of
overriding all the perfectly good BNF from RFC 3986. Sure, we should
put some restrictions (nothing funny in the authorities, no queries
and fragments in whatever you resolve in a registry,...), but I'd
think we should say "IVORNs are run-of-the-mill RFC 3986-type URIs,
*except* (a), (b), and (c)" rather than trying to pretend Identifiers
could possibly work without RFC 3986.
Now, that would finally be a complete rewrite of the document, and
before I even embark on the journey there:
</pre>
</blockquote>
<pre wrap="">
Because nobody protested back in winter, I've gone ahead and followed
that program in volute revisions 2920 (sorry for the sheer size of
the diff) and 2926. For a formatted PDF, head to
<a class="moz-txt-link-freetext" href="http://docs.g-vo.org/Identifiers.pdf">http://docs.g-vo.org/Identifiers.pdf</a>
Despite the massive changes, the specification content has not
changed much. To get a quick idea of what this is about, please have
a look at section 1.3 ("Rationale for Version 2") and the entire
section 4 (and I'd really appreciate if you could find that time for
that).
Also, since that section 2 is almost all-new, I would be especially
grateful if standards lawyers could have a closer look at that (I'm
trying hard to not stare towards Glasgow too obtrusively now).
If you won't find time to do that within, say, two weeks, please let
me know -- otherwise I'd submit that as a WD after another round of
proof-reading by mid-May so there's some time for the rest of the
IVOA to have a look at it before Sesto.
Again, feel free to commit contributions of all sorts directly to
volute -- that's what version control is for.
Until then, I'd have another look at the Registry Interfaces revision
(mentioning RofR, in particular); incidentally, I'm planning to
downgrade that to a minor version (i.e., 1.1), as now that RegTAP is
no longer a part of it we're not formally breaking anything major as
far as I can see. Objections and contributions are welcome here,
too, at any time.
Thanks,
Markus
</pre>
</blockquote>
<br>
</body>
</html>