<div dir="ltr">Hi Markus, all,<div>here follow a few comments/questions</div><div><br></div><div>I'd really like the EBNF grammar in one place, </div><div>probably leaving the current excerpts as are, </div><div>but putting the whole grammar in an appendix.</div><div><br></div><div>In Section 4, you nicely describe musts and </div><div>shoulds on unique identifiers and the re-use vs. update</div><div>of an identifier.</div><div>Publisher discretion is however a bit risky, in my opinion.</div><div>What if I choose to re-use an IVORN that was an SCS </div><div>to change it into a TAP? Wouldn't this confuse applications?</div><div>Or wouldn't this be a bit tricky in an incremental </div><div>harvest for a RegTAP?</div><div>I think that some strong suggestion can be inserted</div><div>in this specification to avoid too loose directions to</div><div>data providers.</div><div><br></div><div>The draft generally moves to IVORN to abbreviate </div><div>IVOA Identifiers.</div><div>IVOA Identifiers are U-RI and we call them IVO-RN, but</div><div>are not U-RN (nor U-RL, as specified correctly).</div><div>Ok...I'm an hairsplitter...drop this, I just payed attention</div><div>to this details while reading on...</div><div><br><div><div class="gmail_extra">I think that (Section 6)</div><div class="gmail_extra">"It is non-normative in the sense that what these </div><div class="gmail_extra">identifiers reference is governed by other standards,"</div><div class="gmail_extra">is a bit confusing considering the section _is_ normative,</div><div class="gmail_extra">maybe the sentence can be turned around, stating it</div><div class="gmail_extra">is normative for syntax but not for identifier reference.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, is Section 7 or should it be Section 6.2, the one</div><div class="gmail_extra">on Standard Identifiers?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Should it be stated explicitly that the Standard Identifiers</div><div class="gmail_extra">Authority is the ivo://<a href="http://ivoa.net">ivoa.net</a>? And the resource key starts</div><div class="gmail_extra">with and "std"?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"> Marco</div><div class="gmail_extra"><br></div><div class="gmail_extra">PS - ...plus some typos</div><div class="gmail_extra"><br></div><div class="gmail_extra">You should put the editor in front of the authors list </div><div class="gmail_extra">(they told me so) for the ADS bibref.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The link in footnote at Sec. 1.2 does not work (apart from a</div><div class="gmail_extra">probably missing ~)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">- page 3 line 2: ...some other [missing] or concept...</div><div class="gmail_extra">- page 3 lines 3&4: IVORN, should it be expanded with capital R and N?</div><div class="gmail_extra">- page 11 last lines of sec 4: identifier should [be] based</div><div class="gmail_extra">- page 11 sec 5, end of second paragraph: two resources are identifiers [that] refer to</div><div class="gmail_extra">- page 11 sec 6, It is non-normative ... reference is gover[e]ned by other standards ...</div><div class="gmail_extra">- page 11 sec 6.1, "an individual data object...metadata"; (switch ; and " in the cited text)</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-12 17:41 GMT+01:00 Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Dear Registry activists,<br>
<br>
As promised in Banff, here's a first internal working draft for<br>
version 2.0 of our Identifiers specification. Its purpose of the new<br>
version is twofold:<br>
<br>
(1) throw out some ancient stuff (XML form of identifiers,<br>
speculation on how our Registry Interfaces spec might eventually look<br>
like) -- this is what I consider the incompatible change that makes<br>
this 2.0.<br>
<br>
(2) create a place where strong advice on special IVORN forms can<br>
sensibly be kept. For now, this concerns standard ids and dataset ids.<br>
<br>
I've put a rendered PDF to <a href="http://docs.g-vo.org/Identifiers.pdf" target="_blank">http://docs.g-vo.org/Identifiers.pdf</a>, but<br>
I really recommend checking out the source from<br>
<a href="https://volute.googlecode.com/svn/trunk/projects/registry/Identifiers" target="_blank">https://volute.googlecode.com/svn/trunk/projects/registry/Identifiers</a><br>
(or the http equivalent if you want to remain as anonymous as Google<br>
will let you) and building yourself (which will let you make an HTML<br>
version, too, if you prefer that; see ivoatex/README).<br>
<br>
Please comment, protest, or contribute in whatever way you see fit.<br>
Unless there is major strife about this, I'd do another redaction in<br>
late January and then go for public working draft in February with<br>
the intention of getting this to PR by Sesto.<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
<br>
</blockquote></div><br></div></div></div></div>