From owner-stdproc@eso.org Mon Sep 22 11:25:58 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8M9Pr24006028 for ; Mon, 22 Sep 2003 11:25:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8M9Prgk006024 for stdproc-outgoing; Mon, 22 Sep 2003 11:25:53 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8M9Pj24005999; Mon, 22 Sep 2003 11:25:45 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h8M9Pjx01306; Mon, 22 Sep 2003 11:25:45 +0200 (MEST) Message-ID: <3F6EC0C1.8050002@eso.org> Date: Mon, 22 Sep 2003 11:28:33 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: Roy Williams CC: stdproc@ivoa.net Subject: Re: Link to RSM document please References: <066f01c37ef9$cc992190$6b91d783@cacr.caltech.edu> <3F6C8CC6.6020403@eso.org> <043801c37fa3$39aa1330$6401a8c0@roxy> In-Reply-To: <043801c37fa3$39aa1330$6401a8c0@roxy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy Williams wrote: > Markus > > I would like to link to a page for the ResMetadata document, which would > list a matrix of versions and formats. I do not want to link specifically to > Microsoft word with a (soon tobe) outdated version. > > In other words, could you add another level of hierarchy? > > The "working documents" page would be split into one for each document -- > ResMetadata, soon there will be UCD, etc. > > Then for each document, the versions and formats are listed? > > This would be fabulous! Roy Hi again Roy, Ok, got your point. Since the IVOA document coordinator is on mission and since there are only two standards documents right now I wonder whether we urgently need another layer at the moment or whether you could link to http://www.ivoa.net/Documents/WD/ for now? At the moment another layer would mean to create a structure with mostly empty pages. Anyway, at the last IVOA meeting we assigned this kind of responsibility to the Document Coordinator which is Marco Leoni. Also, at the Cambridge meeting a new group was formed dealing with the Standards & Documents Acceptance Process. We might not want to bother them with such details. I just put on the CC list of this message to raise awareness of its existence ;). Markus +--- | Markus Dolensky Mailto:Markus.Dolensky@eso.org | AVO Technical Lead Web: www.euro-vo.org | Voice: ++49 89 32006/261 Fax: ++49 89 32006/480 +--- From owner-avo-sci@eso.org Thu Dec 4 20:04:47 2003 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB4J4WlK023535 for ; Thu, 4 Dec 2003 20:04:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4J4WPe023534 for avo-sci-outgoing; Thu, 4 Dec 2003 20:04:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-avo-sci@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB4J2E1u022783; Thu, 4 Dec 2003 20:02:14 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hB4J2Et07715; Thu, 4 Dec 2003 20:02:14 +0100 (MET) Message-ID: <3FCF84B6.9070507@eso.org> Date: Thu, 04 Dec 2003 20:02:14 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: mleoni@eso.org Subject: Server down X-Priority: 1 (highest) Content-Type: multipart/alternative; boundary="------------000202050900060205000601" Sender: owner-avo-sci@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: c001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------000202050900060205000601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Due to maintenance of the electrical systems this week-end in Garching, we have been requested to switch off all computer systems during this period. For this reason all the services (mailing lists, web sites, twikis) will be unavailable on Saturday Dec. 6 . Sorry for the short notice. Best regards, Marco -- Marco C. Leoni Astrophysical Virtual Observatory - http://www.euro-vo.org tel 0049 89 3200 6560 fax 0049 89 3200 6480 mleoni@eso.org --------------000202050900060205000601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Due to maintenance of the electrical systems this week-end in Garching, we have been requested to switch off all computer systems during this period.
For this reason all the services (mailing lists, web sites, twikis) will be unavailable on Saturday Dec. 6 .

Sorry for the short notice.


Best regards,
    Marco




--
Marco C. Leoni

Astrophysical Virtual Observatory - http://www.euro-vo.org
tel 0049 89 3200 6560
fax 0049 89 3200 6480
mleoni@eso.org
--------------000202050900060205000601-- From owner-stdproc@eso.org Fri Jan 23 11:48:35 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NAmOgK028811 for ; Fri, 23 Jan 2004 11:48:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NAmOFo028810 for stdproc-outgoing; Fri, 23 Jan 2004 11:48:24 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0NAmLgK028797 for ; Fri, 23 Jan 2004 11:48:21 +0100 (MET) Received: from apollo.le.ac.uk (mailsend.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NAmJEY028656 for ; Fri, 23 Jan 2004 11:48:20 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.24) id 1AjyrL-0004z3-3d for stdproc@ivoa.net; Fri, 23 Jan 2004 10:48:19 +0000 Received: (qmail 18410 invoked from network); 23 Jan 2004 10:48:39 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 23 Jan 2004 10:48:39 -0000 From: "Tony Linde" To: Subject: Document location Date: Fri, 23 Jan 2004 10:49:24 -0000 Organization: University of Leicester Message-ID: <005c01c3e19e$9104d040$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0NAmNgK028806 Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: While figuring out how to promote the RM document to PR status, I noticed that the process standards document was listed in all three areas (WD, PR and REC). This could be confusing to anyone browsing the site. I think it might be better to remove old references from the site, so a document only can be found at its highest level. It is still possible to get at old versions using the references in the header of the document. Also, I thought the 'Latest Version' was supposed to have the form NAME.EXT whereas it currently has TYPE-NAME.EXT (though the standard seems to have lost this instruction from the Naming Convention - teach me to read changes better) which means that this reference to a document will stop working when a document is promoted. I'd like to suggest we use NAME.EXT. Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk Post: Department of Physics & Astronomy, University of Leicester Leicester, UK LE1 7RH Project Manager, Director, AstroGrid Leicester e-Science Centre http://www.astrogrid.org http://www.e-science.le.ac.uk/ From mleoni@eso.org Fri Jan 23 17:31:35 2004 Return-Path: Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0NGVRgK029419; Fri, 23 Jan 2004 17:31:27 +0100 (MET) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NGVOEY010980; Fri, 23 Jan 2004 17:31:25 +0100 (CET) Received: from aria (203.arlington-29-30rs.va.dial-access.att.net[12.77.111.203]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004012316310511200otma7e> (Authid: rjhanisch@worldnet.att.net); Fri, 23 Jan 2004 16:31:06 +0000 Message-ID: <00ea01c3e1ce$486c1020$cb6f4d0c@stsci.edu> Reply-To: "Robert Hanisch" From: "Robert Hanisch" To: Cc: References: <005c01c3e19e$9104d040$6124d28f@STAR.LE.AC.UK> Subject: Re: Document location Date: Fri, 23 Jan 2004 11:30:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Am cc'ing ivoadoc@ivoa.net (Marco) just in case he is not on the stdproc list. I agree - we should probably show the documents only in their current category. Also, can we create a view in which all documents in all classes appear together? As it is now, you have to click on each category to find out what's there (at ivoa.net/Documents/). The mix up on naming conventions is probably my fault, as I was confused by that stuff from the start. Do we think this warrants recycling the standards document back through the process? I would say not. But it will make it necessary to do some cosmetic repair on a couple of the documents already there. Bob ----- Original Message ----- From: "Tony Linde" To: Sent: Friday, January 23, 2004 5:49 AM Subject: Document location > While figuring out how to promote the RM document to PR status, I noticed > that the process standards document was listed in all three areas (WD, PR > and REC). This could be confusing to anyone browsing the site. > > I think it might be better to remove old references from the site, so a > document only can be found at its highest level. It is still possible to get > at old versions using the references in the header of the document. > > > Also, I thought the 'Latest Version' was supposed to have the form NAME.EXT > whereas it currently has TYPE-NAME.EXT (though the standard seems to have > lost this instruction from the Naming Convention - teach me to read changes > better) which means that this reference to a document will stop working when > a document is promoted. I'd like to suggest we use NAME.EXT. > > Cheers, > Tony. > > __ > Tony Linde > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > Post: Department of Physics & Astronomy, > University of Leicester > Leicester, UK LE1 7RH > > Project Manager, Director, > AstroGrid Leicester e-Science Centre > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > > From owner-stdproc@eso.org Fri Jan 23 17:32:01 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NGVggK029556 for ; Fri, 23 Jan 2004 17:31:42 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NGVfSH029555 for stdproc-outgoing; Fri, 23 Jan 2004 17:31:41 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0NGVRgK029419; Fri, 23 Jan 2004 17:31:27 +0100 (MET) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NGVOEY010980; Fri, 23 Jan 2004 17:31:25 +0100 (CET) Received: from aria (203.arlington-29-30rs.va.dial-access.att.net[12.77.111.203]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004012316310511200otma7e> (Authid: rjhanisch@worldnet.att.net); Fri, 23 Jan 2004 16:31:06 +0000 Message-ID: <00ea01c3e1ce$486c1020$cb6f4d0c@stsci.edu> From: "Robert Hanisch" To: Cc: References: <005c01c3e19e$9104d040$6124d28f@STAR.LE.AC.UK> Subject: Re: Document location Date: Fri, 23 Jan 2004 11:30:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Robert Hanisch" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Am cc'ing ivoadoc@ivoa.net (Marco) just in case he is not on the stdproc list. I agree - we should probably show the documents only in their current category. Also, can we create a view in which all documents in all classes appear together? As it is now, you have to click on each category to find out what's there (at ivoa.net/Documents/). The mix up on naming conventions is probably my fault, as I was confused by that stuff from the start. Do we think this warrants recycling the standards document back through the process? I would say not. But it will make it necessary to do some cosmetic repair on a couple of the documents already there. Bob ----- Original Message ----- From: "Tony Linde" To: Sent: Friday, January 23, 2004 5:49 AM Subject: Document location > While figuring out how to promote the RM document to PR status, I noticed > that the process standards document was listed in all three areas (WD, PR > and REC). This could be confusing to anyone browsing the site. > > I think it might be better to remove old references from the site, so a > document only can be found at its highest level. It is still possible to get > at old versions using the references in the header of the document. > > > Also, I thought the 'Latest Version' was supposed to have the form NAME.EXT > whereas it currently has TYPE-NAME.EXT (though the standard seems to have > lost this instruction from the Naming Convention - teach me to read changes > better) which means that this reference to a document will stop working when > a document is promoted. I'd like to suggest we use NAME.EXT. > > Cheers, > Tony. > > __ > Tony Linde > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > Post: Department of Physics & Astronomy, > University of Leicester > Leicester, UK LE1 7RH > > Project Manager, Director, > AstroGrid Leicester e-Science Centre > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > > From owner-stdproc@eso.org Fri Jan 23 19:28:21 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NIS6gK019836 for ; Fri, 23 Jan 2004 19:28:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NIS6OY019835 for stdproc-outgoing; Fri, 23 Jan 2004 19:28:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0NIS3gK019827 for ; Fri, 23 Jan 2004 19:28:03 +0100 (MET) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NIS1EY013971 for ; Fri, 23 Jan 2004 19:28:01 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040123182732.KDZF12068.mta05-svc.ntlworld.com@gnowee> for ; Fri, 23 Jan 2004 18:27:32 +0000 From: "Tony Linde" To: Subject: RE: Document location Date: Fri, 23 Jan 2004 18:29:06 -0000 Organization: University of Leicester Message-ID: <009301c3e1de$c920b8a0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <00ea01c3e1ce$486c1020$cb6f4d0c@stsci.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > current category. Also, can we create a view in which all > documents in all classes appear together? As it is now, you > have to click on each category to find out what's there (at > ivoa.net/Documents/). Good idea. Like: http://www.w3.org/TR/ > Do we think this > warrants recycling the standards document back through the > process? I would say not. No, the process does allow for corrections to be pushed through without representing the document. Cheers, Tony. > -----Original Message----- > From: owner-stdproc@eso.org [mailto:owner-stdproc@eso.org] On > Behalf Of Robert Hanisch > Sent: 23 January 2004 16:31 > To: stdproc@ivoa.net > Cc: ivoadoc@ivoa.net > Subject: Re: Document location > > > Am cc'ing ivoadoc@ivoa.net (Marco) just in case he is not on > the stdproc list. > > I agree - we should probably show the documents only in their > current category. Also, can we create a view in which all > documents in all classes appear together? As it is now, you > have to click on each category to find out what's there (at > ivoa.net/Documents/). > > The mix up on naming conventions is probably my fault, as I > was confused by that stuff from the start. Do we think this > warrants recycling the standards document back through the > process? I would say not. But it will make it necessary to > do some cosmetic repair on a couple of the documents already there. > > Bob > > > ----- Original Message ----- > From: "Tony Linde" > To: > Sent: Friday, January 23, 2004 5:49 AM > Subject: Document location > > > > While figuring out how to promote the RM document to PR status, I > > noticed that the process standards document was listed in all three > > areas (WD, PR and REC). This could be confusing to anyone > browsing the > > site. > > > > I think it might be better to remove old references from > the site, so > > a document only can be found at its highest level. It is still > > possible to > get > > at old versions using the references in the header of the document. > > > > > > Also, I thought the 'Latest Version' was supposed to have the form > NAME.EXT > > whereas it currently has TYPE-NAME.EXT (though the standard > seems to > > have lost this instruction from the Naming Convention - teach me to > > read > changes > > better) which means that this reference to a document will stop > > working > when > > a document is promoted. I'd like to suggest we use NAME.EXT. > > > > Cheers, > > Tony. > > > > __ > > Tony Linde > > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > > Post: Department of Physics & Astronomy, > > University of Leicester > > Leicester, UK LE1 7RH > > > > Project Manager, Director, > > AstroGrid Leicester e-Science Centre > > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > > > > > > From owner-stdproc@eso.org Fri Jan 23 19:55:40 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NItRgK024670 for ; Fri, 23 Jan 2004 19:55:27 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NItRbk024669 for stdproc-outgoing; Fri, 23 Jan 2004 19:55:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0NItOgK024653 for ; Fri, 23 Jan 2004 19:55:24 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i0NItO326329 for ; Fri, 23 Jan 2004 19:55:24 +0100 (MET) Message-ID: <40116E1C.1020602@eso.org> Date: Fri, 23 Jan 2004 19:55:24 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: stdproc@ivoa.net Subject: Re: Document location References: <005c01c3e19e$9104d040$6124d28f@STAR.LE.AC.UK> In-Reply-To: <005c01c3e19e$9104d040$6124d28f@STAR.LE.AC.UK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, Tony Linde wrote: >While figuring out how to promote the RM document to PR status, I noticed >that the process standards document was listed in all three areas (WD, PR >and REC). This could be confusing to anyone browsing the site. > >I think it might be better to remove old references from the site, so a >document only can be found at its highest level. It is still possible to get >at old versions using the references in the header of the document. > I agree, I'll update the site (after the next week). > > >Also, I thought the 'Latest Version' was supposed to have the form NAME.EXT >whereas it currently has TYPE-NAME.EXT (though the standard seems to have >lost this instruction from the Naming Convention - teach me to read changes >better) which means that this reference to a document will stop working when >a document is promoted. I'd like to suggest we use NAME.EXT. > Agreed as well, BUT this means to correct/recreate all the .pdf .doc .html versions, and to change all the pages = it will take a while ;-) (Anyway, the reference will stop to work only if the doc is removed) > >Cheers, >Tony. > >__ >Tony Linde >Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 >Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk >Post: Department of Physics & Astronomy, > University of Leicester > Leicester, UK LE1 7RH > >Project Manager, Director, >AstroGrid Leicester e-Science Centre >http://www.astrogrid.org http://www.e-science.le.ac.uk/ > Cheers, Marco From owner-stdproc@eso.org Thu Jan 29 10:09:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0T99aOG014189 for ; Thu, 29 Jan 2004 10:09:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0T99ZX3014188 for stdproc-outgoing; Thu, 29 Jan 2004 10:09:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0T99SOG014150 for ; Thu, 29 Jan 2004 10:09:28 +0100 (MET) Received: from apollo.le.ac.uk (apollo.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0T99QWR009971 for ; Thu, 29 Jan 2004 10:09:26 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.30) id 1Am8Av-0005ad-Od for stdproc@ivoa.net; Thu, 29 Jan 2004 09:09:25 +0000 Received: (qmail 20962 invoked from network); 29 Jan 2004 09:09:46 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 29 Jan 2004 09:09:46 -0000 From: "Tony Linde" To: Subject: Software licensing Date: Thu, 29 Jan 2004 09:10:36 -0000 Message-ID: <013b01c3e647$c22fe0d0$0b01a8c0@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0T99YOG014184 Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: For information, the license that I am looking into for IVOA projects use is the Common Public License: http://www.opensource.org/licenses/cpl.php I have a question about point *18* which I've directed to the authors (IBM): 'Does this mean that a commercial company who makes use of a portion or all of our code and wishes to sell that modified code, must make the source code of their amendments available?' Basically I wanted to make sure any code produced is freely available with no constraint on its use except to keep copyright notices in the code. I'll update this list when I get a response. Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk Post: Department of Physics & Astronomy, University of Leicester Leicester, UK LE1 7RH Project Manager, Director, AstroGrid Leicester e-Science Centre http://www.astrogrid.org http://www.e-science.le.ac.uk/ From owner-stdproc@eso.org Thu Jan 29 10:15:57 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i0T9FhOG015706 for ; Thu, 29 Jan 2004 10:15:43 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0T9FhhE015705 for stdproc-outgoing; Thu, 29 Jan 2004 10:15:43 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i0T9FYOG015664 for ; Thu, 29 Jan 2004 10:15:34 +0100 (MET) Received: from apollo.le.ac.uk (mailsend.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0T9FWEY019382 for ; Thu, 29 Jan 2004 10:15:33 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.30) id 1Am8Gq-000687-86 for stdproc@ivoa.net; Thu, 29 Jan 2004 09:15:32 +0000 Received: (qmail 21215 invoked from network); 29 Jan 2004 09:15:52 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 29 Jan 2004 09:15:52 -0000 From: "Tony Linde" To: Subject: RE: Software licensing Date: Thu, 29 Jan 2004 09:16:43 -0000 Message-ID: <013c01c3e648$9cb22420$0b01a8c0@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <013b01c3e647$c22fe0d0$0b01a8c0@STAR.LE.AC.UK> Importance: Normal X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Forgot this link to CPL FAQs: http://www-106.ibm.com/developerworks/library/os-cplfaq.html > -----Original Message----- > From: owner-stdproc@eso.org [mailto:owner-stdproc@eso.org] On > Behalf Of Tony Linde > Sent: 29 January 2004 09:11 > To: stdproc@ivoa.net > Subject: Software licensing > > > For information, the license that I am looking into for IVOA > projects use is the Common Public License: > http://www.opensource.org/licenses/cpl.php > > I have a question about point *18* which I've directed to the > authors (IBM): > > 'Does this mean that a commercial company who makes use of a > portion or all of our code and wishes to sell that modified > code, must make the source code of their amendments available?' > > Basically I wanted to make sure any code produced is freely > available with no constraint on its use except to keep > copyright notices in the code. > > I'll update this list when I get a response. > > Cheers, > Tony. > > __ > Tony Linde > Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356 > Fax: +44 (0)116 252 3311 Email: ael@star.le.ac.uk > Post: Department of Physics & Astronomy, > University of Leicester > Leicester, UK LE1 7RH > > Project Manager, Director, > AstroGrid Leicester e-Science Centre > http://www.astrogrid.org http://www.e-science.le.ac.uk/ > > From owner-stdproc@eso.org Thu Mar 4 15:24:53 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i24ENn9H024788 for ; Thu, 4 Mar 2004 15:23:49 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i24ENnNf024786 for stdproc-outgoing; Thu, 4 Mar 2004 15:23:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i24ENC9H024701; Thu, 4 Mar 2004 15:23:12 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i24ENCF20975; Thu, 4 Mar 2004 15:23:12 +0100 (MET) Message-ID: <40473BD0.4050207@eso.org> Date: Thu, 04 Mar 2004 15:23:12 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Robert Hanisch CC: IVOA stdproc WG Subject: Re: Identifiers 1.1 References: <4046EA3F.6030500@eso.org> <001501c401f0$915608d0$7deca782@stsci.edu> In-Reply-To: <001501c401f0$915608d0$7deca782@stsci.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Bob, this sounds like less work for the Document Coordinator: then I agree, let's merge the two docs - Working Draft and internal WG Draft - and remove the WD tree from the ivoa.net/Documents section of the site. Also, the IVOA Document Standards Recommendation needs to be updated to reflect these changes. Cheers, Marco Robert Hanisch wrote: >Folks, > > I think we've gone a bit overboard in our formatting rules here. There is >no point in making extra work for document authors, changing formats >unnecessarily. If you read our agreed upon standards process you find: >Working Draft. A document begins as a Working Draft. A Working Draft is a >chartered work item of a Working Group and generally represents work in >progress and a commitment by IVOA to pursue work in a particular area. The >label "Working Draft" does not imply that there is consensus within IVOA >about the document. > >I do not see the need for another level of document, a pre-Working Draft. >"Working Draft" is clear enough in name and definition. > >I believe the intent of our discussions in January was to make sure that WG >Chairs worked with the Document Coordinator to keep the document library >uncluttered, with correct cross-links, etc. > >Bob > From owner-stdproc@eso.org Thu Mar 4 18:24:19 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i24HNx9H009529 for ; Thu, 4 Mar 2004 18:23:59 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i24HNxKj009525 for stdproc-outgoing; Thu, 4 Mar 2004 18:23:59 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i24HNq9H009508 for ; Thu, 4 Mar 2004 18:23:52 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i24HNomW008109 for ; Thu, 4 Mar 2004 18:23:50 +0100 (CET) Message-Id: <200403041723.i24HNomW008109@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AywZZ-0002aQ-RJ for stdproc@ivoa.net; Thu, 04 Mar 2004 17:23:49 +0000 Received: (qmail 29535 invoked from network); 4 Mar 2004 17:24:11 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 4 Mar 2004 17:24:11 -0000 From: "Tony Linde" To: "'Marco C. Leoni'" , "'Robert Hanisch'" Cc: "'IVOA stdproc WG'" Subject: RE: Identifiers 1.1 Date: Thu, 4 Mar 2004 17:25:21 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQB9HdlDAJWGo6JSG2+CiExSKnkOAAGPOzg In-Reply-To: <40473BD0.4050207@eso.org> X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Why would we want to remove WD from the Documents section? WD is a definite stage in the approval process and docs at WD stage must appear in the Documents area. This is a separate issue from the formatting of the docs which I believe Bob's email was about. Cheers, Tony. > -----Original Message----- > From: owner-stdproc@eso.org [mailto:owner-stdproc@eso.org] On > Behalf Of Marco C. Leoni > Sent: 04 March 2004 14:23 > To: Robert Hanisch > Cc: IVOA stdproc WG > Subject: Re: Identifiers 1.1 > > Hi Bob, > this sounds like less work for the Document Coordinator: > then I agree, let's merge the two docs - Working Draft and > internal WG Draft - and remove the WD tree from the > ivoa.net/Documents section of the site. > Also, the IVOA Document Standards Recommendation needs to be > updated to reflect these changes. > > Cheers, > Marco > > > > Robert Hanisch wrote: > > >Folks, > > > > I think we've gone a bit overboard in our formatting rules here. > >There is no point in making extra work for document authors, > changing > >formats unnecessarily. If you read our agreed upon > standards process you find: > >Working Draft. A document begins as a Working Draft. A > Working Draft > >is a chartered work item of a Working Group and generally represents > >work in progress and a commitment by IVOA to pursue work in a > >particular area. The label "Working Draft" does not imply > that there > >is consensus within IVOA about the document. > > > >I do not see the need for another level of document, a > pre-Working Draft. > >"Working Draft" is clear enough in name and definition. > > > >I believe the intent of our discussions in January was to make sure > >that WG Chairs worked with the Document Coordinator to keep the > >document library uncluttered, with correct cross-links, etc. > > > >Bob > > > From owner-stdproc@eso.org Tue Mar 16 16:19:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2GFJ91o001476 for ; Tue, 16 Mar 2004 16:19:09 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2GFJ81u001474 for stdproc-outgoing; Tue, 16 Mar 2004 16:19:09 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2GFIp1o001363 for ; Tue, 16 Mar 2004 16:18:51 +0100 (MET) Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2GFIl3R025801 for ; Tue, 16 Mar 2004 16:18:49 +0100 (CET) Received: from aria (aria.stsci.edu [130.167.236.125]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJQ93952; Tue, 16 Mar 2004 10:18:40 -0500 (EST) Message-ID: <00d701c40b69$f9215780$7deca782@stsci.edu> From: "Robert Hanisch" To: Cc: "Francoise Genova" , "Ray Plante" , "Francois Ochsenbein" , "Jonathan McDowell" , "Roy Williams" , "Masatoshi Ohishi" , "Doug Tody" , "Guy Rixon" , "Tom McGlynn" , Subject: guidelines and procedures for IVOA document management Date: Tue, 16 Mar 2004 10:18:40 -0500 Organization: Space Telescope Science Institute MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu) X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Robert Hanisch" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Please review the new IVOA Note entitled "Guidelines and Procedures for IVOA Document Standards Management," which can be viewed at the URL: http://www.ivoa.net/Documents/latest/DocStdProc.html This Note attempts to capture the sense of the IVOA Executive when, at its January 2004 meeting, it asked that the IVOA document collection be tidied up and some procedures be put in place to avoid confusion between works-in-progress and published Working Drafts. I ask you particularly to comment on the following points: o We propose a version numbering system that uses the format #.##. Details are explained in the Note. This is slightly more constraining than a proposal circulated by Ray Plante a few days ago, but is hopefully easy for everyone to understand. o We ask working groups to develop new Working Drafts using a standard template, a template which helps to distinguish works-in-progress from published documents. Working Drafts are published to the IVOA document collection only when ready for wider review, and then the Document Coordinator updates formats to conform to the IVOA standards. Authors will not have to change text or formatting AT ALL as documents are promoted through the system. o We somewhat mix use of date formats, e.g., 15 March 2004 for main headings, but ISO 8601 format (2004-03-15) for time-stamps. Personally I'd prefer to use ISO 8601 throughout; it just seems to me to be a good practice. But I will not push it if others do not particularly care. Thank you, Bob Hanisch Chair, IVOA Standards and Processess Working Group From owner-stdproc@eso.org Tue Mar 16 16:48:27 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2GFmE1o007365 for ; Tue, 16 Mar 2004 16:48:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2GFmE6P007360 for stdproc-outgoing; Tue, 16 Mar 2004 16:48:14 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2GFm91o007340 for ; Tue, 16 Mar 2004 16:48:10 +0100 (MET) Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2GFm83R026804 for ; Tue, 16 Mar 2004 16:48:08 +0100 (CET) Received: from urania.cfa.harvard.edu (urania [131.142.52.147]) by head.cfa.harvard.edu (d/w) with ESMTP id i2GFm78Y020255 for ; Tue, 16 Mar 2004 10:48:07 -0500 (EST) From: Jonathan McDowell Received: (from jcm@localhost) by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id i2GFm6K4014552 for stdproc@ivoa.net; Tue, 16 Mar 2004 10:48:06 -0500 (EST) Date: Tue, 16 Mar 2004 10:48:06 -0500 (EST) Message-Id: <200403161548.i2GFm6K4014552@urania.cfa.harvard.edu> To: stdproc@ivoa.net Subject: Re: guidelines and procedures for IVOA document management X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Jonathan McDowell X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Bob, I think the draft seems mostly reasonable. A couple of points: - on the format of dates like "15 Mar 2004": it has been standard in astronomy for at least a century to write "2004 Mar 15", which has the merits of being Europe/US-neutral and in the same order as ISO-8601 but more readable. - on watermarks: my own experience is that when online, it is easy enough just to go to the depository to get the latest version of the doc, the problem arises when you have a hardcopy - or, usually in my case, 15 hardcopies all slightly different - and its origin is unclear. In that case the digital watermark doesn't help. I fear adding non-trivial overhead to the process in a way that won't actually help much. I think the introduction of the Working Group Working Draft (what has been called Internal Draft up to now, which I mildly prefer) solves a lot of the problem if we are disciplined enough to use it. - Jonathan From owner-stdproc@eso.org Thu Mar 18 11:19:07 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IAIq0f000658 for ; Thu, 18 Mar 2004 11:18:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2IAIqIo000655 for stdproc-outgoing; Thu, 18 Mar 2004 11:18:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IAIn0f000632 for ; Thu, 18 Mar 2004 11:18:49 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2I96amW017029 for ; Thu, 18 Mar 2004 10:06:37 +0100 (CET) Message-Id: <200403180906.i2I96amW017029@rocky.hq.eso.org> Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1B3tU3-0005X4-Ix for stdproc@ivoa.net; Thu, 18 Mar 2004 09:06:35 +0000 Received: (qmail 105 invoked from network); 18 Mar 2004 09:06:11 -0000 Received: from fluorine.star.le.ac.uk (HELO gnowee) (143.210.36.13) by mail.star.le.ac.uk with SMTP; 18 Mar 2004 09:06:11 -0000 From: "Tony Linde" To: Subject: Namespaces Date: Thu, 18 Mar 2004 09:07:30 -0000 Organization: University of Leicester MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQMKOX8Bj+5SPV+RwyzrKbj7DfJ4AAno4CA X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: It looks like we should quickly come up with a *standard* way of versioning namespaces. This is a little out of my field: does the following suggestion from Martin work as a standard? Or do we already have a standard? We need to namespace standard interfaces (eg SkyNode) and any of the parameters that those interfaces may take (eg ADQL as input, VOTable as output). Should we have a 'namespace' resource in the registry and use its identifier as the namespace? Cheers, Tony. -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil O'Mullane Sent: 17 March 2004 14:03 To: Martin @ ROE Cc: voql@ivoa.net Subject: Re: Versioning SkyNode WSDL This is the only one we made and its an old ADQL version. Yes when we put the new adql in I will make sure we version it also. The namespace also sounds fine On Wed, Mar 17, 2004 at 10:14:49AM +0000, Martin @ ROE wrote: > Me again - > > Can we start to version the SkyNode WSDL? Following the links on > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL I get to > http://SkyService.pha.jhu.edu/devel/SkyNode/SkyNode.asmx?WSDL. > > However this has 'http://voql.ivoa.net/' as its namespace; can we make > this eg 'http://skynode.ivoa.net/v0.n'? > > What version are we on anyay?! > > Cheers, > > Martin > > > -- > Martin Hill > Software Engineer, AstroGrid (ROE) > 07901 55 24 66 From owner-stdproc@eso.org Thu Mar 18 11:33:49 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IAXT0f003560 for ; Thu, 18 Mar 2004 11:33:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2IAXTDe003559 for stdproc-outgoing; Thu, 18 Mar 2004 11:33:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IAXQ0f003542 for ; Thu, 18 Mar 2004 11:33:26 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2IAXQF18230 for ; Thu, 18 Mar 2004 11:33:26 +0100 (MET) Message-ID: <40597AF6.8020400@eso.org> Date: Thu, 18 Mar 2004 11:33:26 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: stdproc@ivoa.net Subject: Re: Namespaces References: <200403180906.i2I96amW017029@rocky.hq.eso.org> In-Reply-To: <200403180906.i2I96amW017029@rocky.hq.eso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, actually, for the other schema in the /xml tree we are using the following: - http://www.ivoa.net/xml/VOResource/v0.9 therefore the skynode should be something like: - http://www.ivoa.net/xml/SkyNode/v0.n Cheers, Marco Tony Linde wrote: >It looks like we should quickly come up with a *standard* way of versioning >namespaces. This is a little out of my field: does the following suggestion >from Martin work as a standard? Or do we already have a standard? > >We need to namespace standard interfaces (eg SkyNode) and any of the >parameters that those interfaces may take (eg ADQL as input, VOTable as >output). > >Should we have a 'namespace' resource in the registry and use its identifier >as the namespace? > >Cheers, >Tony. > >-----Original Message----- >From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil >O'Mullane >Sent: 17 March 2004 14:03 >To: Martin @ ROE >Cc: voql@ivoa.net >Subject: Re: Versioning SkyNode WSDL > >This is the only one we made and its an old ADQL version. >Yes when we put the new adql in I will make sure we version it also. >The namespace also sounds fine > >On Wed, Mar 17, 2004 at 10:14:49AM +0000, Martin @ ROE wrote: > > >>Me again - >> >>Can we start to version the SkyNode WSDL? Following the links on >>http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL I get to >>http://SkyService.pha.jhu.edu/devel/SkyNode/SkyNode.asmx?WSDL. >> >>However this has 'http://voql.ivoa.net/' as its namespace; can we make >>this eg 'http://skynode.ivoa.net/v0.n'? >> >>What version are we on anyay?! >> >>Cheers, >> >>Martin >> >> >>-- >>Martin Hill >>Software Engineer, AstroGrid (ROE) >>07901 55 24 66 >> From owner-stdproc@eso.org Thu Mar 18 12:03:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IB3e0f008748 for ; Thu, 18 Mar 2004 12:03:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2IB3et8008747 for stdproc-outgoing; Thu, 18 Mar 2004 12:03:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2IB3Z0f008711 for ; Thu, 18 Mar 2004 12:03:35 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2IB3XmW020185 for ; Thu, 18 Mar 2004 12:03:33 +0100 (CET) Received: from dial.pipex.com (81-86-225-216.dsl.pipex.com [81.86.225.216]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 995D31C002C9; Thu, 18 Mar 2004 11:03:31 +0000 (GMT) Message-ID: <40598174.2050009@dial.pipex.com> Date: Thu, 18 Mar 2004 11:01:08 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdproc@ivoa.net Subject: Re: Namespaces References: <200403180906.i2I96amW017029@rocky.hq.eso.org> <40597AF6.8020400@eso.org> In-Reply-To: <40597AF6.8020400@eso.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: That makes sense; in fact we can extend it a little so that the namespace can then correspond to the location of the schema: http://www.ivoa.net/xml/VOResource/v0.9/VOResource.xsd http://www.ivoa.net/xml/SkyNode/v0.n/SkyNode.wsdl Which I believe is the industry convention? Seems a bit daft having the 'http://www.' prefix for a namespace, but that's conventions for you... Marco C. Leoni wrote: > Hi Tony, > > actually, for the other schema in the /xml tree we are using the following: > - http://www.ivoa.net/xml/VOResource/v0.9 > > therefore the skynode should be something like: > - http://www.ivoa.net/xml/SkyNode/v0.n > > > Cheers, > Marco > > > > > Tony Linde wrote: > >> It looks like we should quickly come up with a *standard* way of >> versioning >> namespaces. This is a little out of my field: does the following >> suggestion >> from Martin work as a standard? Or do we already have a standard? >> We need to namespace standard interfaces (eg SkyNode) and any of the >> parameters that those interfaces may take (eg ADQL as input, VOTable as >> output). >> >> Should we have a 'namespace' resource in the registry and use its >> identifier >> as the namespace? >> >> Cheers, >> Tony. >> -----Original Message----- >> From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil >> O'Mullane >> Sent: 17 March 2004 14:03 >> To: Martin @ ROE >> Cc: voql@ivoa.net >> Subject: Re: Versioning SkyNode WSDL >> >> This is the only one we made and its an old ADQL version. >> Yes when we put the new adql in I will make sure we version it also. >> The namespace also sounds fine >> >> On Wed, Mar 17, 2004 at 10:14:49AM +0000, Martin @ ROE wrote: >> >> >>> Me again - >>> >>> Can we start to version the SkyNode WSDL? Following the links on >>> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL I get to >>> http://SkyService.pha.jhu.edu/devel/SkyNode/SkyNode.asmx?WSDL. >>> >>> However this has 'http://voql.ivoa.net/' as its namespace; can we >>> make this eg 'http://skynode.ivoa.net/v0.n'? >>> >>> What version are we on anyay?! >>> >>> Cheers, >>> >>> Martin >>> >>> >>> -- >>> Martin Hill >>> Software Engineer, AstroGrid (ROE) >>> 07901 55 24 66 >>> > > From owner-stdproc@eso.org Thu Mar 18 13:31:32 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2ICV50f022631 for ; Thu, 18 Mar 2004 13:31:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2ICV5Pc022627 for stdproc-outgoing; Thu, 18 Mar 2004 13:31:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2ICUn0f022547; Thu, 18 Mar 2004 13:30:49 +0100 (MET) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2ICUnF20601; Thu, 18 Mar 2004 13:30:49 +0100 (MET) Message-ID: <40599679.1030701@eso.org> Date: Thu, 18 Mar 2004 13:30:49 +0100 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Martin Hill CC: stdproc@ivoa.net Subject: Re: Namespaces References: <200403180906.i2I96amW017029@rocky.hq.eso.org> <40597AF6.8020400@eso.org> <40598174.2050009@dial.pipex.com> In-Reply-To: <40598174.2050009@dial.pipex.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The namespace already correspond to the location of the schema, i.e. http://www.ivoa.net/xml/VOResource/v0.9 is a real (schema) file. That's why there is the "http://www" prefix. Marco Martin Hill wrote: > That makes sense; in fact we can extend it a little so that the > namespace can then correspond to the location of the schema: > > http://www.ivoa.net/xml/VOResource/v0.9/VOResource.xsd > http://www.ivoa.net/xml/SkyNode/v0.n/SkyNode.wsdl > > Which I believe is the industry convention? Seems a bit daft having > the 'http://www.' prefix for a namespace, but that's conventions for > you... > > > > Marco C. Leoni wrote: > >> Hi Tony, >> >> actually, for the other schema in the /xml tree we are using the >> following: >> - http://www.ivoa.net/xml/VOResource/v0.9 >> >> therefore the skynode should be something like: >> - http://www.ivoa.net/xml/SkyNode/v0.n >> >> >> Cheers, >> Marco >> >> >> >> >> Tony Linde wrote: >> >>> It looks like we should quickly come up with a *standard* way of >>> versioning >>> namespaces. This is a little out of my field: does the following >>> suggestion >>> from Martin work as a standard? Or do we already have a standard? >>> We need to namespace standard interfaces (eg SkyNode) and any of the >>> parameters that those interfaces may take (eg ADQL as input, VOTable as >>> output). >>> >>> Should we have a 'namespace' resource in the registry and use its >>> identifier >>> as the namespace? >>> >>> Cheers, >>> Tony. -----Original Message----- >>> From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil >>> O'Mullane >>> Sent: 17 March 2004 14:03 >>> To: Martin @ ROE >>> Cc: voql@ivoa.net >>> Subject: Re: Versioning SkyNode WSDL >>> >>> This is the only one we made and its an old ADQL version. >>> Yes when we put the new adql in I will make sure we version it also. >>> The namespace also sounds fine >>> >>> On Wed, Mar 17, 2004 at 10:14:49AM +0000, Martin @ ROE wrote: >>> >>> >>>> Me again - >>>> >>>> Can we start to version the SkyNode WSDL? Following the links on >>>> http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL I get to >>>> http://SkyService.pha.jhu.edu/devel/SkyNode/SkyNode.asmx?WSDL. >>>> >>>> However this has 'http://voql.ivoa.net/' as its namespace; can we >>>> make this eg 'http://skynode.ivoa.net/v0.n'? >>>> >>>> What version are we on anyay?! >>>> >>>> Cheers, >>>> >>>> Martin >>>> >>>> >>>> -- >>>> Martin Hill >>>> Software Engineer, AstroGrid (ROE) >>>> 07901 55 24 66 >>> From owner-stdproc@eso.org Wed Mar 31 23:22:29 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2VLMFZV028683 for ; Wed, 31 Mar 2004 23:22:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2VLMFDN028682 for stdproc-outgoing; Wed, 31 Mar 2004 23:22:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2VLMDZV028674 for ; Wed, 31 Mar 2004 23:22:13 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2VLMB3R012405 for ; Wed, 31 Mar 2004 23:22:12 +0200 (CEST) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i2VLMBV11163 for ; Wed, 31 Mar 2004 15:22:11 -0600 Date: Wed, 31 Mar 2004 15:22:11 -0600 (CST) From: Ray Plante To: stdproc@ivoa.net Subject: version numbers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Bob, Markus, Marco, I know I should have said something earlier, so feel free to say, "it's too late to change it." Thanks for the acknowledgement in the Guidelines Note regarding version numbers; however, you modified my suggestion in toward a direction I was trying to get away from. The convention of having 0.21 come between 0.2 and 0.22 has a real problem: you only get ten revisions of a particular level. What comes after 0.99 if you are not ready for 1.0? 0.991? Or are you out of luck? The result is that you no longer have a sense of how major a change the revision is. The point of *my* saying "fields on either side of the period (.) are integers" is to say that 3 comes between 2 and 4, and 21 come between 20 and 22. All increments between a set of periods are considered the same level of change. This is how RCS, CVS, and probably most other revision control systems work. cheers, Ray From owner-stdproc@eso.org Thu Apr 1 09:38:22 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i317bjle024888 for ; Thu, 1 Apr 2004 09:37:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i317bjxI024885 for stdproc-outgoing; Thu, 1 Apr 2004 09:37:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i317bJle024825; Thu, 1 Apr 2004 09:37:19 +0200 (MEST) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i317bJs13393; Thu, 1 Apr 2004 09:37:19 +0200 (MEST) Message-ID: <406BC6AE.2060905@eso.org> Date: Thu, 01 Apr 2004 09:37:18 +0200 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Ray Plante CC: stdproc@ivoa.net Subject: Re: version numbers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Ray, the "simplification" of version numbering came from some thoughts about document process: - do we really need 10000 versions in between ver. 0.1 and the first published WD (i.e. ver. 1.0)? - the documents process does not take into account the xml files et similia: they are "supplementary resources" that means you can follow your preferred numbering schema (CVS, RCS, VSS, etc.). Cheers, Marco Ray Plante wrote: >Hi Bob, Markus, Marco, > >I know I should have said something earlier, so feel free to say, "it's >too late to change it." > >Thanks for the acknowledgement in the Guidelines Note regarding version >numbers; however, you modified my suggestion in toward a direction I was >trying to get away from. The convention of having 0.21 come between 0.2 >and 0.22 has a real problem: you only get ten revisions of a particular >level. What comes after 0.99 if you are not ready for 1.0? 0.991? Or >are you out of luck? The result is that you no longer have a sense of how >major a change the revision is. > >The point of *my* saying "fields on either side of the period (.) are >integers" is to say that 3 comes between 2 and 4, and 21 come between 20 >and 22. All increments between a set of periods are considered the same >level of change. > >This is how RCS, CVS, and probably most other revision control systems >work. > >cheers, >Ray > From owner-stdproc@eso.org Thu Apr 1 14:25:22 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31CP7Ta002311 for ; Thu, 1 Apr 2004 14:25:07 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31CP717002307 for stdproc-outgoing; Thu, 1 Apr 2004 14:25:07 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31CP0Ta002269 for ; Thu, 1 Apr 2004 14:25:00 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i31COv3R005628; Thu, 1 Apr 2004 14:24:58 +0200 (CEST) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i31COxh18977; Thu, 1 Apr 2004 06:24:59 -0600 Date: Thu, 1 Apr 2004 06:24:59 -0600 (CST) From: Ray Plante To: marco.leoni@eso.org cc: stdproc@ivoa.net Subject: Re: version numbers In-Reply-To: <406BC6AE.2060905@eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Marco, On Thu, 1 Apr 2004, Marco C. Leoni wrote: > - do we really need 10000 versions in between ver. 0.1 and the first > published WD (i.e. ver. 1.0)? No, of course not. But I expect that it won't be uncommon that we'll need more than ten. > - the documents process does not take into account the xml files et > similia: they are "supplementary resources" that means you can follow > your preferred numbering schema (CVS, RCS, VSS, etc.). In some cases where a document has an associated standard schema (e.g. ADQL), it would advantageous to have the XML version track the document version. Even in general, people will want to just adopt one system as a matter of practice. Consider the situation of VOResource, whose version now sits at 0.9. We have a choice between whether to make a major fundemental change to the core model or just an incremental change. (This is not hypothetical.) In my suggested system, it's a choice between going to 0.10 or 0.9.1. In the IVOA system, I'm pretty much forced to go to 0.91. Is there functional disadvantage to my system? (I hope I'm not overblowing this one.) cheers, Ray > > > Cheers, > Marco > > > > > Ray Plante wrote: > > >Hi Bob, Markus, Marco, > > > >I know I should have said something earlier, so feel free to say, "it's > >too late to change it." > > > >Thanks for the acknowledgement in the Guidelines Note regarding version > >numbers; however, you modified my suggestion in toward a direction I was > >trying to get away from. The convention of having 0.21 come between 0.2 > >and 0.22 has a real problem: you only get ten revisions of a particular > >level. What comes after 0.99 if you are not ready for 1.0? 0.991? Or > >are you out of luck? The result is that you no longer have a sense of how > >major a change the revision is. > > > >The point of *my* saying "fields on either side of the period (.) are > >integers" is to say that 3 comes between 2 and 4, and 21 come between 20 > >and 22. All increments between a set of periods are considered the same > >level of change. > > > >This is how RCS, CVS, and probably most other revision control systems > >work. > > > >cheers, > >Ray > > > From owner-stdproc@eso.org Thu Apr 1 14:42:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31CgBTa006551 for ; Thu, 1 Apr 2004 14:42:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31CgAsF006550 for stdproc-outgoing; Thu, 1 Apr 2004 14:42:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31Cg1Ta006490 for ; Thu, 1 Apr 2004 14:42:01 +0200 (MEST) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i31CfxmW022316 for ; Thu, 1 Apr 2004 14:42:00 +0200 (CEST) Received: from dial.pipex.com (81-86-95-43.dsl.pipex.com [81.86.95.43]) by colossus.systems.pipex.net (Postfix) with ESMTP id 4D49E1C0019F; Thu, 1 Apr 2004 13:41:57 +0100 (BST) Message-ID: <406C0DCD.1070302@dial.pipex.com> Date: Thu, 01 Apr 2004 13:40:45 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdproc@ivoa.net Subject: Re: version numbers References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Throw in my opinion (how unusual) in support of Ray: 1) the numbering scheme that says that 0.10 is the version after 0.9 is reasonably common and gives all the flexibility we need. Limiting ourselves to one digit creates problems as Ray says with depth and with what happens after v0.9. Please please lets have a consistent pattern that lets us say v0.17 is after v0.7.3 2) Keeping the human document and associated schemas, WSDLs, etc versions the same makes life so much easier for the users of these documents! Given that we are setting *a* standard at each version change, then the whole set of documents describing that standard should make it clear they belong to that version of that standard. Cheers MC Ray Plante wrote: > Hi Marco, > > On Thu, 1 Apr 2004, Marco C. Leoni wrote: > >>- do we really need 10000 versions in between ver. 0.1 and the first >>published WD (i.e. ver. 1.0)? > > > No, of course not. But I expect that it won't be uncommon that we'll > need more than ten. > > >>- the documents process does not take into account the xml files et >>similia: they are "supplementary resources" that means you can follow >>your preferred numbering schema (CVS, RCS, VSS, etc.). > > > In some cases where a document has an associated standard schema (e.g. > ADQL), it would advantageous to have the XML version track the document > version. Even in general, people will want to just adopt one system as a > matter of practice. > > Consider the situation of VOResource, whose version now sits at 0.9. We > have a choice between whether to make a major fundemental change to the > core model or just an incremental change. (This is not hypothetical.) > In my suggested system, it's a choice between going to 0.10 or 0.9.1. In > the IVOA system, I'm pretty much forced to go to 0.91. > > Is there functional disadvantage to my system? > > (I hope I'm not overblowing this one.) > > cheers, > Ray > > > >> >>Cheers, >> Marco >> >> >> >> >>Ray Plante wrote: >> >> >>>Hi Bob, Markus, Marco, >>> >>>I know I should have said something earlier, so feel free to say, "it's >>>too late to change it." >>> >>>Thanks for the acknowledgement in the Guidelines Note regarding version >>>numbers; however, you modified my suggestion in toward a direction I was >>>trying to get away from. The convention of having 0.21 come between 0.2 >>>and 0.22 has a real problem: you only get ten revisions of a particular >>>level. What comes after 0.99 if you are not ready for 1.0? 0.991? Or >>>are you out of luck? The result is that you no longer have a sense of how >>>major a change the revision is. >>> >>>The point of *my* saying "fields on either side of the period (.) are >>>integers" is to say that 3 comes between 2 and 4, and 21 come between 20 >>>and 22. All increments between a set of periods are considered the same >>>level of change. >>> >>>This is how RCS, CVS, and probably most other revision control systems >>>work. >>> >>>cheers, >>>Ray >>> >> > > From owner-stdproc@eso.org Thu Apr 1 15:05:16 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31D4uTa011835 for ; Thu, 1 Apr 2004 15:04:56 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31D4uwv011833 for stdproc-outgoing; Thu, 1 Apr 2004 15:04:56 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31D4rTa011821 for ; Thu, 1 Apr 2004 15:04:53 +0200 (MEST) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i31D4rs26546 for ; Thu, 1 Apr 2004 15:04:53 +0200 (MEST) Message-ID: <406C1375.30108@eso.org> Date: Thu, 01 Apr 2004 15:04:53 +0200 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: IVOA stdproc WG Subject: Guidelines and Procedures note and version numbers Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Everybody, The most labour intensive part for the DC is reformatting documents to/from HTML, especially if the input HTML is automatically generated by some word processor. I'd like to propose the following section to clarify how to go about this. 2. Document Format The official format for IVOA documents is HTML. Templates in this format can be found at http://www.ivoa.net/Documents/templates. An automatic procedure is used to convert HTML documents into other common formats (PDF, MS-WORD). If the resulting output of this procedure is not satisfactory, the Document Coordinator will assist the Author(s) in producing the initial Working Draft version 1.0 from which such a loss less conversion is possible. In any case the Author(s) will be informed about the technical problem and advised to use the massaged html document as the baseline for future updates. If the authors prefer to work from a different baseline thereafter the conversion to other formats will be performed only if the output is complete and therefore consistent with the original and if this can be achieved without manual editing of the original. - About version numbers First of all, the standard process is about document specification, whereas software implementation is something different. Having said that, let me recall a discussion Tony, Ray and myself had some time ago: "[...] I would prefer: http://www.ivoa.net/xml/VOResource/v0.9 Since the status as working draft is irrelevant for the namespace - it *IS* the namespace we are using for that schema, it is not a working draft, it is actual. [...] We cannot guarantee a 1:1 relationship between schema and document so it is pointless to tie the schema namespace to any document naming scheme." [Tony] This should explain why we do not want to have the same numbering for documents and xml files. By the way, having ten possibilities to go from one level to another should be sufficient, simply requires some attention in producing a new *document*. Cheers, Marco From owner-stdproc@eso.org Thu Apr 1 15:42:15 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31DfpTa021073 for ; Thu, 1 Apr 2004 15:41:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31DfpOB021071 for stdproc-outgoing; Thu, 1 Apr 2004 15:41:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31DflTa021043 for ; Thu, 1 Apr 2004 15:41:47 +0200 (MEST) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i31DfjmW024769 for ; Thu, 1 Apr 2004 15:41:45 +0200 (CEST) Received: from dial.pipex.com (81-86-95-43.dsl.pipex.com [81.86.95.43]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 3BF041C003E4; Thu, 1 Apr 2004 14:41:41 +0100 (BST) Message-ID: <406C1BCC.4090106@dial.pipex.com> Date: Thu, 01 Apr 2004 14:40:28 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marco C. Leoni" Cc: IVOA stdproc WG Subject: Re: Guidelines and Procedures note and version numbers References: <406C1375.30108@eso.org> In-Reply-To: <406C1375.30108@eso.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Marco C. Leoni wrote: > - About version numbers > > First of all, the standard process is about document specification, > whereas software implementation is something different. If the full standard was described in the document, I would agree; the schemas/wsdls/etc are implementation issues. However we are using the schemas/wsdls to describe the standard, so I see them as being part of the specification. In other words, if I read the SkyNode document, I see the 'sorts of things' that an astrogrid datacenter must supply, but it is not in sufficient detail for me to create a datacenter that conforms closely enough to the standard that it will work with the VO. For that I need the WSDL and schemas. > Having said that, let me recall a discussion Tony, Ray and myself had > some time ago: > > "[...] I would prefer: http://www.ivoa.net/xml/VOResource/v0.9 > Since the status as working draft is irrelevant for the namespace - it *IS* > the namespace we are using for that schema, it is not a working draft, > it is actual. > [...] > We cannot guarantee a 1:1 relationship between schema and document so it is > pointless to tie the schema namespace to any document naming scheme." > [Tony] > > This should explain why we do not want to have the same numbering for > documents and xml files. While Tony's comment is technically true (we can't guarantee it) would it not make sense as a working practice? On the other hand, I understand that having to copy half a dozen files for a small change in one of them would be a pain... > By the way, having ten possibilities to go from one level to another > should be sufficient, simply requires some attention in producing a new > *document*. ? Ten's not nearly enough! SkyNode *was* passing v0.8 (somehow it's slipped back to 0.7.1?) and there's only one or two prototypes of it so far. Can we expect only two more changes before it's ready for general release v1? Why restrict ourselves to that if we have another industry-common versioning pattern? Now I really am going to take some time off.... honest I will be quiet now... MC From owner-stdproc@eso.org Thu Apr 1 17:59:02 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31FwpTa025732 for ; Thu, 1 Apr 2004 17:58:51 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31FwpPK025731 for stdproc-outgoing; Thu, 1 Apr 2004 17:58:51 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31FwnTa025722 for ; Thu, 1 Apr 2004 17:58:49 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i31FwlmW001360 for ; Thu, 1 Apr 2004 17:58:47 +0200 (CEST) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i31FwjW22656 for ; Thu, 1 Apr 2004 09:58:46 -0600 Date: Thu, 1 Apr 2004 09:58:45 -0600 (CST) From: Ray Plante To: IVOA stdproc WG Subject: Re: Guidelines and Procedures note and version numbers In-Reply-To: <406C1375.30108@eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Marco, (Thanks for reminding us of the previous discussion--often necessary as not everyone may have been aware of how we got to this point, and I know you're not operating in a vacuum.) > By the way, having ten possibilities to go from one level to another > should be sufficient, simply requires some attention in producing a new > *document*. As Martin points out, we are demonstrating that 10 is not enough. It doesn't matter if we are talking about documents, schemas, or software--the revision process is essentially the same. I guess I'm failing see what the advantage of the "simplified" system is. cheers, Ray From owner-stdproc@eso.org Fri Apr 2 12:00:45 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32A0T3Q001102 for ; Fri, 2 Apr 2004 12:00:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i32A0TEF001100 for stdproc-outgoing; Fri, 2 Apr 2004 12:00:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32A0J3Q001015 for ; Fri, 2 Apr 2004 12:00:20 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i32A0Js03221 for ; Fri, 2 Apr 2004 12:00:19 +0200 (MEST) Message-ID: <406D39C2.2080807@eso.org> Date: Fri, 02 Apr 2004 12:00:34 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 CC: IVOA stdproc WG Subject: 4 reasons why ver. # suffice + 3 reasons why more is harmful References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi The simplified version numbering scheme is partially my fault. In fact, I was initially even in favor of format "n.m" instead of "n.mm". Here are 4 reasons why m.nn version numbers (=> 100 revisions/increment of m) will easily suffice and 3 reasons why a more elaborate scheme would be harmful: *** 4 reasons why m.nn version numbers will suffice: 1. WDs prior to version 1.0 are WG internal and therefore not in the doc collection but remain in the roams of the WG where they can be freely altered without following any particular policy as long as the document layout is such that it prevents confusion with those on the official document tree. 2. But also after V1.0 internal drafts can be circulated within the WG, on the Wiki and on the mailing lists as often as deemed necessary. 3. Experience shows that it easily takes 6 weeks to review, rewrite and repost a document. Having potentially 100 revisions allows to intensively work on it for up to 10 years on a single version! If this is not enough one should seriously consider splitting the document into smaller solvable pieces. 4. Each version increment also requires the WG chair to review things, document changes within the doc. and - as our experience shows - to fiddle together with the DC on little details. Neither the WG chairs nor the DC have got the time to exhaust the potential number of possible revisions assuming that we all have only 24 hours a day. *** 3 reasons why a more elaborate scheme is harmful: 1. We should consider also the consumer point of view: Which one do you trust more: V2.0 or V1.19.04? V2.0 appears trustworthy and comforting to pick up and to develop against whereas V1.19.04 implies fragility, uncertainty and one can never remember the exact number anyway. 2. Each WG and author has a different attitude towards version increments. The more freedom we leave the more inconsistent will version numbers appear across the document tree. 3. The official doc collection is aimed at the whole VO community and beyond; if a revision is considered so minor that it isn't reflected within the first 2 version number components then by definition it is not worth bothering the whole community. *** It is interesting to note that the particular WG using numbers like 0.7.n spends considerable time discussing which version they are actually working on. A remark to Ray: It is a bit unfortunate that your name is acknowledged as the one suggesting the scheme, after we put it upside down. I can understand that you don't want to be blamed for something which is not your fault, but on the other hand Bob just tried to give credit where it seemed to be due. Give us advice at the end of the discussion on how to change it. Markus From owner-stdproc@eso.org Fri Apr 2 13:47:56 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32BlT3Q028779 for ; Fri, 2 Apr 2004 13:47:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i32BlTx9028777 for stdproc-outgoing; Fri, 2 Apr 2004 13:47:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32BlI3Q028743 for ; Fri, 2 Apr 2004 13:47:18 +0200 (MEST) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i32BlG3R025723 for ; Fri, 2 Apr 2004 13:47:16 +0200 (CEST) Received: from roe.ac.uk (81-86-95-43.dsl.pipex.com [81.86.95.43]) by pengo.systems.pipex.net (Postfix) with ESMTP id 53D034C0006E; Fri, 2 Apr 2004 12:47:14 +0100 (BST) Message-ID: <406D5284.4010105@roe.ac.uk> Date: Fri, 02 Apr 2004 12:46:12 +0100 From: "Martin @ ROE" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IVOA stdproc WG Subject: Version 0.3.2 of the version numbering debate... References: <406D39C2.2080807@eso.org> In-Reply-To: <406D39C2.2080807@eso.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Martin @ ROE" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: That's what we needed, a definite list of pros and cons... Markus Dolensky wrote: > Hi > > The simplified version numbering scheme is partially my fault. In fact, > I was initially even in favor of format "n.m" instead of "n.mm". Here > are 4 reasons why m.nn version numbers (=> 100 revisions/increment of m) > will easily suffice and 3 reasons why a more elaborate scheme would be > harmful: > > *** > > 4 reasons why m.nn version numbers will suffice: > > 1. WDs prior to version 1.0 are WG internal and therefore not in the doc > collection but remain in the roams of the WG where they can be freely > altered without following any particular policy as long as the document > layout is such that it prevents confusion with those on the official > document tree. > We still need to version them, even if they are not on the official site. That is what has been (and for some documents still is) causing confusion right now with the SkyNode spec. > 2. But also after V1.0 internal drafts can be circulated within the WG, > on the Wiki and on the mailing lists as often as deemed necessary. These too need to be versioned so we all know we are referring to the same document set. > 3. Experience shows that it easily takes 6 weeks to review, rewrite and > repost a document. Having potentially 100 revisions allows to > intensively work on it for up to 10 years on a single version! If this > is not enough one should seriously consider splitting the document into > smaller solvable pieces. > > 4. Each version increment also requires the WG chair to review things, > document changes within the doc. and - as our experience shows - to > fiddle together with the DC on little details. Neither the WG chairs nor > the DC have got the time to exhaust the potential number of possible > revisions assuming that we all have only 24 hours a day. That's fair enough - shall we say that only high level (release.major) docs get posted to the ivoa site? That allows us to continue to discuss and propose changes amongst the mailing list and experimental sites, using .minor versions to ensure amongst ourselves that we are talking about the same thing. What about minor changes such as spelling or wording changes? Or should these just be fixed without versioning on the official site? > > *** > > 3 reasons why a more elaborate scheme is harmful: > > 1. We should consider also the consumer point of view: Which one do you > trust more: V2.0 or V1.19.04? It is highly unlikely that V2.0 will live long. Soon there will be a few fixes - do these result in v2.3 or v2.0.3? The latter indicates minor changes, the former a relatively major one. > V2.0 appears trustworthy and comforting to pick up and to develop > against whereas V1.19.04 implies fragility, uncertainty and one can > never remember the exact number anyway. When it comes to releases we can always 'copy over' a version. I would expect that when we all agree that v0.25.4.3 is the right version to release, we copy that into v1.0. As we fix 'bugs' in the documents/specifications, these become v1.0.1, v1.0.2 etc, which indicates in an industry-common way to the user that these are minor changes. When v1.1 appears the users know they will have to read the spec again! This is exactly what happened to the JVM spec, and was very useful to people like myself who used JVM implementations. > > 2. Each WG and author has a different attitude towards version > increments. The more freedom we leave the more inconsistent will version > numbers appear across the document tree. Not really; we have a choice of whether a standard is a minor or major *increment*; that's it. If we agree that major changes are posted to the ivoa that should be a straightforward decision, or? > > 3. The official doc collection is aimed at the whole VO community and > beyond; if a revision is considered so minor that it isn't reflected > within the first 2 version number components then by definition it is > not worth bothering the whole community. Agreed. > > *** > > It is interesting to note that the particular WG using numbers like > 0.7.n spends considerable time discussing which version they are > actually working on. That's exactly the point; we were having trouble with the version numbers on the SkyNode document set *because* the standard was, largely, not versioned at all. Now that some of those documents are versioned we *can* discuss which version we are working on. Previously it was all rather vague; we picked up snapshots of their stuff and worked with that. Now we can find out what versions are being produced by which service and the problems and advantages of each, before submitting agreed new versions to the IVOA. We can't do that without an exact 'handle' on the working document version. MC -- Martin Hill Software Engineer, AstroGrid (ROE) 07901 55 24 66 From owner-stdproc@eso.org Fri Apr 2 14:27:35 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32CPh3U010227 for ; Fri, 2 Apr 2004 14:26:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i32CKxeo008987 for stdproc-outgoing; Fri, 2 Apr 2004 14:20:59 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32CKH3Q008779; Fri, 2 Apr 2004 14:20:17 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i32CKGs19332; Fri, 2 Apr 2004 14:20:16 +0200 (MEST) Message-ID: <406D5A8F.8050706@eso.org> Date: Fri, 02 Apr 2004 14:20:31 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: "Martin @ ROE" , stdproc@ivoa.net Subject: Re: Version 0.3.2 of the version numbering debate... References: <406D39C2.2080807@eso.org> <406D5284.4010105@roe.ac.uk> In-Reply-To: <406D5284.4010105@roe.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin Hill wrote: > Now I really am going to take some time off.... honest I will be quiet From owner-stdproc@eso.org Fri Apr 2 17:00:47 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32Eti3e025033 for ; Fri, 2 Apr 2004 16:59:53 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i32EDCuN009427 for stdproc-outgoing; Fri, 2 Apr 2004 16:13:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32EB23Q009022; Fri, 2 Apr 2004 16:11:02 +0200 (MEST) Received: from eso.org (nb008487.ads.eso.org [134.171.27.211]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i32EB1s01581; Fri, 2 Apr 2004 16:11:01 +0200 (MEST) Message-ID: <406D7475.9020508@eso.org> Date: Fri, 02 Apr 2004 16:11:01 +0200 From: "Marco C. Leoni" Organization: Astrophysical Virtual Observatory @ESO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Jonathan McDowell , IVOA stdproc WG Subject: Re: Fwd: IVOA Standard Documents References: <200404021311.i32DB1ti012727@urania.cfa.harvard.edu> In-Reply-To: <200404021311.i32DB1ti012727@urania.cfa.harvard.edu> Content-Type: multipart/alternative; boundary="------------010900030405070405030106" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: "Marco C. Leoni" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------010900030405070405030106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jonathan, I'm forwarding your mail to the stdproc list ..... as you said, discussion about the the standards document recommendation should be addressed there. Cheers, Marco Jonathan McDowell wrote: >Marco wrote: > > > >>Well, html is the standard format for IVOA documents >> >> > >[This is now beyond the scope of the voql list, but anyway...] >Marco, although I support the decision to make HTML the canonical >format for IVOA, I didn't realize we were going to be so restrictive, >and I think we may need eventually to revise this rule. > I think there are two roles for documents - > a source version which someone might use as a starting point for changes > a representation which is easy to read for everyone >and I think both should be found on the official IVOA documents page, >in multiple formats. HTML is in theory good for both because everyone >can access it, although in practice it does not always come out the >same in different browsers. PDF is also pretty good because I think >it's easy to read and print for most people, but it's not a source version. >Still it should be allowed as it's much easier to print a big PDF than >a big HTML. And the operating system specific formats - latex and postscript >for Unix, .doc for Microsoft - are good for source but each is inconvenient >for some users - still I think they should both be findable on the >official page, not just the twiki, if they are provided, AS LONG AS they >are accompanied by a universally printable format version (HTML or, I would >argue, PDF). > I worry that the current system may become so inflexible and >inconvenient that people will end up just bypassing it. It would be much >better if the IVOA Documents tree were the default place people went >to find the official document they wanted, the WG twikis are not optimal >for this. > - Jonathan McDowell > --------------010900030405070405030106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
    I'm forwarding your mail to the stdproc list ..... as you said, discussion about the the standards document recommendation should be addressed there.


Cheers,
    Marco



Jonathan McDowell wrote:
Marco wrote:

  
Well, html is the standard format for IVOA documents
    

[This is now beyond the scope of the voql list, but anyway...]
Marco, although I support the decision to make HTML the canonical
format for IVOA, I didn't realize we were going to be so restrictive,
and I think we may need eventually to revise this rule.
 I think there are two roles for documents -
   a source version which someone might use as a starting point for changes
   a representation which is easy to read for everyone
and I think both should be found on the official IVOA documents page,
in multiple formats. HTML is in theory good for both because everyone
can access it, although in practice it does not always come out the
same in different browsers. PDF is also pretty good because I think
it's easy to read and print for most people, but it's not a source version.
Still it should be allowed as it's much easier to print a big PDF than
a big HTML. And the operating system specific formats - latex and postscript
for Unix, .doc for Microsoft - are good for source but each is inconvenient
for some users - still I think they should both be findable on the
official page, not just the twiki, if they are provided, AS LONG AS they
are accompanied by a universally printable format version (HTML or, I would
argue, PDF). 
 I worry that the current system may become so inflexible and
inconvenient that people will end up just bypassing it. It would be much
better if the IVOA Documents tree were the default place people went
to find the official document they wanted, the WG twikis are not optimal
for this.
 - Jonathan McDowell
--------------010900030405070405030106-- From owner-stdproc@eso.org Fri Apr 2 21:31:26 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32JVD3Q004472 for ; Fri, 2 Apr 2004 21:31:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i32JVDGj004471 for stdproc-outgoing; Fri, 2 Apr 2004 21:31:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i32JVB3Q004454 for ; Fri, 2 Apr 2004 21:31:11 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i32JV8mW004579 for ; Fri, 2 Apr 2004 21:31:09 +0200 (CEST) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i32JV7d08882 for ; Fri, 2 Apr 2004 13:31:07 -0600 Date: Fri, 2 Apr 2004 13:31:07 -0600 (CST) From: Ray Plante To: IVOA stdproc WG Subject: Re: 4 reasons why ver. # suffice + 3 reasons why more is harmful In-Reply-To: <406D39C2.2080807@eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-PMX-Version: 4.1.0.84332 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Markos, Forgive me if I'm reading between the lines too much here, but I get the sense that you have two concerns: One is what the numbers communicate to the community. The other is the impact on the document coordinator of having to manage many versions on the IVOA site. I want to note that version numbers--particular the common convention I recommended--is a familiar concept in the software community. First, we all understand vaguely the relative significance of a change between two periods carries. (Unlike the "n.mm" pattern, where n.21 comes between n.2 and n.3., which is not commonly understood.) Second, we all understand that a change shift 2.1 from 2.2 in one product does not have much relevence to a change in another; it is up to the authors to determine what level of significance this is. We all operate fine with this common, albeit vague, notion of revisions. Also, the fact that m.n.r.[...] system is unbounded is not about allowing more than 100 versions. We have yet to generate 100 versions of anything nor do I expect us to (official or otherwise). It's about adopting a widely recognized convention with the flexibility required by typical software and document developments. I expect that most of the versions will never get posted to the official release page, yet we must track versions between them. I think we need to consider the way we are generating versions now, in practice. The m.n.r system supports us, it does not necessarily impact the document maintainers (i.e. let's deal with that issue separately), and the community will recognize what we're doing. So, if can suffer through more of my opinion, read my detailed reactions below. On Fri, 2 Apr 2004, Markus Dolensky wrote: > 1. WDs prior to version 1.0 are WG internal and therefore not in the doc > collection but remain in the roams of the WG where they can be freely altered > without following any particular policy as long as the document layout > is such that it prevents confusion with those on the official document > tree. As Martin says, we need to track changes prior to 1.0. Also, the suggestion that pre-WD version need not follow any stated policies is not viable; from the perspective of the WG, revision management is continuous prior to and after 1.0. > 3. Experience shows that it easily takes 6 weeks to review, rewrite and > repost a document. Having potentially 100 revisions allows to > intensively work on it for up to 10 years on a single version! If this > is not enough one should seriously consider splitting the document into > smaller solvable pieces. Recall my annotation that you put into the guidelines: "perhaps 0.3 never saw the light of day." In that six months, you can have lots of minor revisions; if it's done collaboratively, all have to have a different version number. Even when I was revising VOResource internally myself, I needed to track versions; my collaborators then saw multiple-increment jumps in the version number. The m.nn system indicates that the 2nd n is a minor revision on the first. That means you only get 10 revisions of a particular level. > 4. Each version increment also requires the WG chair to review things, document > changes within the doc. and - as our experience shows - to fiddle together with > the DC on little details. Neither the WG chairs nor the DC have got the time to > exhaust the potential number of possible revisions assuming that we all have > only 24 hours a day. As I've alluded, the WG chair does not necessarily review each revision; only those of sufficient significance (including those released via the Document repository.) > 1. We should consider also the consumer point of view: Which one do you trust > more: V2.0 or V1.19.04? > V2.0 appears trustworthy and comforting to pick up and to develop against > whereas V1.19.04 implies fragility, uncertainty and one can never remember the > exact number anyway. Actually, V2.0 implies fragility. V1.19.04 implies that version one has been well tested and debugged. > 2. Each WG and author has a different attitude towards version > increments. The more freedom we leave the more inconsistent will version > numbers appear across the document tree. I do not see detailed consistancy across different documents as necessary beyond what I've stated above. This is the reality of software development. I'm sure Apache doesn't coordinate its various projects' versioning (see http://www.apache.org/foundation/roles.html, "Individual projects define their own rules to add additional structure to their development processes."). > 3. The official doc collection is aimed at the whole VO community and beyond; > if a revision is considered so minor that it isn't reflected within the first 2 > version number components then by definition it is not worth bothering the > whole community. This is incorrect. Any change in a standard--however minor--that affects how the standard is implemented must be versioned (example: IVOA Identifiers 1.1). (This excludes typo-level changes.) cheers, Ray From owner-stdproc@eso.org Sat Apr 3 17:07:21 2004 Return-Path: Received: from mercury.hq.eso.org (localhost [127.0.0.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i33F73Uc009360 for ; Sat, 3 Apr 2004 17:07:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i33F72VL009359 for stdproc-outgoing; Sat, 3 Apr 2004 17:07:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-stdproc@eso.org using -f Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i33F6rUc009348; Sat, 3 Apr 2004 17:06:53 +0200 (MEST) Received: from eso.org (pc003499.hq.eso.org [134.171.40.117]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i33F6rs24819; Sat, 3 Apr 2004 17:06:53 +0200 (MEST) Message-ID: <406ED31C.7070309@eso.org> Date: Sat, 03 Apr 2004 17:07:08 +0200 From: Markus Dolensky Organization: European Southern Observatory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en, de-AT MIME-Version: 1.0 To: Ray Plante CC: IVOA stdproc WG Subject: Re: 4 reasons why ver. # suffice + 3 reasons why more is harmful References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-stdproc@eso.org Precedence: bulk Reply-To: Markus Dolensky X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi, Ray, to my believe the main source of disagreement on your proposed version scheme is that we have a different idea of its scope. The DC needs to enumerate documents - again, documents only - in a way that is enough for readers to identify them. This is already the case by assigning a release date and title. Even the simplest version number is already redundant information in this context. All the rest of the discussion belongs to software development and maintenance - it's nothing that the reader of standard documents needs to worry about and therefore such internal bookkeeping doesn't need to be exposed on the official doc. tree and hence DC doesn't need to worry about it. > So, if can suffer through more of my opinion, read my detailed reactions > below. ditto ... In the note (http://www.ivoa.net/Documents/latest/DocStdProc.html) it says that there can be supplementary resources (like Schema) which the DC publishes as is, i.e., embedded version info stays untouched. This will assure consistency with the source of information which is most likely some CVS system or some other dev. suite that is assigning revision numbers. Mapping such numbers to a uniform IVOA scheme implies that there can be 2(!) version numbers for the same item. If you think this is really essential and justifies the overhead of such an endless source of potential confusion then I'm not against introducing such a scheme: BUT, the mapping of the two namespaces has to be maintained internally (for instance on the Wiki) and by the relevant people in each WG and NOT at all by the DC. I vehemently object to offload the task of enumerating configuration files onto the shoulder of the DC. (For instance, the Wiki uses RCS to automatically assign revision numbers to topics and each attachment. It'll be fun to maintain a mapping with this kind of source.) Conclusion: 1. introduce an IVOA version scheme (on top of RCS, CVS etc.) where the community considers it essential, but not for the official doc. tree. 2. If it appears inconsistent to have a doc. tree with a different scheme, then let's remove version numbers from official documents altogether and simply use title and release date to identify them. Markus From stdproc-bounces@ivoa.net Thu Jul 2 17:08:17 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 5F1876242D7 for ; Thu, 2 Jul 2009 17:08:16 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8Gun017607 for ; Thu, 2 Jul 2009 17:08:16 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id D4979ECA3BF; Thu, 2 Jul 2009 17:08:15 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 230CCECA3B0; Thu, 2 Jul 2009 17:08:14 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.45.132] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8D9f017592; Thu, 2 Jul 2009 17:08:13 +0200 (MEST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by flux.hq.eso.org (Postfix) with ESMTP id 41281B6647; Thu, 2 Jul 2009 17:03:23 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-4.tower-178.messagelabs.com!1246547289!6201165!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG Received: (qmail 16858 invoked from network); 2 Jul 2009 15:08:11 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-4.tower-178.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 2 Jul 2009 15:08:11 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGC35659 (AUTH hanisch); Thu, 2 Jul 2009 11:08:08 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Jul 2009 11:08:06 -0400 Subject: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn7JucFJW3nnGcaEd6B/AARJN7wDA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: interop@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On behalf of the Standing Committee on Standards and Processes, I have posted responses to the comments that came in during the recent RFC. (And I apologize that these responses were not posted in a more timely manner!) Please see the RFC page for details. http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 In order to make sure that there is broad review and understanding of this document, as it is the basis for all document promotion processes in the IVOA, I am posting this overview to the stdproc and interop distribution lists. Detailed discussion is best carried out on the stdproc list, but that list has not been used much for a few years. Further comments can also be posted on the RFC page above. Several comments on the RFC were posted regarding the need for interoperable implementations and validators. The Committee agrees that some strengthening of the language in the document on this matter is warranted. In particular, item 4 concerning the promotion from Working Draft to Proposed Recommendation currently reads: "4. Each feature of the Working Draft has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature, and validation tools should be available. If the chair of the Working Group believes that broader review is critical, the chair may advance the document to Proposed Recommendation even without adequate implementation experience. In this case, the document status section should indicate why the chair promoted the document directly to Proposed Recommendation. A report describing the implementations or any associated validation tools may be published as a Note, or may be documented as part of the Request for Comments (see below)." Several people argued that having at least two interoperable implementations and at least one validator service should be mandatory. As noted in the RFC response, however, the Committee feels that making software implementations mandatory is beyond the scope of the IVOA. One might argue that if one or more VO projects invests the efforts into developing the standard itself, it follows that they would put effort into implementations and validators. But this could put a lot of pressure on schedule and resources of individual projects, and could lead to major delays in the promotion process. I think we can remove the "Preferably" language above, which seems very soft, and make the text a SHOULD in the canonical sense. Similarly the "may" in the last sentence can become SHOULD. If we are to embrace the idea that implementations and validators are to become mandatory, it would be important to hear from the project managers as to whether or not they are willing to support this requirement. Speaking as project manager of NVO I would have some reticence, especially now when we have no resources to follow through. Please follow up with comments to stdproc@ivoa.net, and if you wish to participate in this discussion make sure you are on that list. thanks, Bob From interop-bounces@ivoa.net Thu Jul 2 17:08:17 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 70CB6624196 for ; Thu, 2 Jul 2009 17:08:16 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8GKj017609 for ; Thu, 2 Jul 2009 17:08:16 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 82703ECA3B2; Thu, 2 Jul 2009 17:08:15 +0200 (CEST) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 230CCECA3B0; Thu, 2 Jul 2009 17:08:14 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.45.132] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8D9f017592; Thu, 2 Jul 2009 17:08:13 +0200 (MEST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by flux.hq.eso.org (Postfix) with ESMTP id 41281B6647; Thu, 2 Jul 2009 17:03:23 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-4.tower-178.messagelabs.com!1246547289!6201165!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG Received: (qmail 16858 invoked from network); 2 Jul 2009 15:08:11 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-4.tower-178.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 2 Jul 2009 15:08:11 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGC35659 (AUTH hanisch); Thu, 2 Jul 2009 11:08:08 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Jul 2009 11:08:06 -0400 Subject: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn7JucFJW3nnGcaEd6B/AARJN7wDA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: interop@ivoa.net X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net On behalf of the Standing Committee on Standards and Processes, I have posted responses to the comments that came in during the recent RFC. (And I apologize that these responses were not posted in a more timely manner!) Please see the RFC page for details. http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 In order to make sure that there is broad review and understanding of this document, as it is the basis for all document promotion processes in the IVOA, I am posting this overview to the stdproc and interop distribution lists. Detailed discussion is best carried out on the stdproc list, but that list has not been used much for a few years. Further comments can also be posted on the RFC page above. Several comments on the RFC were posted regarding the need for interoperable implementations and validators. The Committee agrees that some strengthening of the language in the document on this matter is warranted. In particular, item 4 concerning the promotion from Working Draft to Proposed Recommendation currently reads: "4. Each feature of the Working Draft has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature, and validation tools should be available. If the chair of the Working Group believes that broader review is critical, the chair may advance the document to Proposed Recommendation even without adequate implementation experience. In this case, the document status section should indicate why the chair promoted the document directly to Proposed Recommendation. A report describing the implementations or any associated validation tools may be published as a Note, or may be documented as part of the Request for Comments (see below)." Several people argued that having at least two interoperable implementations and at least one validator service should be mandatory. As noted in the RFC response, however, the Committee feels that making software implementations mandatory is beyond the scope of the IVOA. One might argue that if one or more VO projects invests the efforts into developing the standard itself, it follows that they would put effort into implementations and validators. But this could put a lot of pressure on schedule and resources of individual projects, and could lead to major delays in the promotion process. I think we can remove the "Preferably" language above, which seems very soft, and make the text a SHOULD in the canonical sense. Similarly the "may" in the last sentence can become SHOULD. If we are to embrace the idea that implementations and validators are to become mandatory, it would be important to hear from the project managers as to whether or not they are willing to support this requirement. Speaking as project manager of NVO I would have some reticence, especially now when we have no resources to follow through. Please follow up with comments to stdproc@ivoa.net, and if you wish to participate in this discussion make sure you are on that list. thanks, Bob From interop-bounces@ivoa.net Thu Jul 2 17:08:18 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 483DB6242C6; Thu, 2 Jul 2009 17:08:17 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8GEj017608; Thu, 2 Jul 2009 17:08:16 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 82703ECA3B2; Thu, 2 Jul 2009 17:08:15 +0200 (CEST) X-Original-To: interop@pat.hq.eso.org Delivered-To: interop@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 230CCECA3B0; Thu, 2 Jul 2009 17:08:14 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.45.132] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62F8D9f017592; Thu, 2 Jul 2009 17:08:13 +0200 (MEST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by flux.hq.eso.org (Postfix) with ESMTP id 41281B6647; Thu, 2 Jul 2009 17:03:23 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-4.tower-178.messagelabs.com!1246547289!6201165!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG Received: (qmail 16858 invoked from network); 2 Jul 2009 15:08:11 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-4.tower-178.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 2 Jul 2009 15:08:11 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGC35659 (AUTH hanisch); Thu, 2 Jul 2009 11:08:08 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Jul 2009 11:08:06 -0400 Subject: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn7JucFJW3nnGcaEd6B/AARJN7wDA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: interop@ivoa.net X-BeenThere: interop@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Interoperability Forum - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: interop-bounces@ivoa.net On behalf of the Standing Committee on Standards and Processes, I have posted responses to the comments that came in during the recent RFC. (And I apologize that these responses were not posted in a more timely manner!) Please see the RFC page for details. http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 In order to make sure that there is broad review and understanding of this document, as it is the basis for all document promotion processes in the IVOA, I am posting this overview to the stdproc and interop distribution lists. Detailed discussion is best carried out on the stdproc list, but that list has not been used much for a few years. Further comments can also be posted on the RFC page above. Several comments on the RFC were posted regarding the need for interoperable implementations and validators. The Committee agrees that some strengthening of the language in the document on this matter is warranted. In particular, item 4 concerning the promotion from Working Draft to Proposed Recommendation currently reads: "4. Each feature of the Working Draft has been implemented. Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature, and validation tools should be available. If the chair of the Working Group believes that broader review is critical, the chair may advance the document to Proposed Recommendation even without adequate implementation experience. In this case, the document status section should indicate why the chair promoted the document directly to Proposed Recommendation. A report describing the implementations or any associated validation tools may be published as a Note, or may be documented as part of the Request for Comments (see below)." Several people argued that having at least two interoperable implementations and at least one validator service should be mandatory. As noted in the RFC response, however, the Committee feels that making software implementations mandatory is beyond the scope of the IVOA. One might argue that if one or more VO projects invests the efforts into developing the standard itself, it follows that they would put effort into implementations and validators. But this could put a lot of pressure on schedule and resources of individual projects, and could lead to major delays in the promotion process. I think we can remove the "Preferably" language above, which seems very soft, and make the text a SHOULD in the canonical sense. Similarly the "may" in the last sentence can become SHOULD. If we are to embrace the idea that implementations and validators are to become mandatory, it would be important to hear from the project managers as to whether or not they are willing to support this requirement. Speaking as project manager of NVO I would have some reticence, especially now when we have no resources to follow through. Please follow up with comments to stdproc@ivoa.net, and if you wish to participate in this discussion make sure you are on that list. thanks, Bob From stdproc-bounces@ivoa.net Thu Jul 2 19:34:05 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 9DBE0624194 for ; Thu, 2 Jul 2009 19:34:05 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62HY5ev005357 for ; Thu, 2 Jul 2009 19:34:05 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 716E2ECA3A3; Thu, 2 Jul 2009 19:34:05 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 6A310ECA38F for ; Thu, 2 Jul 2009 19:34:03 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.45.132] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62HY3Vk005353 for ; Thu, 2 Jul 2009 19:34:03 +0200 (MEST) Received: from mail188.messagelabs.com (mail188.messagelabs.com [85.158.139.163]) by flux.hq.eso.org (Postfix) with SMTP id 7B4B8B663C for ; Thu, 2 Jul 2009 19:29:12 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: m.b.taylor@bristol.ac.uk X-Msg-Ref: server-14.tower-188.messagelabs.com!1246556041!40778397!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [137.222.58.39] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG Received: (qmail 25898 invoked from network); 2 Jul 2009 17:34:01 -0000 Received: from sol.star.bris.ac.uk (HELO sol.star.bris.ac.uk) (137.222.58.39) by server-14.tower-188.messagelabs.com with SMTP; 2 Jul 2009 17:34:01 -0000 Received: from andromeda.star.bris.ac.uk ([137.222.58.155]) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1MMQAY-00063c-00; Thu, 02 Jul 2009 18:33:58 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 4.43) id 1MMQAX-0004Ra-P7; Thu, 02 Jul 2009 18:33:57 +0100 Date: Thu, 2 Jul 2009 18:33:57 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: Robert Hanisch Subject: Re: IVOA Document Standards RFC V1.2 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On Thu, 2 Jul 2009, Robert Hanisch wrote: > On behalf of the Standing Committee on Standards and Processes, I have > posted responses to the comments that came in during the recent RFC. (And I > apologize that these responses were not posted in a more timely manner!) > Please see the RFC page for details. > > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 > > In order to make sure that there is broad review and understanding of this > document, as it is the basis for all document promotion processes in the > IVOA, I am posting this overview to the stdproc and interop distribution > lists. Detailed discussion is best carried out on the stdproc list, but > that list has not been used much for a few years. Further comments can also > be posted on the RFC page above. > > Several comments on the RFC were posted regarding the need for interoperable > implementations and validators. The Committee agrees that some > strengthening of the language in the document on this matter is warranted. > In particular, item 4 concerning the promotion from Working Draft to > Proposed Recommendation currently reads: > > "4. Each feature of the Working Draft has been implemented. Preferably, > the Working Group should be able to demonstrate two interoperable > implementations of each feature, and validation tools should be available. > If the chair of the Working Group believes that broader review is critical, > the chair may advance the document to Proposed Recommendation even without > adequate implementation experience. In this case, the document status > section should indicate why the chair promoted the document directly to > Proposed Recommendation. A report describing the implementations or any > associated validation tools may be published as a Note, or may be documented > as part of the Request for Comments (see below)." > > Several people argued that having at least two interoperable implementations > and at least one validator service should be mandatory. As noted in the RFC > response, however, the Committee feels that making software implementations > mandatory is beyond the scope of the IVOA. One might argue that if one or > more VO projects invests the efforts into developing the standard itself, it > follows that they would put effort into implementations and validators. But > this could put a lot of pressure on schedule and resources of individual > projects, and could lead to major delays in the promotion process. > > I think we can remove the "Preferably" language above, which seems very > soft, and make the text a SHOULD in the canonical sense. Similarly the > "may" in the last sentence can become SHOULD. > > If we are to embrace the idea that implementations and validators are to > become mandatory, it would be important to hear from the project managers as > to whether or not they are willing to support this requirement. Speaking as > project manager of NVO I would have some reticence, especially now when we > have no resources to follow through. > > Please follow up with comments to stdproc@ivoa.net, and if you wish to > participate in this discussion make sure you are on that list. Bob, thanks for the response. I would like to take issue with it on two main grounds: firstly that I don't find the 'out of scope' argument convincing given what is clearly in scope for the IVOA, and secondly that I believe the effort saved by not requiring these things is in fact illusory. >From the response on the RFC page: "The problem we see with making such implementations mandatory is really one of scope and authority of the IVOA. The IVOA has no funding to support such activities, and thus the IVOA has no basis for demanding such things. If we were in position to fund such work, that would be one thing, but were are not; we rely on the goodwill and resources of the VO projects. -- BobHanisch on behalf of the Committee" I don't follow the argument that since the IVOA does not fund writing of implementations or validators, it cannot mandate them. Exactly the same could be said about writing the text of the standards documents themselves. Writing and reviewing the standards can require a great deal of time and effort from contributors, as I'm sure that you and many readers of this list know first hand, but the IVOA feels able to state requirements about these without providing any funding for the authorship or review process. "If we make interoperable implementations and a validator mandatory, how do we make sure that they get developed? Who validates the validator? We have seen already that even our most experienced software engineers have written validators with errors in them. -- BobHanisch on behalf of the Committee" We make sure that they get developed in the same way that we (in principle, at any rate) currently ensure the quality of the written standards: by public review from those IVOA members who feel sufficiently motivated to participate, and by witholding Recommendation status until agreement among those participants has been reached. Regarding validating the validators: obviously I'm not suggesting that associated software with a bug count which is provably zero is to be a requirement. As with the standards text, the authors make their best efforts in good faith, and if others scrutinising their work believe there are problems with it these are addressed by discussion. Yes this system is open to abuse (people claiming they have a validator when it doesn't do much validation), but we're mostly grown ups here. The measure of success of the IVOA is surely not how many standards it can churn out, it's more about the amount those standards are used, which in turn has to depend on the existence and quality of the implementations of those standards. Surely, a standard only becomes worth anything when at least one usable implementation exists. Here is the most important part of my argument: Postulate: If your goal is to reach an implementation, it is much easier (you can do it both faster and better; also, for the benefit of project managers, cheaper) to write the implementation and validation alongside the standard than it is to write the standard on paper, get it set in stone, and then start to write the software. The reason is that when you write it down on paper, there is a very good chance that you will write things which are contradictory or ambiguous or conflict with other established standards or are hard or impossible to implement. These are things you will stand a much much better chance of spotting if you are writing software alongside the text. The arguments for implementations and validators are similar but slightly different; I can elaborate on request. Based on my experience I believe that the postulate above is true: I would like to know whether the DocStd committee believe it is true, false, or just not relevant here. Finally, I should concede that the software requirement is clearly inapplicable in some cases - for instance I'm not suggesing that a validation suite be required for the DocStd document itself. So some concession about applicability should be included in the discussion of requirements. I'm happy to hear other people's views on this ... Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From stdproc-bounces@ivoa.net Thu Jul 2 19:57:23 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 6D381624196 for ; Thu, 2 Jul 2009 19:57:23 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62HvNOd007333 for ; Thu, 2 Jul 2009 19:57:23 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 2C0FCECA39F; Thu, 2 Jul 2009 19:57:23 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 3254FECA38D for ; Thu, 2 Jul 2009 19:57:21 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.45.132] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62HvKDV007326 for ; Thu, 2 Jul 2009 19:57:21 +0200 (MEST) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by flux.hq.eso.org (Postfix) with ESMTP id 30EBCB65F4 for ; Thu, 2 Jul 2009 19:52:30 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-8.tower-193.messagelabs.com!1246557438!16938649!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG Received: (qmail 8164 invoked from network); 2 Jul 2009 17:57:19 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-8.tower-193.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 2 Jul 2009 17:57:19 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGC58898 (AUTH hanisch); Thu, 2 Jul 2009 13:57:05 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Jul 2009 13:57:04 -0400 Subject: Re: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Mark Taylor Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn7PoG9wE6sYmcxEd6B/AARJN7wDA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Thanks Mark, for the (as usual) thoughtful comments. First, let me quote myself in the e-mail message I sent earlier today: "One might argue that if one or more VO projects invests the efforts into developing the standard itself, it follows that they would put effort into implementations and validators. But this could put a lot of pressure on schedule and resources of individual projects, and could lead to major delays in the promotion process." I agree completely with you that doing implementations in parallel with standards development is the best way to go, with the obvious exception that some of the IVOA standards, as you point out, are not really about software implementations. But making the implementations and the validator mandatory for promotion is where I, and Christophe and Francoise, feel it is necessary to pause. For example, if right now we were to enforce this requirement on TAP, with the resource constraints we have in several of the major projects, we would be forced to stop the promotion process. This would be an awful situation for IVOA, I think. We want prototypes to inform the standards development process, for sure, we SHOULD have them, but from a management perspective I think we have to avoid boxing ourselves into a corner. It is also a bit ambiguous just how one proves that implementations are interoperable. So far we have taken people's word, but IVOA has no means to independently test these assertions. I would probably agree fully with you if, say, IVOA were a dues-based membership organization, with its own financial resources to build validators, or test those developed by others. But I see a distinction, albeit a subtle one, between the projects' willingness to contribute to development of a standard and their ability to provide supporting software and validators on a timescale that does not jeopardize the promotion process. Finally, in any case, we have a revision system that is there to deal with problems and shortcomings found in earlier versions. If V1.0 of a standard ends up having problems -- unsupportable features, inconsistencies, etc. (and we have had this experience) -- then we fix the problems in V1.x or V2.0. So, as I said to begin with, I do believe we need to strengthen the language, but I am very reluctant to make things mandatory. Bob On 7/2/09 1:33 PM, "Mark Taylor" wrote: > On Thu, 2 Jul 2009, Robert Hanisch wrote: > >> On behalf of the Standing Committee on Standards and Processes, I have >> posted responses to the comments that came in during the recent RFC. (And I >> apologize that these responses were not posted in a more timely manner!) >> Please see the RFC page for details. >> >> http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 >> >> In order to make sure that there is broad review and understanding of this >> document, as it is the basis for all document promotion processes in the >> IVOA, I am posting this overview to the stdproc and interop distribution >> lists. Detailed discussion is best carried out on the stdproc list, but >> that list has not been used much for a few years. Further comments can also >> be posted on the RFC page above. >> >> Several comments on the RFC were posted regarding the need for interoperable >> implementations and validators. The Committee agrees that some >> strengthening of the language in the document on this matter is warranted. >> In particular, item 4 concerning the promotion from Working Draft to >> Proposed Recommendation currently reads: >> >> "4. Each feature of the Working Draft has been implemented. Preferably, >> the Working Group should be able to demonstrate two interoperable >> implementations of each feature, and validation tools should be available. >> If the chair of the Working Group believes that broader review is critical, >> the chair may advance the document to Proposed Recommendation even without >> adequate implementation experience. In this case, the document status >> section should indicate why the chair promoted the document directly to >> Proposed Recommendation. A report describing the implementations or any >> associated validation tools may be published as a Note, or may be documented >> as part of the Request for Comments (see below)." >> >> Several people argued that having at least two interoperable implementations >> and at least one validator service should be mandatory. As noted in the RFC >> response, however, the Committee feels that making software implementations >> mandatory is beyond the scope of the IVOA. One might argue that if one or >> more VO projects invests the efforts into developing the standard itself, it >> follows that they would put effort into implementations and validators. But >> this could put a lot of pressure on schedule and resources of individual >> projects, and could lead to major delays in the promotion process. >> >> I think we can remove the "Preferably" language above, which seems very >> soft, and make the text a SHOULD in the canonical sense. Similarly the >> "may" in the last sentence can become SHOULD. >> >> If we are to embrace the idea that implementations and validators are to >> become mandatory, it would be important to hear from the project managers as >> to whether or not they are willing to support this requirement. Speaking as >> project manager of NVO I would have some reticence, especially now when we >> have no resources to follow through. >> >> Please follow up with comments to stdproc@ivoa.net, and if you wish to >> participate in this discussion make sure you are on that list. > > Bob, > > thanks for the response. I would like to take issue with it on two > main grounds: firstly that I don't find the 'out of scope' argument > convincing given what is clearly in scope for the IVOA, and secondly > that I believe the effort saved by not requiring these things is > in fact illusory. > > From the response on the RFC page: > > "The problem we see with making such implementations mandatory is > really one of scope and authority of the IVOA. The IVOA has no > funding to support such activities, and thus the IVOA has no basis > for demanding such things. If we were in position to fund such work, > that would be one thing, but were are not; we rely on the goodwill > and resources of the VO projects. > -- BobHanisch on behalf of the Committee" > > I don't follow the argument that since the IVOA does not fund writing > of implementations or validators, it cannot mandate them. > Exactly the same could be said about writing the text of the > standards documents themselves. Writing and reviewing the standards > can require a great deal of time and effort from contributors, > as I'm sure that you and many readers of this list know first hand, > but the IVOA feels able to state requirements about these without > providing any funding for the authorship or review process. > > "If we make interoperable implementations and a validator mandatory, > how do we make sure that they get developed? Who validates the > validator? We have seen already that even our most experienced software > engineers have written validators with errors in them. > -- BobHanisch on behalf of the Committee" > > We make sure that they get developed in the same way that we > (in principle, at any rate) currently ensure the quality of the written > standards: by public review from those IVOA members who feel > sufficiently motivated to participate, and by witholding Recommendation > status until agreement among those participants has been reached. > Regarding validating the validators: obviously I'm not suggesting > that associated software with a bug count which is provably zero is > to be a requirement. As with the standards text, the authors make > their best efforts in good faith, and if others scrutinising their > work believe there are problems with it these are addressed by > discussion. Yes this system is open to abuse (people claiming they > have a validator when it doesn't do much validation), but we're > mostly grown ups here. > > The measure of success of the IVOA is surely not how many standards > it can churn out, it's more about the amount those standards are used, > which in turn has to depend on the existence and quality of the > implementations of those standards. Surely, a standard only becomes > worth anything when at least one usable implementation exists. Here is > the most important part of my argument: > > Postulate: If your goal is to reach an implementation, it is much > easier (you can do it both faster and better; also, for the > benefit of project managers, cheaper) to write the > implementation and validation alongside the standard than it is > to write the standard on paper, get it set in stone, and then > start to write the software. > > The reason is that when you write it down on paper, there is a very > good chance that you will write things which are contradictory or > ambiguous or conflict with other established standards or are hard or > impossible to implement. These are things you will stand a much much > better chance of spotting if you are writing software alongside the > text. The arguments for implementations and validators are similar > but slightly different; I can elaborate on request. > > Based on my experience I believe that the postulate above is true: > I would like to know whether the DocStd committee believe it is > true, false, or just not relevant here. > > Finally, I should concede that the software requirement is clearly > inapplicable in some cases - for instance I'm not suggesing that > a validation suite be required for the DocStd document itself. > So some concession about applicability should be included in the > discussion of requirements. > > I'm happy to hear other people's views on this ... > > Mark From stdproc-bounces@ivoa.net Thu Jul 2 21:19:31 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 8C3F2624194 for ; Thu, 2 Jul 2009 21:19:31 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JJVJk020285 for ; Thu, 2 Jul 2009 21:19:31 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 31DD0ECA3A3; Thu, 2 Jul 2009 21:19:31 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id AC04DECA320 for ; Thu, 2 Jul 2009 21:19:29 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JJTmr020282 for ; Thu, 2 Jul 2009 21:19:29 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by aeon.hq.eso.org (Postfix) with ESMTP id EBB505A655 for ; Thu, 2 Jul 2009 21:19:28 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: mjg@cacr.caltech.edu X-Msg-Ref: server-5.tower-186.messagelabs.com!1246562364!9830617!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.215.148.6] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 8938 invoked from network); 2 Jul 2009 19:19:26 -0000 Received: from ben-franklin.cacr.caltech.edu (HELO ben-franklin.cacr.caltech.edu) (131.215.148.6) by server-5.tower-186.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:19:26 -0000 Received: from brighid.cacr.caltech.edu (brighid.cacr.caltech.edu [131.215.146.27]) (authenticated bits=0) by ben-franklin.cacr.caltech.edu (8.13.8/8.13.8) with ESMTP id n62JJNQ7028902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 2 Jul 2009 12:19:24 -0700 Message-Id: <833254ED-BA5D-4D10-8536-46DAFEBE4989@cacr.caltech.edu> From: Matthew Graham To: stdproc@ivoa.net Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Versioning Date: Thu, 2 Jul 2009 12:19:23 -0700 X-Mailer: Apple Mail (2.935.3) X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Hi, This is a discussion that I started within my WG just to solicit opinion. Can the Standards WG please clarify: The response was posted to my comments on the RFC page: "The Committee agrees that the version numbering scheme is challenging when dealing with namespaces and WSDL, and leads to the conclusion that when IVOA standards describe web services or have associated XML schemas, with namespaces that when changed, cause software to break, then these changes must both be accompanied by an increment to the integer part of the document and the associated "supplementary" files. This would not affect most of the standards documents, and should not present any real logistical difficulty, as there are a sufficient number of integers available to support any number of revisions. " I explain: This has greatest impact for this working group (GWS but I am also cross-posting to Semantics) and essentially means that ALL (WD, PR, etc) versions of our specs with WSDL/XML/RDF documents (anything with a namespace) will only carry integer versions. So, for example, the progression of VOSpace 2.0 would actually proceed as: VOSpace 2 (first WD) VOSpace 3 (second WD) VOSpace 4 (third WD) VOSpace 5 (first PR) VOSpace 6 (second PR) VOSpace 7 (final PR) VOSpace 8 (REC) The next version would then VOSpace 9, etc. Is this a valid interpretation of the spec? The standards documents says: "The number to the left of the (first) decimal point starts with 0 for documents that are being discussed within a Working Group prior to publication for IVOA-wide review. The number increments to 1 for the first public version, and to 2, 3, ..., for subsequent versions that are not backward compatible and/or require substantial revisions to implementations." The definition of a Working Draft is: "A Working Draft is published at the discretion of a Working Group once the WG is satisfied that the document is sufficiently developed to merit broader exposure and feedback" So I think that a Working Draft fulfils the "IVOA-wide review" criterion. The alternate suggestion from Dave Morris and with much support is: If the integer rule only applied to something that has been accepted as a recommendation. VOSpace 2.0-yyymmdd (first WD) VOSpace 2.0-yyymmdd (second WD) VOSpace 2.0-yyymmdd (third WD) VOSpace 2.0-yyymmdd (first PR) VOSpace 2.0-yyymmdd (second PR) VOSpace 2.0-yyymmdd (final PR) VOSpace 2.0 (REC) VOSpace 2.1-yyymmdd (first WD) (minor text changes only) VOSpace 2.1-yyymmdd (final PR) (minor text changes only) VOSpace 2.1 (REC) VOSpace 3.0-yyymmdd (first WD) (changes to service behavior or xml schema) ... I think this needs to be clarified one way or the other. Cheers, Matthew From tcg-bounces@ivoa.net Thu Jul 2 21:48:36 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id A95F7624194 for ; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62Jmaca022945 for ; Thu, 2 Jul 2009 21:48:36 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 77E88ECA360; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) X-Original-To: tcg@pat.hq.eso.org Delivered-To: tcg@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id DCB65ECA320; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmYPG022938; Thu, 2 Jul 2009 21:48:34 +0200 (MEST) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by aeon.hq.eso.org (Postfix) with ESMTP id 4B3675A65A; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: paul.harrison@manchester.ac.uk X-Msg-Ref: server-8.tower-194.messagelabs.com!1246564113!25813600!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.88.200.94] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjg4LjIwMC45NCA9PiA0NTUwNg==\n Received: (qmail 10612 invoked from network); 2 Jul 2009 19:48:34 -0000 Received: from probity.mcc.ac.uk (HELO probity.mcc.ac.uk) (130.88.200.94) by server-8.tower-194.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:48:34 -0000 Received: from star1.jb.man.ac.uk ([130.88.24.176]) by probity.mcc.ac.uk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSGl-0002N2-Sc; Thu, 02 Jul 2009 20:48:31 +0100 Received: from [130.88.24.18] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1MMSGl-0002OG-00; Thu, 02 Jul 2009 20:48:31 +0100 Message-Id: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> From: Paul Harrison To: Matthew Graham In-Reply-To: <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Versioning Date: Thu, 2 Jul 2009 20:48:01 +0100 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> X-Mailer: Apple Mail (2.935.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. Cc: IVOA TCG , Grid_Ivoa_List , Doug Tody , stdproc@ivoa.net X-BeenThere: tcg@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Technical Co-ordinating Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcg-bounces@ivoa.net Hi All, During the discussion that took place on this before the latest Standards document the consensus was that for a document name of the form WD-VOSpace-2.0-yyyymmdd * That the 2.0 was the version number of the "protocol/standard" * yyyymmdd was effectively the version number of the document What was not explicitly thought about is the progression from a version 1.0 to a version 2.0 of a protocol, - in this case the document numbering can only start and stay with 2.0 from first WD to REC - even though there might be substantial (protocol/interface) changes between the drafts (which would make the programmer in us want to change the version number). Only after reaching the REC status does the "2.0" number have to change. What should be removed from the Standards document is the idea of a public WD that has a 0.x number, as this is logically inconsistent with the new scheme - the first public WD of a new protocol/standard should have a 1.0 number - the new numbering scheme was intended to remove this ambiguity, but I agree that the Standards document still does not make it clear. Under this numbering scheme, what is currently VOTable 1.2 should really be VOTable 2.0 in my opinion, as it causes VOTable 1.1 xml to be invalid, even though the changes in the written document look quite minimal. However, I am not sure who will police this sort of issue..... Cheers, Paul. On 2009-07 -02, at 19:07, Matthew Graham wrote: > Hi Doug, > > The standards documents says: > > "The number to the left of the (first) decimal point starts with 0 > for documents that are being discussed within a Working Group prior > to publication for IVOA-wide review. The number increments to 1 for > the first public version, and to 2, 3, ..., for subsequent versions > that are not backward compatible and/or require substantial > revisions to implementations." > > The definition of a Working Draft is: > > "A Working Draft is published at the discretion of a Working Group > once the WG is satisfied that the document is sufficiently developed > to merit broader exposure and feedback" > > So I think that a Working Draft fulfils the "IVOA-wide review" > criterion. > > If the integer progression is only a prerequisite for REC versions > then the standards document needs to be amended to say this. > > Cheers, > > Matthew > > > On Jul 2, 2009, at 10:52 AM, Doug Tody wrote: > >> If this were true I agree it would be crazy. But is a WD or PR a >> "standard"? I should think this would only apply to established >> standards that are already deployed. That is, to recommendations. >> Perhaps the documents and standards folks should clarify. >> >> Also, I don't think this is just limited to GWS; any DAL or DM >> standard >> for example might also have to deal with this issue. >> >> - Doug >> >> >> On Thu, 2 Jul 2009, Matthew Graham wrote: >> >>> Hi, >>> >>> You might be aware that the Document Standards v1.2 PR has just >>> completed its RFC (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 >>> ). I raised concerns about the proposed versioning scheme: >>> >>> "The document now states that there is an integer increment in the >>> version number in the case where subsequent versions are not >>> backward compatible. " >>> >>> and the response that has been posted is: >>> >>> "The Committee agrees that the version numbering scheme is >>> challenging when dealing with namespaces and WSDL, and leads to >>> the conclusion that when IVOA standards describe web services or >>> have associated XML schemas, with namespaces that when changed, >>> cause software to break, then these changes must both be >>> accompanied by an increment to the integer part of the document >>> and the associated "supplementary" files. This would not affect >>> most of the standards documents, and should not present any real >>> logistical difficulty, as there are a sufficient number of >>> integers available to support any number of revisions. " >>> >>> This has greatest impact for this working group (GWS but I am also >>> cross-posting to Semantics) and essentially means that ALL (WD, >>> PR, etc) versions of our specs with WSDL/XML/RDF documents >>> (anything with a namespace) will only carry integer versions. >>> >>> So, for example, the progression of VOSpace 2.0 would actually >>> proceed as: >>> >>> VOSpace 2 (first WD) >>> VOSpace 3 (second WD) >>> VOSpace 4 (third WD) >>> VOSpace 5 (first PR) >>> VOSpace 6 (second PR) >>> VOSpace 7 (final PR) >>> VOSpace 8 (REC) >>> >>> The next version would then VOSpace 9, etc. >>> >>> Although this is very much a procedural issue, I just wanted to >>> flag it so that everyone is aware and happy with it before I >>> approve. >>> >>> Cheers, >>> >>> Matthew >>> >> > From stdproc-bounces@ivoa.net Thu Jul 2 21:48:37 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id D702C6242D7 for ; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmaIJ022950 for ; Thu, 2 Jul 2009 21:48:36 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id A7813ECA360; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id DCB65ECA320; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmYPG022938; Thu, 2 Jul 2009 21:48:34 +0200 (MEST) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by aeon.hq.eso.org (Postfix) with ESMTP id 4B3675A65A; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: paul.harrison@manchester.ac.uk X-Msg-Ref: server-8.tower-194.messagelabs.com!1246564113!25813600!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.88.200.94] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjg4LjIwMC45NCA9PiA0NTUwNg==\n Received: (qmail 10612 invoked from network); 2 Jul 2009 19:48:34 -0000 Received: from probity.mcc.ac.uk (HELO probity.mcc.ac.uk) (130.88.200.94) by server-8.tower-194.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:48:34 -0000 Received: from star1.jb.man.ac.uk ([130.88.24.176]) by probity.mcc.ac.uk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSGl-0002N2-Sc; Thu, 02 Jul 2009 20:48:31 +0100 Received: from [130.88.24.18] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1MMSGl-0002OG-00; Thu, 02 Jul 2009 20:48:31 +0100 Message-Id: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> From: Paul Harrison To: Matthew Graham In-Reply-To: <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Versioning Date: Thu, 2 Jul 2009 20:48:01 +0100 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> X-Mailer: Apple Mail (2.935.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. Cc: IVOA TCG , Grid_Ivoa_List , Doug Tody , stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Hi All, During the discussion that took place on this before the latest Standards document the consensus was that for a document name of the form WD-VOSpace-2.0-yyyymmdd * That the 2.0 was the version number of the "protocol/standard" * yyyymmdd was effectively the version number of the document What was not explicitly thought about is the progression from a version 1.0 to a version 2.0 of a protocol, - in this case the document numbering can only start and stay with 2.0 from first WD to REC - even though there might be substantial (protocol/interface) changes between the drafts (which would make the programmer in us want to change the version number). Only after reaching the REC status does the "2.0" number have to change. What should be removed from the Standards document is the idea of a public WD that has a 0.x number, as this is logically inconsistent with the new scheme - the first public WD of a new protocol/standard should have a 1.0 number - the new numbering scheme was intended to remove this ambiguity, but I agree that the Standards document still does not make it clear. Under this numbering scheme, what is currently VOTable 1.2 should really be VOTable 2.0 in my opinion, as it causes VOTable 1.1 xml to be invalid, even though the changes in the written document look quite minimal. However, I am not sure who will police this sort of issue..... Cheers, Paul. On 2009-07 -02, at 19:07, Matthew Graham wrote: > Hi Doug, > > The standards documents says: > > "The number to the left of the (first) decimal point starts with 0 > for documents that are being discussed within a Working Group prior > to publication for IVOA-wide review. The number increments to 1 for > the first public version, and to 2, 3, ..., for subsequent versions > that are not backward compatible and/or require substantial > revisions to implementations." > > The definition of a Working Draft is: > > "A Working Draft is published at the discretion of a Working Group > once the WG is satisfied that the document is sufficiently developed > to merit broader exposure and feedback" > > So I think that a Working Draft fulfils the "IVOA-wide review" > criterion. > > If the integer progression is only a prerequisite for REC versions > then the standards document needs to be amended to say this. > > Cheers, > > Matthew > > > On Jul 2, 2009, at 10:52 AM, Doug Tody wrote: > >> If this were true I agree it would be crazy. But is a WD or PR a >> "standard"? I should think this would only apply to established >> standards that are already deployed. That is, to recommendations. >> Perhaps the documents and standards folks should clarify. >> >> Also, I don't think this is just limited to GWS; any DAL or DM >> standard >> for example might also have to deal with this issue. >> >> - Doug >> >> >> On Thu, 2 Jul 2009, Matthew Graham wrote: >> >>> Hi, >>> >>> You might be aware that the Document Standards v1.2 PR has just >>> completed its RFC (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 >>> ). I raised concerns about the proposed versioning scheme: >>> >>> "The document now states that there is an integer increment in the >>> version number in the case where subsequent versions are not >>> backward compatible. " >>> >>> and the response that has been posted is: >>> >>> "The Committee agrees that the version numbering scheme is >>> challenging when dealing with namespaces and WSDL, and leads to >>> the conclusion that when IVOA standards describe web services or >>> have associated XML schemas, with namespaces that when changed, >>> cause software to break, then these changes must both be >>> accompanied by an increment to the integer part of the document >>> and the associated "supplementary" files. This would not affect >>> most of the standards documents, and should not present any real >>> logistical difficulty, as there are a sufficient number of >>> integers available to support any number of revisions. " >>> >>> This has greatest impact for this working group (GWS but I am also >>> cross-posting to Semantics) and essentially means that ALL (WD, >>> PR, etc) versions of our specs with WSDL/XML/RDF documents >>> (anything with a namespace) will only carry integer versions. >>> >>> So, for example, the progression of VOSpace 2.0 would actually >>> proceed as: >>> >>> VOSpace 2 (first WD) >>> VOSpace 3 (second WD) >>> VOSpace 4 (third WD) >>> VOSpace 5 (first PR) >>> VOSpace 6 (second PR) >>> VOSpace 7 (final PR) >>> VOSpace 8 (REC) >>> >>> The next version would then VOSpace 9, etc. >>> >>> Although this is very much a procedural issue, I just wanted to >>> flag it so that everyone is aware and happy with it before I >>> approve. >>> >>> Cheers, >>> >>> Matthew >>> >> > From grid-bounces@ivoa.net Thu Jul 2 21:48:37 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 351EF6242D4; Thu, 2 Jul 2009 21:48:37 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmbEb022958; Thu, 2 Jul 2009 21:48:37 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id D9D44ECA3B6; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id DCB65ECA320; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmYPG022938; Thu, 2 Jul 2009 21:48:34 +0200 (MEST) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by aeon.hq.eso.org (Postfix) with ESMTP id 4B3675A65A; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: paul.harrison@manchester.ac.uk X-Msg-Ref: server-8.tower-194.messagelabs.com!1246564113!25813600!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.88.200.94] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjg4LjIwMC45NCA9PiA0NTUwNg==\n Received: (qmail 10612 invoked from network); 2 Jul 2009 19:48:34 -0000 Received: from probity.mcc.ac.uk (HELO probity.mcc.ac.uk) (130.88.200.94) by server-8.tower-194.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:48:34 -0000 Received: from star1.jb.man.ac.uk ([130.88.24.176]) by probity.mcc.ac.uk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSGl-0002N2-Sc; Thu, 02 Jul 2009 20:48:31 +0100 Received: from [130.88.24.18] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1MMSGl-0002OG-00; Thu, 02 Jul 2009 20:48:31 +0100 Message-Id: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> From: Paul Harrison To: Matthew Graham In-Reply-To: <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Versioning Date: Thu, 2 Jul 2009 20:48:01 +0100 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> X-Mailer: Apple Mail (2.935.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. Cc: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net Hi All, During the discussion that took place on this before the latest Standards document the consensus was that for a document name of the form WD-VOSpace-2.0-yyyymmdd * That the 2.0 was the version number of the "protocol/standard" * yyyymmdd was effectively the version number of the document What was not explicitly thought about is the progression from a version 1.0 to a version 2.0 of a protocol, - in this case the document numbering can only start and stay with 2.0 from first WD to REC - even though there might be substantial (protocol/interface) changes between the drafts (which would make the programmer in us want to change the version number). Only after reaching the REC status does the "2.0" number have to change. What should be removed from the Standards document is the idea of a public WD that has a 0.x number, as this is logically inconsistent with the new scheme - the first public WD of a new protocol/standard should have a 1.0 number - the new numbering scheme was intended to remove this ambiguity, but I agree that the Standards document still does not make it clear. Under this numbering scheme, what is currently VOTable 1.2 should really be VOTable 2.0 in my opinion, as it causes VOTable 1.1 xml to be invalid, even though the changes in the written document look quite minimal. However, I am not sure who will police this sort of issue..... Cheers, Paul. On 2009-07 -02, at 19:07, Matthew Graham wrote: > Hi Doug, > > The standards documents says: > > "The number to the left of the (first) decimal point starts with 0 > for documents that are being discussed within a Working Group prior > to publication for IVOA-wide review. The number increments to 1 for > the first public version, and to 2, 3, ..., for subsequent versions > that are not backward compatible and/or require substantial > revisions to implementations." > > The definition of a Working Draft is: > > "A Working Draft is published at the discretion of a Working Group > once the WG is satisfied that the document is sufficiently developed > to merit broader exposure and feedback" > > So I think that a Working Draft fulfils the "IVOA-wide review" > criterion. > > If the integer progression is only a prerequisite for REC versions > then the standards document needs to be amended to say this. > > Cheers, > > Matthew > > > On Jul 2, 2009, at 10:52 AM, Doug Tody wrote: > >> If this were true I agree it would be crazy. But is a WD or PR a >> "standard"? I should think this would only apply to established >> standards that are already deployed. That is, to recommendations. >> Perhaps the documents and standards folks should clarify. >> >> Also, I don't think this is just limited to GWS; any DAL or DM >> standard >> for example might also have to deal with this issue. >> >> - Doug >> >> >> On Thu, 2 Jul 2009, Matthew Graham wrote: >> >>> Hi, >>> >>> You might be aware that the Document Standards v1.2 PR has just >>> completed its RFC (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 >>> ). I raised concerns about the proposed versioning scheme: >>> >>> "The document now states that there is an integer increment in the >>> version number in the case where subsequent versions are not >>> backward compatible. " >>> >>> and the response that has been posted is: >>> >>> "The Committee agrees that the version numbering scheme is >>> challenging when dealing with namespaces and WSDL, and leads to >>> the conclusion that when IVOA standards describe web services or >>> have associated XML schemas, with namespaces that when changed, >>> cause software to break, then these changes must both be >>> accompanied by an increment to the integer part of the document >>> and the associated "supplementary" files. This would not affect >>> most of the standards documents, and should not present any real >>> logistical difficulty, as there are a sufficient number of >>> integers available to support any number of revisions. " >>> >>> This has greatest impact for this working group (GWS but I am also >>> cross-posting to Semantics) and essentially means that ALL (WD, >>> PR, etc) versions of our specs with WSDL/XML/RDF documents >>> (anything with a namespace) will only carry integer versions. >>> >>> So, for example, the progression of VOSpace 2.0 would actually >>> proceed as: >>> >>> VOSpace 2 (first WD) >>> VOSpace 3 (second WD) >>> VOSpace 4 (third WD) >>> VOSpace 5 (first PR) >>> VOSpace 6 (second PR) >>> VOSpace 7 (final PR) >>> VOSpace 8 (REC) >>> >>> The next version would then VOSpace 9, etc. >>> >>> Although this is very much a procedural issue, I just wanted to >>> flag it so that everyone is aware and happy with it before I >>> approve. >>> >>> Cheers, >>> >>> Matthew >>> >> > From grid-bounces@ivoa.net Thu Jul 2 21:48:38 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 4275D624196 for ; Thu, 2 Jul 2009 21:48:37 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmbGK022959 for ; Thu, 2 Jul 2009 21:48:37 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id D9D44ECA3B6; Thu, 2 Jul 2009 21:48:36 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id DCB65ECA320; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62JmYPG022938; Thu, 2 Jul 2009 21:48:34 +0200 (MEST) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by aeon.hq.eso.org (Postfix) with ESMTP id 4B3675A65A; Thu, 2 Jul 2009 21:48:34 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: paul.harrison@manchester.ac.uk X-Msg-Ref: server-8.tower-194.messagelabs.com!1246564113!25813600!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.88.200.94] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjg4LjIwMC45NCA9PiA0NTUwNg==\n Received: (qmail 10612 invoked from network); 2 Jul 2009 19:48:34 -0000 Received: from probity.mcc.ac.uk (HELO probity.mcc.ac.uk) (130.88.200.94) by server-8.tower-194.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2009 19:48:34 -0000 Received: from star1.jb.man.ac.uk ([130.88.24.176]) by probity.mcc.ac.uk with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MMSGl-0002N2-Sc; Thu, 02 Jul 2009 20:48:31 +0100 Received: from [130.88.24.18] (helo=[127.0.0.1]) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1MMSGl-0002OG-00; Thu, 02 Jul 2009 20:48:31 +0100 Message-Id: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> From: Paul Harrison To: Matthew Graham In-Reply-To: <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Versioning Date: Thu, 2 Jul 2009 20:48:01 +0100 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> X-Mailer: Apple Mail (2.935.3) X-UoM: Scanned by the University Mail System. See http://www.itservices.manchester.ac.uk/email/filtering/information/ for details. Cc: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net Hi All, During the discussion that took place on this before the latest Standards document the consensus was that for a document name of the form WD-VOSpace-2.0-yyyymmdd * That the 2.0 was the version number of the "protocol/standard" * yyyymmdd was effectively the version number of the document What was not explicitly thought about is the progression from a version 1.0 to a version 2.0 of a protocol, - in this case the document numbering can only start and stay with 2.0 from first WD to REC - even though there might be substantial (protocol/interface) changes between the drafts (which would make the programmer in us want to change the version number). Only after reaching the REC status does the "2.0" number have to change. What should be removed from the Standards document is the idea of a public WD that has a 0.x number, as this is logically inconsistent with the new scheme - the first public WD of a new protocol/standard should have a 1.0 number - the new numbering scheme was intended to remove this ambiguity, but I agree that the Standards document still does not make it clear. Under this numbering scheme, what is currently VOTable 1.2 should really be VOTable 2.0 in my opinion, as it causes VOTable 1.1 xml to be invalid, even though the changes in the written document look quite minimal. However, I am not sure who will police this sort of issue..... Cheers, Paul. On 2009-07 -02, at 19:07, Matthew Graham wrote: > Hi Doug, > > The standards documents says: > > "The number to the left of the (first) decimal point starts with 0 > for documents that are being discussed within a Working Group prior > to publication for IVOA-wide review. The number increments to 1 for > the first public version, and to 2, 3, ..., for subsequent versions > that are not backward compatible and/or require substantial > revisions to implementations." > > The definition of a Working Draft is: > > "A Working Draft is published at the discretion of a Working Group > once the WG is satisfied that the document is sufficiently developed > to merit broader exposure and feedback" > > So I think that a Working Draft fulfils the "IVOA-wide review" > criterion. > > If the integer progression is only a prerequisite for REC versions > then the standards document needs to be amended to say this. > > Cheers, > > Matthew > > > On Jul 2, 2009, at 10:52 AM, Doug Tody wrote: > >> If this were true I agree it would be crazy. But is a WD or PR a >> "standard"? I should think this would only apply to established >> standards that are already deployed. That is, to recommendations. >> Perhaps the documents and standards folks should clarify. >> >> Also, I don't think this is just limited to GWS; any DAL or DM >> standard >> for example might also have to deal with this issue. >> >> - Doug >> >> >> On Thu, 2 Jul 2009, Matthew Graham wrote: >> >>> Hi, >>> >>> You might be aware that the Document Standards v1.2 PR has just >>> completed its RFC (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DocStdRFC2 >>> ). I raised concerns about the proposed versioning scheme: >>> >>> "The document now states that there is an integer increment in the >>> version number in the case where subsequent versions are not >>> backward compatible. " >>> >>> and the response that has been posted is: >>> >>> "The Committee agrees that the version numbering scheme is >>> challenging when dealing with namespaces and WSDL, and leads to >>> the conclusion that when IVOA standards describe web services or >>> have associated XML schemas, with namespaces that when changed, >>> cause software to break, then these changes must both be >>> accompanied by an increment to the integer part of the document >>> and the associated "supplementary" files. This would not affect >>> most of the standards documents, and should not present any real >>> logistical difficulty, as there are a sufficient number of >>> integers available to support any number of revisions. " >>> >>> This has greatest impact for this working group (GWS but I am also >>> cross-posting to Semantics) and essentially means that ALL (WD, >>> PR, etc) versions of our specs with WSDL/XML/RDF documents >>> (anything with a namespace) will only carry integer versions. >>> >>> So, for example, the progression of VOSpace 2.0 would actually >>> proceed as: >>> >>> VOSpace 2 (first WD) >>> VOSpace 3 (second WD) >>> VOSpace 4 (third WD) >>> VOSpace 5 (first PR) >>> VOSpace 6 (second PR) >>> VOSpace 7 (final PR) >>> VOSpace 8 (REC) >>> >>> The next version would then VOSpace 9, etc. >>> >>> Although this is very much a procedural issue, I just wanted to >>> flag it so that everyone is aware and happy with it before I >>> approve. >>> >>> Cheers, >>> >>> Matthew >>> >> > From grid-bounces@ivoa.net Thu Jul 2 22:14:32 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 4B002624196; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEWJN025855; Thu, 2 Jul 2009 22:14:32 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 05727ECA39E; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 431A4ECA386; Thu, 2 Jul 2009 22:14:30 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEU5p025843; Thu, 2 Jul 2009 22:14:30 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by aeon.hq.eso.org (Postfix) with SMTP id A27035A632; Thu, 2 Jul 2009 22:14:29 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: seaman@noao.edu X-Msg-Ref: server-5.tower-186.messagelabs.com!1246565667!9840378!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [140.252.1.54] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 18694 invoked from network); 2 Jul 2009 20:14:28 -0000 Received: from noao.edu (HELO noao.edu) (140.252.1.54) by server-5.tower-186.messagelabs.com with SMTP; 2 Jul 2009 20:14:28 -0000 Received: from baleen.tuc.noao.edu ([140.252.4.27] verified) by noao.edu (CommuniGate Pro SMTP 5.2.14) with ESMTPS id 67375599; Thu, 02 Jul 2009 13:14:27 -0700 Message-Id: From: Rob Seaman To: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net In-Reply-To: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Versioning Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 13:14:26 -0700 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> X-Mailer: Apple Mail (2.935.3) X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net On Jul 2, 2009, at 12:48 PM, Paul Harrison wrote: > During the discussion that took place on this before the latest > Standards document the consensus was that for a document name of the > form > > WD-VOSpace-2.0-yyyymmdd > > * That the 2.0 was the version number of the "protocol/standard" > * yyyymmdd was effectively the version number of the document > > What was not explicitly thought about is the progression from a > version 1.0 to a version 2.0 of a protocol, - in this case the > document numbering can only start and stay with 2.0 from first WD to > REC - even though there might be substantial (protocol/interface) > changes between the drafts This distinction between version of the standard and version of the document maps well onto the process used with VOEvent. I have about 50 sequential (and some parallel) versions of the document that eventually turned into v1.0 of the standard. The first few versions were named in a rather ad hoc manner until it became clear that one has to say just these two things with the nomenclature from the very first draft: - What standard am I working on? - What version of the document is this? Otherwise you find yourself inadvertently incrementing the version of the standard, when what you are really doing is just revising a draft description of the same final product. It would be silly to require the version of the standard to be incremented with every notion thrashed out by a working group while reaching consensus. Which is to say that assigning a version number to a new standard is something that occurs at the beginning of the development/revision process, not just as a final swat on its tush. Incrementing by integers has the main advantage of making progress in the IVOA appear to be occurring ten times as rapidly. (It's also more- or-less the industry norm.) Rob From tcg-bounces@ivoa.net Thu Jul 2 22:14:33 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 9D5736242C6 for ; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEWdU025861 for ; Thu, 2 Jul 2009 22:14:32 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 40399ECA3B3; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) X-Original-To: tcg@pat.hq.eso.org Delivered-To: tcg@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 431A4ECA386; Thu, 2 Jul 2009 22:14:30 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEU5p025843; Thu, 2 Jul 2009 22:14:30 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by aeon.hq.eso.org (Postfix) with SMTP id A27035A632; Thu, 2 Jul 2009 22:14:29 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: seaman@noao.edu X-Msg-Ref: server-5.tower-186.messagelabs.com!1246565667!9840378!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [140.252.1.54] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 18694 invoked from network); 2 Jul 2009 20:14:28 -0000 Received: from noao.edu (HELO noao.edu) (140.252.1.54) by server-5.tower-186.messagelabs.com with SMTP; 2 Jul 2009 20:14:28 -0000 Received: from baleen.tuc.noao.edu ([140.252.4.27] verified) by noao.edu (CommuniGate Pro SMTP 5.2.14) with ESMTPS id 67375599; Thu, 02 Jul 2009 13:14:27 -0700 Message-Id: From: Rob Seaman To: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net In-Reply-To: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Versioning Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 13:14:26 -0700 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> X-Mailer: Apple Mail (2.935.3) X-BeenThere: tcg@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Technical Co-ordinating Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcg-bounces@ivoa.net On Jul 2, 2009, at 12:48 PM, Paul Harrison wrote: > During the discussion that took place on this before the latest > Standards document the consensus was that for a document name of the > form > > WD-VOSpace-2.0-yyyymmdd > > * That the 2.0 was the version number of the "protocol/standard" > * yyyymmdd was effectively the version number of the document > > What was not explicitly thought about is the progression from a > version 1.0 to a version 2.0 of a protocol, - in this case the > document numbering can only start and stay with 2.0 from first WD to > REC - even though there might be substantial (protocol/interface) > changes between the drafts This distinction between version of the standard and version of the document maps well onto the process used with VOEvent. I have about 50 sequential (and some parallel) versions of the document that eventually turned into v1.0 of the standard. The first few versions were named in a rather ad hoc manner until it became clear that one has to say just these two things with the nomenclature from the very first draft: - What standard am I working on? - What version of the document is this? Otherwise you find yourself inadvertently incrementing the version of the standard, when what you are really doing is just revising a draft description of the same final product. It would be silly to require the version of the standard to be incremented with every notion thrashed out by a working group while reaching consensus. Which is to say that assigning a version number to a new standard is something that occurs at the beginning of the development/revision process, not just as a final swat on its tush. Incrementing by integers has the main advantage of making progress in the IVOA appear to be occurring ten times as rapidly. (It's also more- or-less the industry norm.) Rob From stdproc-bounces@ivoa.net Thu Jul 2 22:14:34 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id C99E36242D7 for ; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEWQu025865 for ; Thu, 2 Jul 2009 22:14:32 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 60444ECA3B6; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 431A4ECA386; Thu, 2 Jul 2009 22:14:30 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEU5p025843; Thu, 2 Jul 2009 22:14:30 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by aeon.hq.eso.org (Postfix) with SMTP id A27035A632; Thu, 2 Jul 2009 22:14:29 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: seaman@noao.edu X-Msg-Ref: server-5.tower-186.messagelabs.com!1246565667!9840378!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [140.252.1.54] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 18694 invoked from network); 2 Jul 2009 20:14:28 -0000 Received: from noao.edu (HELO noao.edu) (140.252.1.54) by server-5.tower-186.messagelabs.com with SMTP; 2 Jul 2009 20:14:28 -0000 Received: from baleen.tuc.noao.edu ([140.252.4.27] verified) by noao.edu (CommuniGate Pro SMTP 5.2.14) with ESMTPS id 67375599; Thu, 02 Jul 2009 13:14:27 -0700 Message-Id: From: Rob Seaman To: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net In-Reply-To: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Versioning Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 13:14:26 -0700 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> X-Mailer: Apple Mail (2.935.3) X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On Jul 2, 2009, at 12:48 PM, Paul Harrison wrote: > During the discussion that took place on this before the latest > Standards document the consensus was that for a document name of the > form > > WD-VOSpace-2.0-yyyymmdd > > * That the 2.0 was the version number of the "protocol/standard" > * yyyymmdd was effectively the version number of the document > > What was not explicitly thought about is the progression from a > version 1.0 to a version 2.0 of a protocol, - in this case the > document numbering can only start and stay with 2.0 from first WD to > REC - even though there might be substantial (protocol/interface) > changes between the drafts This distinction between version of the standard and version of the document maps well onto the process used with VOEvent. I have about 50 sequential (and some parallel) versions of the document that eventually turned into v1.0 of the standard. The first few versions were named in a rather ad hoc manner until it became clear that one has to say just these two things with the nomenclature from the very first draft: - What standard am I working on? - What version of the document is this? Otherwise you find yourself inadvertently incrementing the version of the standard, when what you are really doing is just revising a draft description of the same final product. It would be silly to require the version of the standard to be incremented with every notion thrashed out by a working group while reaching consensus. Which is to say that assigning a version number to a new standard is something that occurs at the beginning of the development/revision process, not just as a final swat on its tush. Incrementing by integers has the main advantage of making progress in the IVOA appear to be occurring ten times as rapidly. (It's also more- or-less the industry norm.) Rob From grid-bounces@ivoa.net Thu Jul 2 22:14:32 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 46667624194 for ; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEWdp025856 for ; Thu, 2 Jul 2009 22:14:32 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 05727ECA39E; Thu, 2 Jul 2009 22:14:32 +0200 (CEST) X-Original-To: grid@pat.hq.eso.org Delivered-To: grid@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 431A4ECA386; Thu, 2 Jul 2009 22:14:30 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62KEU5p025843; Thu, 2 Jul 2009 22:14:30 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by aeon.hq.eso.org (Postfix) with SMTP id A27035A632; Thu, 2 Jul 2009 22:14:29 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: seaman@noao.edu X-Msg-Ref: server-5.tower-186.messagelabs.com!1246565667!9840378!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [140.252.1.54] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 18694 invoked from network); 2 Jul 2009 20:14:28 -0000 Received: from noao.edu (HELO noao.edu) (140.252.1.54) by server-5.tower-186.messagelabs.com with SMTP; 2 Jul 2009 20:14:28 -0000 Received: from baleen.tuc.noao.edu ([140.252.4.27] verified) by noao.edu (CommuniGate Pro SMTP 5.2.14) with ESMTPS id 67375599; Thu, 02 Jul 2009 13:14:27 -0700 Message-Id: From: Rob Seaman To: IVOA TCG , Grid_Ivoa_List , stdproc@ivoa.net In-Reply-To: <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: Re: Versioning Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 13:14:26 -0700 References: <4137BEF6-99BC-4E8D-9B26-B001C9A604E3@cacr.caltech.edu> <7DCCB579-8289-4AF2-8EDE-C0EAA5A080F7@cacr.caltech.edu> <7E91E847-3F8F-44F1-A59D-FB4588819819@manchester.ac.uk> X-Mailer: Apple Mail (2.935.3) X-BeenThere: grid@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Grid and Web Services Working Group - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: grid-bounces@ivoa.net On Jul 2, 2009, at 12:48 PM, Paul Harrison wrote: > During the discussion that took place on this before the latest > Standards document the consensus was that for a document name of the > form > > WD-VOSpace-2.0-yyyymmdd > > * That the 2.0 was the version number of the "protocol/standard" > * yyyymmdd was effectively the version number of the document > > What was not explicitly thought about is the progression from a > version 1.0 to a version 2.0 of a protocol, - in this case the > document numbering can only start and stay with 2.0 from first WD to > REC - even though there might be substantial (protocol/interface) > changes between the drafts This distinction between version of the standard and version of the document maps well onto the process used with VOEvent. I have about 50 sequential (and some parallel) versions of the document that eventually turned into v1.0 of the standard. The first few versions were named in a rather ad hoc manner until it became clear that one has to say just these two things with the nomenclature from the very first draft: - What standard am I working on? - What version of the document is this? Otherwise you find yourself inadvertently incrementing the version of the standard, when what you are really doing is just revising a draft description of the same final product. It would be silly to require the version of the standard to be incremented with every notion thrashed out by a working group while reaching consensus. Which is to say that assigning a version number to a new standard is something that occurs at the beginning of the development/revision process, not just as a final swat on its tush. Incrementing by integers has the main advantage of making progress in the IVOA appear to be occurring ten times as rapidly. (It's also more- or-less the industry norm.) Rob From stdproc-bounces@ivoa.net Fri Jul 3 01:27:11 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 043E3624196 for ; Fri, 3 Jul 2009 01:27:11 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62NRAjX016328 for ; Fri, 3 Jul 2009 01:27:10 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id AC138ECA39E; Fri, 3 Jul 2009 01:27:10 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id AF7F4EC819D for ; Fri, 3 Jul 2009 01:27:09 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n62NR9o0016324 for ; Fri, 3 Jul 2009 01:27:09 +0200 (MEST) Received: from mail169.messagelabs.com (mail169.messagelabs.com [85.158.138.179]) by aeon.hq.eso.org (Postfix) with ESMTP id CF7C75A632 for ; Fri, 3 Jul 2009 01:27:08 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-9.tower-169.messagelabs.com!1246577227!17193916!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 27564 invoked from network); 2 Jul 2009 23:27:08 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-9.tower-169.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 2 Jul 2009 23:27:08 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGD02494 (AUTH hanisch); Thu, 2 Jul 2009 19:27:05 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Jul 2009 19:27:04 -0400 Subject: versioning and WSDL and namespaces, etc. From: Robert Hanisch To: Message-ID: Thread-Topic: versioning and WSDL and namespaces, etc. Thread-Index: Acn7bJt12krb2mdfEd6B/AARJN7wDA== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Following a bit of side discussion with Matthew to make sure I understand the issue, I think we can resolve the problem if we consider "software breakage" in the sense of manual recoding. Changes to WSDL or XML namespaces typically require regeneration of bindings and recompilation of code, but this is all (supposed) to be more or less automatic. So, with some clarification to the text, the implication would be that the integer part of the version remains fixed -- it is notional and describes the intention -- and updates to WSDL, etc., coincide with increments to the part of the version number to the right of the decimal point. As for Paul's comment: What should be removed from the Standards document is the idea of a public WD that has a 0.x number, as this is logically inconsistent with the new scheme - the first public WD of a new protocol/standard should have a 1.0 number - the new numbering scheme was intended to remove this ambiguity, but I agree that the Standards document still does not make it clear. What the document says is =B7 The number to the left of the (first) decimal point starts with 0 for documents that are being discussed within a Working Group prior to publication for IVOA-wide review. The number increments to 1 for the first public version, and to 2, 3, ..., for subsequent versions that are not backward compatible and/or require substantial revisions to implementations= . Thus, I do not see why there is confusion on this point. Bob From stdproc-bounces@ivoa.net Fri Jul 3 11:53:48 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 8A28E624194 for ; Fri, 3 Jul 2009 11:53:47 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n639rliI008969 for ; Fri, 3 Jul 2009 11:53:47 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 5939BECA3A1; Fri, 3 Jul 2009 11:53:47 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id CFDB3ECA38F for ; Fri, 3 Jul 2009 11:53:45 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.75.150] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n639rj0D008959 for ; Fri, 3 Jul 2009 11:53:45 +0200 (MEST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by flux.hq.eso.org (Postfix) with SMTP id F12F2B65FF for ; Fri, 3 Jul 2009 11:48:53 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: m.b.taylor@bristol.ac.uk X-Msg-Ref: server-14.tower-178.messagelabs.com!1246614824!33350141!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [137.222.58.39] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 20813 invoked from network); 3 Jul 2009 09:53:44 -0000 Received: from sol.star.bris.ac.uk (HELO sol.star.bris.ac.uk) (137.222.58.39) by server-14.tower-178.messagelabs.com with SMTP; 3 Jul 2009 09:53:44 -0000 Received: from andromeda.star.bris.ac.uk ([137.222.58.155]) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1MMfSF-0000U9-00; Fri, 03 Jul 2009 10:53:15 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 4.43) id 1MMfSE-0005iW-Dz; Fri, 03 Jul 2009 10:53:14 +0100 Date: Fri, 3 Jul 2009 10:53:14 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: Robert Hanisch Subject: Re: IVOA Document Standards RFC V1.2 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Bob, On Thu, 2 Jul 2009, Robert Hanisch wrote: > First, let me quote myself in the e-mail message I sent earlier today: > > "One might argue that if one or more VO projects invests the efforts into > developing the standard itself, it follows that they would put effort into > implementations and validators. But this could put a lot of pressure on > schedule and resources of individual projects, and could lead to major > delays in the promotion process." > > I agree completely with you that doing implementations in parallel with > standards development is the best way to go, with the obvious exception that > some of the IVOA standards, as you point out, are not really about software > implementations. > > But making the implementations and the validator mandatory for promotion is > where I, and Christophe and Francoise, feel it is necessary to pause. For > example, if right now we were to enforce this requirement on TAP, with the > resource constraints we have in several of the major projects, we would be > forced to stop the promotion process. This would be an awful situation for > IVOA, I think. We want prototypes to inform the standards development > process, for sure, we SHOULD have them, but from a management perspective I > think we have to avoid boxing ourselves into a corner. I agree with you that requiring the associated software would slow down the promotion process. However, as I tried to make clear in my previous message, I don't believe that the date of publication of the Recommendation is what we should be focussing on. When a document reaches Recommendation status, yes it looks good on Gantt charts, but all it means is we have a bit of paper to wave in the air. Nothing useful has been achieved until effective use of that standard is made, which in most cases requires software to be written. I believe that attaining that second goal will actually be accelerated rather than decelerated if the software is written in tandem with the text (I tried to get you to agree or disagree with this statement in my last message, but I still don't know your opinion). Doing them in parallel will also lead to a better standard. In any case: if you can't find anyone who is prepared to implement the standard, there's probably a good reason; either it's too hard to do, or it's not something that people need. In either case it's no great achievement to have published it. > It is also a bit ambiguous just how one proves that implementations are > interoperable. So far we have taken people's word, but IVOA has no means to > independently test these assertions. Agreed it's ambiguous, and rigorous enforcement is not really feasible. I'm prepared to rely on the good will of the authors/implementors, supplemented by whatever scrutiny other IVOA members are prepared to provide on an ad-hoc basis. > I would probably agree fully with you if, say, IVOA were a dues-based > membership organization, with its own financial resources to build > validators, or test those developed by others. But I see a distinction, > albeit a subtle one, between the projects' willingness to contribute to > development of a standard and their ability to provide supporting software > and validators on a timescale that does not jeopardize the promotion > process. Again - I believe that the timescale of the promotion process itself is a red herring. That given, I don't see the subtle difference here (management is neither my enthusiasm nor my expertise, so I'm quite prepared to believe there are issues over my head here) - could you elaborate a bit? But I'll say this, I think it is somewhat dangerous for the system to encourage or allow organisations to shove their oar in when it comes to writing requirements, but not when it comes to resourcing their implementation. > Finally, in any case, we have a revision system that is there to deal with > problems and shortcomings found in earlier versions. If V1.0 of a standard > ends up having problems -- unsupportable features, inconsistencies, etc. > (and we have had this experience) -- then we fix the problems in V1.x or > V2.0. My understanding of the basic intention for the versioning system is that version X+delta is version X with the additions or changes gained from working with version X for a while, as well as enhancements which weren't feasible (e.g. from lack of resources) on the timescale of version X. While it can also be used for patching up things which were broken or ill-thought-out in the first place, it's not very well designed for that purpose, if only because of the very long timescales typically involved. > (and we have had this experience) -- then we fix the problems in V1.x or and we'd have had the experience a lot less if software was written in tandem with the original versions! Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From stdproc-bounces@ivoa.net Fri Jul 3 14:37:58 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 755CD624194 for ; Fri, 3 Jul 2009 14:37:58 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63Cbwxs025508 for ; Fri, 3 Jul 2009 14:37:58 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 52445ECA396; Fri, 3 Jul 2009 14:37:58 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 02485ECA35D for ; Fri, 3 Jul 2009 14:37:56 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.75.150] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63Cbuxg025499 for ; Fri, 3 Jul 2009 14:37:56 +0200 (MEST) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by flux.hq.eso.org (Postfix) with ESMTP id B1BCDB65F3 for ; Fri, 3 Jul 2009 14:33:04 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-4.tower-178.messagelabs.com!1246624674!6407526!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 7708 invoked from network); 3 Jul 2009 12:37:55 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-4.tower-178.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 3 Jul 2009 12:37:55 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGD85109 (AUTH hanisch); Fri, 3 Jul 2009 08:35:08 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 03 Jul 2009 08:35:07 -0400 Subject: Re: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Mark Taylor Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn72rJT8SAZumfNEd6B/AARJN7wDA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On 7/3/09 5:53 AM, "Mark Taylor" wrote: > Bob, > > On Thu, 2 Jul 2009, Robert Hanisch wrote: > >> First, let me quote myself in the e-mail message I sent earlier today: >> >> "One might argue that if one or more VO projects invests the efforts into >> developing the standard itself, it follows that they would put effort into >> implementations and validators. But this could put a lot of pressure on >> schedule and resources of individual projects, and could lead to major >> delays in the promotion process." >> >> I agree completely with you that doing implementations in parallel with >> standards development is the best way to go, with the obvious exception that >> some of the IVOA standards, as you point out, are not really about software >> implementations. >> >> But making the implementations and the validator mandatory for promotion is >> where I, and Christophe and Francoise, feel it is necessary to pause. For >> example, if right now we were to enforce this requirement on TAP, with the >> resource constraints we have in several of the major projects, we would be >> forced to stop the promotion process. This would be an awful situation for >> IVOA, I think. We want prototypes to inform the standards development >> process, for sure, we SHOULD have them, but from a management perspective I >> think we have to avoid boxing ourselves into a corner. > > I agree with you that requiring the associated software would slow down > the promotion process. However, as I tried to make clear in my previous > message, I don't believe that the date of publication of the > Recommendation is what we should be focussing on. > When a document reaches Recommendation status, yes it looks good on > Gantt charts, but all it means is we have a bit of paper to wave > in the air. Nothing useful has been achieved until effective use of > that standard is made, which in most cases requires software to be > written. I believe that attaining that second goal will actually > be accelerated rather than decelerated if the software is written > in tandem with the text (I tried to get you to agree or disagree with > this statement in my last message, but I still don't know your opinion). > Doing them in parallel will also lead to a better standard. > > In any case: if you can't find anyone who is prepared to implement > the standard, there's probably a good reason; either it's too hard > to do, or it's not something that people need. In either case > it's no great achievement to have published it. I disagree with you on this point, and perhaps that is the crux of the issue. Many organizations will not even look at an IVOA standard until it has been finalized. They say "why should I bother implementing something that is just going to change." Plus, like it or not, just reaching agreement on the standard IS a major milestone for our development projects. I don't know what is faster overall ... you are probably right, that when the standard is accompanied by two or more implementations, it is more likely to be correct and implementable by others outside of the core development team. But we also all work to external expectations (from our funding agencies), and I have heard many times now comments from people at data centers saying they are not going to code up an interface because it is still a WD. Please keep in mind that many of the implementors of IVOA standards are not part of the VO development teams. >> It is also a bit ambiguous just how one proves that implementations are >> interoperable. So far we have taken people's word, but IVOA has no means to >> independently test these assertions. > > Agreed it's ambiguous, and rigorous enforcement is not really feasible. > I'm prepared to rely on the good will of the authors/implementors, > supplemented by whatever scrutiny other IVOA members are prepared > to provide on an ad-hoc basis. We have no choice at the moment! >> I would probably agree fully with you if, say, IVOA were a dues-based >> membership organization, with its own financial resources to build >> validators, or test those developed by others. But I see a distinction, >> albeit a subtle one, between the projects' willingness to contribute to >> development of a standard and their ability to provide supporting software >> and validators on a timescale that does not jeopardize the promotion >> process. > > Again - I believe that the timescale of the promotion process itself > is a red herring. That given, I don't see the subtle difference here > (management is neither my enthusiasm nor my expertise, so I'm quite > prepared to believe there are issues over my head here) - could you > elaborate a bit? As above. Agreement on these standards is a major milestone. Read any of the NVO Quarterly Reports to NSF (all are on the NVO web page, in the document collection) and you can see how important these are in terms of deliverables. > But I'll say this, I think it is somewhat dangerous for the system > to encourage or allow organisations to shove their oar in when it > comes to writing requirements, but not when it comes to resourcing > their implementation. This is not unique to the IVOA process! Everyone is eager to tell you what needs to be done, as long as someone else actually does it! >> Finally, in any case, we have a revision system that is there to deal with >> problems and shortcomings found in earlier versions. If V1.0 of a standard >> ends up having problems -- unsupportable features, inconsistencies, etc. >> (and we have had this experience) -- then we fix the problems in V1.x or >> V2.0. > > My understanding of the basic intention for the versioning system > is that version X+delta is version X with the additions or changes > gained from working with version X for a while, as well as > enhancements which weren't feasible (e.g. from lack of resources) > on the timescale of version X. While it can also be used for > patching up things which were broken or ill-thought-out in the > first place, it's not very well designed for that purpose, if only > because of the very long timescales typically involved. Which will be longer if we make interoperable implementations and validators mandatory at every step of the process. >> (and we have had this experience) -- then we fix the problems in V1.x or > > and we'd have had the experience a lot less if software was written > in tandem with the original versions! > > Mark Bob From stdproc-bounces@ivoa.net Fri Jul 3 15:51:17 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 4E762624196 for ; Fri, 3 Jul 2009 15:51:17 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63DpHQg004016 for ; Fri, 3 Jul 2009 15:51:17 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 1C5CBECA385; Fri, 3 Jul 2009 15:51:17 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 21A58ECA35B for ; Fri, 3 Jul 2009 15:51:15 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63DpFgD004012 for ; Fri, 3 Jul 2009 15:51:15 +0200 (MEST) Received: from mail193.messagelabs.com (mail193.messagelabs.com [85.158.140.195]) by aeon.hq.eso.org (Postfix) with SMTP id D44C45A60F for ; Fri, 3 Jul 2009 15:51:13 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: m.b.taylor@bristol.ac.uk X-Msg-Ref: server-10.tower-193.messagelabs.com!1246629073!10429678!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [137.222.58.39] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 30941 invoked from network); 3 Jul 2009 13:51:13 -0000 Received: from sol.star.bris.ac.uk (HELO sol.star.bris.ac.uk) (137.222.58.39) by server-10.tower-193.messagelabs.com with SMTP; 3 Jul 2009 13:51:13 -0000 Received: from andromeda.star.bris.ac.uk ([137.222.58.155]) by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1) id 1MMjAV-0001Fn-00; Fri, 03 Jul 2009 14:51:11 +0100 Received: from mbt (helo=localhost) by andromeda.star.bris.ac.uk with local-esmtp (Exim 4.43) id 1MMjAU-00062d-Pm; Fri, 03 Jul 2009 14:51:10 +0100 Date: Fri, 3 Jul 2009 14:51:10 +0100 (BST) From: Mark Taylor X-X-Sender: mbt@andromeda.star.bris.ac.uk To: Robert Hanisch Subject: Re: IVOA Document Standards RFC V1.2 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On Fri, 3 Jul 2009, Robert Hanisch wrote: > >Bob wrote: > >> But making the implementations and the validator mandatory for promotion is > >> where I, and Christophe and Francoise, feel it is necessary to pause. For > >> example, if right now we were to enforce this requirement on TAP, with the > >> resource constraints we have in several of the major projects, we would be > >> forced to stop the promotion process. This would be an awful situation for > >> IVOA, I think. We want prototypes to inform the standards development > >> process, for sure, we SHOULD have them, but from a management perspective I > >> think we have to avoid boxing ourselves into a corner. > > > Mark wrote: > > I agree with you that requiring the associated software would slow down > > the promotion process. However, as I tried to make clear in my previous > > message, I don't believe that the date of publication of the > > Recommendation is what we should be focussing on. > > When a document reaches Recommendation status, yes it looks good on > > Gantt charts, but all it means is we have a bit of paper to wave > > in the air. Nothing useful has been achieved until effective use of > > that standard is made, which in most cases requires software to be > > written. I believe that attaining that second goal will actually > > be accelerated rather than decelerated if the software is written > > in tandem with the text (I tried to get you to agree or disagree with > > this statement in my last message, but I still don't know your opinion). > > Doing them in parallel will also lead to a better standard. > > > > In any case: if you can't find anyone who is prepared to implement > > the standard, there's probably a good reason; either it's too hard > > to do, or it's not something that people need. In either case > > it's no great achievement to have published it. > I disagree with you on this point, and perhaps that is the crux of the > issue. Many organizations will not even look at an IVOA standard until it > has been finalized. They say "why should I bother implementing something > that is just going to change." Plus, like it or not, just reaching > agreement on the standard IS a major milestone for our development projects. > I don't know what is faster overall ... you are probably right, that when > the standard is accompanied by two or more implementations, it is more > likely to be correct and implementable by others outside of the core > development team. But we also all work to external expectations (from our > funding agencies), and I have heard many times now comments from people at > data centers saying they are not going to code up an interface because it is > still a WD. Please keep in mind that many of the implementors of IVOA > standards are not part of the VO development teams. That's a fair point as stated. However, my impression (not backed up by evidence, and possibly incorrect - data welcomed) is that the first implementations for the standards that we're talking about are in fact by VO/IVOA insiders. Non-IVOA data centers in practice don't wait until the REC acceptance date and then start implementing; they wait until it looks like it's going to be a standard which is actually being used, or going to get used, by other people and then start implementing. This latter only happens after somebody else (most likely an IVOA insider) has provided an implementation of some kind. > >> I would probably agree fully with you if, say, IVOA were a dues-based > >> membership organization, with its own financial resources to build > >> validators, or test those developed by others. But I see a distinction, > >> albeit a subtle one, between the projects' willingness to contribute to > >> development of a standard and their ability to provide supporting software > >> and validators on a timescale that does not jeopardize the promotion > >> process. > > > > Again - I believe that the timescale of the promotion process itself > > is a red herring. That given, I don't see the subtle difference here > > (management is neither my enthusiasm nor my expertise, so I'm quite > > prepared to believe there are issues over my head here) - could you > > elaborate a bit? > As above. Agreement on these standards is a major milestone. Read any of > the NVO Quarterly Reports to NSF (all are on the NVO web page, in the > document collection) and you can see how important these are in terms of > deliverables. To some extent, this is what I was goading you to say. I do concede that there are political considerations here which will affect what decisions we take. When I said above that nothing useful is achieved by the standard publication per se, I should really have said nothing *technically* useful has been achieved - I admit that there may be some (maybe, a lot of) political advantage. If we're going to determine the standards process on that basis however, I'd like to have it out in the open amongst ourselves rather than to pretend that the StdDoc text is motivated purely by the considerations of technical excellence and technical pragmatism. If we admit that, maybe there's another way forward: declare an intermediate document stage of "accepted in principle, no major changes expected, but revisions possible on the basis of implementation experience". This stage could be sold as the one that counts to the funding agencies. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From stdproc-bounces@ivoa.net Sat Jul 4 00:44:06 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 02E5C62418C for ; Sat, 4 Jul 2009 00:44:06 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63Mi546029389 for ; Sat, 4 Jul 2009 00:44:05 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id CAAC0ECA3A3; Sat, 4 Jul 2009 00:44:05 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id C290EECA389 for ; Sat, 4 Jul 2009 00:44:04 +0200 (CEST) Received: from aeon.hq.eso.org (aeon.hq.eso.org [134.171.75.149]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n63Mi4mC029385 for ; Sat, 4 Jul 2009 00:44:04 +0200 (MEST) Received: from mail169.messagelabs.com (mail169.messagelabs.com [85.158.138.179]) by aeon.hq.eso.org (Postfix) with ESMTP id EA9E35A617 for ; Sat, 4 Jul 2009 00:44:02 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-15.tower-169.messagelabs.com!1246661042!19508581!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 20406 invoked from network); 3 Jul 2009 22:44:03 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-15.tower-169.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 3 Jul 2009 22:44:03 -0000 Received: from [192.168.1.2] (pool-71-126-165-62.washdc.fios.verizon.net [71.126.165.62]) by dancer.stsci.edu (MOS 3.10.5-GA) with ESMTP id IGE68682 (AUTH hanisch); Fri, 3 Jul 2009 18:43:50 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 03 Jul 2009 18:43:49 -0400 Subject: Re: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Mark Taylor Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Acn8L7si+Zw1JGgiEd6B/AARJN7wDA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net > That's a fair point as stated. However, my impression (not backed up > by evidence, and possibly incorrect - data welcomed) is that the first > implementations for the standards that we're talking about are in > fact by VO/IVOA insiders. Non-IVOA data centers in practice don't > wait until the REC acceptance date and then start implementing; > they wait until it looks like it's going to be a standard which > is actually being used, or going to get used, by other people > and then start implementing. This latter only happens after > somebody else (most likely an IVOA insider) has provided an > implementation of some kind. I don't have very complete information on this -- mostly anecdotal evidence. Most developers like to start with something already existing; others eschew what's been done and start from scratch. >>>> I would probably agree fully with you if, say, IVOA were a dues-based >>>> membership organization, with its own financial resources to build >>>> validators, or test those developed by others. But I see a distinction, >>>> albeit a subtle one, between the projects' willingness to contribute to >>>> development of a standard and their ability to provide supporting software >>>> and validators on a timescale that does not jeopardize the promotion >>>> process. >>> >>> Again - I believe that the timescale of the promotion process itself >>> is a red herring. That given, I don't see the subtle difference here >>> (management is neither my enthusiasm nor my expertise, so I'm quite >>> prepared to believe there are issues over my head here) - could you >>> elaborate a bit? >> As above. Agreement on these standards is a major milestone. Read any of >> the NVO Quarterly Reports to NSF (all are on the NVO web page, in the >> document collection) and you can see how important these are in terms of >> deliverables. > > To some extent, this is what I was goading you to say. I do concede > that there are political considerations here which will affect what > decisions we take. When I said above that nothing useful is achieved > by the standard publication per se, I should really have said nothing > *technically* useful has been achieved - I admit that there may be > some (maybe, a lot of) political advantage. If we're going to determine > the standards process on that basis however, I'd like to have > it out in the open amongst ourselves rather than to pretend that the > StdDoc text is motivated purely by the considerations of technical > excellence and technical pragmatism. If we admit that, maybe there's > another way forward: declare an intermediate document stage of > "accepted in principle, no major changes expected, but revisions > possible on the basis of implementation experience". This stage > could be sold as the one that counts to the funding agencies. It was understood from the beginning of IVOA that standards would evolve and that first versions would likely need to change. I found something I wrote back in March 2004, concerning the registry standards, that I think remains relevant today: We need to reach agreements quickly, build to them, and iterate to improve them. We need to be willing to build and revise, or even in some cases throw away and start again. We have set up a standards process that recognizes change, and is intended to be responsive to change. I do not believe we can afford to set 2-3 year schedules for reaching consensus. If it takes this long, the community upon which we will utimately depend for support will see us as purveyors of snake-oil, and will blow us off. - - - - - All this said, I think we will update the document to make the implementations and validator strongly/highly recommended, with some reason needing to be provided if these have not been done in order to move the standard ahead. I still think we do not want to go with mandatory, for the reasons explained in the past several messages. Off now for our independence holiday (which started today, actually). cheers, Bob From stdproc-bounces@ivoa.net Mon Sep 21 00:03:07 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id B86786242AA for ; Mon, 21 Sep 2009 00:03:06 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n8KM36ke015210 for ; Mon, 21 Sep 2009 00:03:06 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 80161ECA3B5; Mon, 21 Sep 2009 00:03:06 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 7C358ECA365 for ; Mon, 21 Sep 2009 00:03:04 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.75.150] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n8KM34Vc015204 for ; Mon, 21 Sep 2009 00:03:04 +0200 (MEST) Received: from mail204.messagelabs.com (mail204.messagelabs.com [194.106.221.19]) by flux.hq.eso.org (Postfix) with ESMTP id A408AB6622 for ; Sun, 20 Sep 2009 23:56:10 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: norman@astro.gla.ac.uk X-Msg-Ref: server-4.tower-204.messagelabs.com!1253484183!3946135!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [130.209.202.229] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 15152 invoked from network); 20 Sep 2009 22:03:03 -0000 Received: from desdemona.physics.gla.ac.uk (HELO desdemona.physics.gla.ac.uk) (130.209.202.229) by server-4.tower-204.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Sep 2009 22:03:03 -0000 Received: from fintan.physics.gla.ac.uk ([130.209.202.224]:47608) by desdemona.physics.gla.ac.uk:25 with esmtp (Exim 4.69) id 1MpUUk-0007YA-Rq; Sun, 20 Sep 2009 23:02:58 +0100 Received: from kronecker.demon.co.uk ([80.177.13.240]:50279 helo=[10.0.1.6]) by fintan.physics.gla.ac.uk:587 with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) id 1MpUUk-0004aQ-IL; Sun, 20 Sep 2009 23:02:58 +0100 Subject: Re: IVOA Document Standards RFC V1.2 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Norman Gray In-Reply-To: Date: Sun, 20 Sep 2009 23:02:57 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4DE7C180-EF16-4F05-B85C-04A0E3D79054@astro.gla.ac.uk> References: To: Robert Hanisch X-Mailer: Apple Mail (2.1076) X-PHYSCI2-Scanned: Virus scanned by submission X-PHYSCI2-scanned: Scanned by scanner1 X-PHYSCI2-outgoing: desdemona.physics.gla.ac.uk Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net Bob and all, hello. I put off taking part in this discussion back in July, but given the recent TCG discussion about the requiring or not of implementations, I'd like to add something tentatively here. There are two strands: what should funders want, and how should they be persuaded they're getting what they need. On 2009 Jul 3, at 23:43, Robert Hanisch wrote: >>>>> I would probably agree fully with you if, say, IVOA were a dues- >>>>> based >>>>> membership organization, with its own financial resources to build >>>>> validators, or test those developed by others. But I see a >>>>> distinction, >>>>> albeit a subtle one, between the projects' willingness to >>>>> contribute to >>>>> development of a standard and their ability to provide >>>>> supporting software >>>>> and validators on a timescale that does not jeopardize the >>>>> promotion >>>>> process. This is slightly parenthetical, but given that standardisations are all about the _reputation_ of the standards body, then I think it's at least _reasonable_ for a standards body to say 'if we're going to invest our reputation in a standard, then we can expect participants to invest resources in the standard they claim to support'. End parenthesis. Bob, responding to Mark, said: >>> As above. Agreement on these standards is a major milestone. >>> Read any of >>> the NVO Quarterly Reports to NSF (all are on the NVO web page, in >>> the >>> document collection) and you can see how important these are in >>> terms of >>> deliverables. I don't much like Bob's argument here, but I do respect it as an important one, and I want to criticise it on its own terms. The various funders want to support the development of standards which (a) are good for the discipline, and (b) are respected enough that they are taken up by the community. The funders want some evidence that this is happening, and ideally that it happened as a result of their support. 'Number of standards agreed' is a convenient metric for progress for obvious reasons -- it's quantitative and reasonably predictable. However I think it is not a good metric for measuring progress towards either of the goals the funder _actually_ has. The IVOA is one of a range of standards bodies in the world. I've had some exposure to the standards of ISO, W3C, IETF, ECMA and OCLC. Those bodies have different funding models, cultures, and timescales, and their standards have very different authorities, from the (generally) high-status, pragmatic and broadly implemented IETF ones, to the joke ECMA ones. A common criticism of ISO standards is that they're produced by highly political committees, and are barely implementable -- bad. The IVOA's funders (I hope) want IVOA standards to be at the upper end of that range of authority, but agreeing standards too early -- going off half-cocked, in the rush to report number of standards agreed -- could militate _against_ our standards having the authority we and they want. So what _can_ we show to the funders? Mark mentioned: >> maybe there's >> another way forward: declare an intermediate document stage of >> "accepted in principle, no major changes expected, but revisions >> possible on the basis of implementation experience". This stage >> could be sold as the one that counts to the funding agencies. This is very similar to the W3C's 'Candidate recommendation' stage (one of the few bits of W3C process that we didn't lift). This is the stage before 'proposed recommendation' [1], and is for standards where 'W3C believes the technical report is stable and appropriate for implementation. The technical report may still change based on implementation experience.' Thus it's a formal (reportable) milestone, with the implication that a lot of hard work has been done and the only changes between now and PR will be based on implementation experience. You don't really need implementations to get to CR, but you do need at least one implementation of every feature in order to proceed beyond PR. I'm not pushing this CR stage as a magical solution, but I believe that something like this is necessary for the IVOA, and desirable for the IVOA's funders, if someone can work out how to tell them so. * We don't want IVOA standards to get the 'ignore v1.0' reputation which we'll get if we rush standards to REC too quickly -- that just wastes time and makes us look cheap. * I think any standard is a poor standard if it proceeds to REC without implementations, validators, or some other public concrete evidence that it's _ready_. Having the WG Chair say 'I can feel it in my bones' does not count. [that is, I'm firmly in the must-implement rather than should-implement camp] * I think a standard is a poor standard, if it normatively depends on still-draft standards. [this shouldn't need saying] * If no-one can be bothered to implement a pre-REC standard, then that is evidence that that standard should not exist. [sure, there are plenty of people for whom this would be too early to implement, but if there aren't any early-adopters, what's the point?] > It was understood from the beginning of IVOA that standards would > evolve and > that first versions would likely need to change. I found something > I wrote > back in March 2004, concerning the registry standards, that I think > remains > relevant today: > > We need to reach agreements quickly, build to them, and iterate to > improve > them. We need to be willing to build and revise, or even in some > cases > throw away and start again. We have set up a standards process that > recognizes change, and is intended to be responsive to change. I do > not > believe we can afford to set 2-3 year schedules for reaching > consensus. If > it takes this long, the community upon which we will utimately > depend for > support will see us as purveyors of snake-oil, and will blow us off. I agree with the sentiment, and agree with the need for iterations and (particularly) discarding when necessary. Standards do need updating and improving. But that doesn't imply making v1.0 standards throwaway. The problem is that we _do_ appear to have 2-3 year schedules for reaching consensus. If that's too long (and I'd agree with 'snake oil' for ambitious proposals in permanent draft), then we need to shorten the process earlier, perhaps by insisting that v1 proposals are less ambitious, but not by skipping an important late stage. A 'standard' which turns out to be unimplementable is also snake oil, and I'd argue that it's _worse_ than one in permanent draft, because at least the permanent doesn't pretend to be a fully thought-through document. I appreciate that this may be a hard sell to funders (and I say this while up to the elbows in my half-written grant proposals). You know what you (plural) signed up for! All the best (and good luck), Norman [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi -- Norman Gray : http://nxg.me.uk Dept Physics and Astronomy, University of Leicester, UK From stdproc-bounces@ivoa.net Tue Sep 22 16:36:47 2009 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: X-Original-To: vomail@fiction.hq.eso.org Delivered-To: vomail@fiction.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by fiction.hq.eso.org (ESO maildrop) with ESMTP id 4CB406242D5 for ; Tue, 22 Sep 2009 16:36:47 +0200 (CEST) Received: from pat.hq.eso.org (pat.hq.eso.org [134.171.42.15]) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n8MEalmh013619 for ; Tue, 22 Sep 2009 16:36:47 +0200 (MEST) Received: from pat.hq.eso.org (localhost [127.0.0.1]) by pat.hq.eso.org (Postfix) with ESMTP id 1E261ECA3CD; Tue, 22 Sep 2009 16:36:47 +0200 (CEST) X-Original-To: stdproc@pat.hq.eso.org Delivered-To: stdproc@pat.hq.eso.org Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20]) by pat.hq.eso.org (Postfix) with ESMTP id 1B49CECA3BC for ; Tue, 22 Sep 2009 16:36:46 +0200 (CEST) Received: from flux.hq.eso.org (flux.hq.eso.org [134.171.75.150] (may be forged)) by mercury.hq.eso.org (8.13.6+Sun/8.12.10) with ESMTP id n8MEajeE013615 for ; Tue, 22 Sep 2009 16:36:46 +0200 (MEST) Received: from mail186.messagelabs.com (mail186.messagelabs.com [85.158.138.131]) by flux.hq.eso.org (Postfix) with ESMTP id 7254AB6622 for ; Tue, 22 Sep 2009 16:29:49 +0200 (CEST) X-VirusChecked: Checked X-Env-Sender: hanisch@stsci.edu X-Msg-Ref: server-15.tower-186.messagelabs.com!1253630203!6586556!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [130.167.251.70] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 3106 invoked from network); 22 Sep 2009 14:36:44 -0000 Received: from dancer.stsci.edu (HELO dancer.stsci.edu) (130.167.251.70) by server-15.tower-186.messagelabs.com with DES-CBC3-SHA encrypted SMTP; 22 Sep 2009 14:36:44 -0000 Received: from [130.167.31.62] (opus9.stsci.edu [130.167.31.62]) by dancer.stsci.edu (MOS 3.10.6-GA) with ESMTP id IKB57258; Tue, 22 Sep 2009 10:35:32 -0400 (EDT) User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 22 Sep 2009 10:35:31 -0400 Subject: Re: IVOA Document Standards RFC V1.2 From: Robert Hanisch To: Norman Gray Message-ID: Thread-Topic: IVOA Document Standards RFC V1.2 Thread-Index: Aco7ke+fLh5BTKeFEd66AQAlS892Ig== In-Reply-To: <4DE7C180-EF16-4F05-B85C-04A0E3D79054@astro.gla.ac.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at dancer.stsci.edu) Cc: stdproc@ivoa.net X-BeenThere: stdproc@ivoa.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Standardization Process Standing Committee - IVOA List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: stdproc-bounces@ivoa.net On 9/20/09 6:02 PM, "Norman Gray" wrote: > > Bob and all, hello. > > I put off taking part in this discussion back in July, but given the > recent TCG discussion about the requiring or not of implementations, > I'd like to add something tentatively here. There are two strands: > what should funders want, and how should they be persuaded they're > getting what they need. > > On 2009 Jul 3, at 23:43, Robert Hanisch wrote: > >>>>>> I would probably agree fully with you if, say, IVOA were a dues- >>>>>> based >>>>>> membership organization, with its own financial resources to build >>>>>> validators, or test those developed by others. But I see a >>>>>> distinction, >>>>>> albeit a subtle one, between the projects' willingness to >>>>>> contribute to >>>>>> development of a standard and their ability to provide >>>>>> supporting software >>>>>> and validators on a timescale that does not jeopardize the >>>>>> promotion >>>>>> process. > > This is slightly parenthetical, but given that standardisations are > all about the _reputation_ of the standards body, then I think it's at > least _reasonable_ for a standards body to say 'if we're going to > invest our reputation in a standard, then we can expect participants > to invest resources in the standard they claim to support'. End > parenthesis. I agree in principle. I also see practical problems, such as the funding shortfalls we are facing in the UK and US (the latter being temporary, we believe, and the former requiring a new approach). > Bob, responding to Mark, said: > >>>> As above. Agreement on these standards is a major milestone. >>>> Read any of >>>> the NVO Quarterly Reports to NSF (all are on the NVO web page, in >>>> the >>>> document collection) and you can see how important these are in >>>> terms of >>>> deliverables. > > I don't much like Bob's argument here, but I do respect it as an > important one, and I want to criticise it on its own terms. > > The various funders want to support the development of standards which > (a) are good for the discipline, and (b) are respected enough that > they are taken up by the community. The funders want some evidence > that this is happening, and ideally that it happened as a result of > their support. 'Number of standards agreed' is a convenient metric > for progress for obvious reasons -- it's quantitative and reasonably > predictable. However I think it is not a good metric for measuring > progress towards either of the goals the funder _actually_ has. I did not mean to suggest that just the number of standards agreed upon is itself much of a metric. It reminds me of "Standards are great, let's have lots of them!" But, progress towards those standards that are agreed to be necessary -- that is a reasonable metric. > The IVOA is one of a range of standards bodies in the world. I've had > some exposure to the standards of ISO, W3C, IETF, ECMA and OCLC. > Those bodies have different funding models, cultures, and timescales, > and their standards have very different authorities, from the > (generally) high-status, pragmatic and broadly implemented IETF ones, > to the joke ECMA ones. A common criticism of ISO standards is that > they're produced by highly political committees, and are barely > implementable -- bad. > > The IVOA's funders (I hope) want IVOA standards to be at the upper end > of that range of authority, but agreeing standards too early -- going > off half-cocked, in the rush to report number of standards agreed -- > could militate _against_ our standards having the authority we and > they want. > > So what _can_ we show to the funders? Actually, at this point I don't think our funders are particularly interested in the standards per se. More on that later. > Mark mentioned: > >>> maybe there's >>> another way forward: declare an intermediate document stage of >>> "accepted in principle, no major changes expected, but revisions >>> possible on the basis of implementation experience". This stage >>> could be sold as the one that counts to the funding agencies. > > This is very similar to the W3C's 'Candidate recommendation' stage > (one of the few bits of W3C process that we didn't lift). This is the > stage before 'proposed recommendation' [1], and is for standards where > 'W3C believes the technical report is stable and appropriate for > implementation. The technical report may still change based on > implementation experience.' Thus it's a formal (reportable) > milestone, with the implication that a lot of hard work has been done > and the only changes between now and PR will be based on > implementation experience. You don't really need implementations to > get to CR, but you do need at least one implementation of every > feature in order to proceed beyond PR. I worry about inserting another step in the process when already we have considerable difficulty getting IVOA participants to follow the process we have. > I'm not pushing this CR stage as a magical solution, but I believe > that something like this is necessary for the IVOA, and desirable for > the IVOA's funders, if someone can work out how to tell them so. > > * We don't want IVOA standards to get the 'ignore v1.0' reputation > which we'll get if we rush standards to REC too quickly -- that just > wastes time and makes us look cheap. > > * I think any standard is a poor standard if it proceeds to REC > without implementations, validators, or some other public concrete > evidence that it's _ready_. Having the WG Chair say 'I can feel it in > my bones' does not count. [that is, I'm firmly in the must-implement > rather than should-implement camp] I agree -- always have -- that RECs are better with the prior implementation experience. The "should" is a very strong one, in that we need to be convinced that it is worth promoting a document to REC without implementations. > * I think a standard is a poor standard, if it normatively depends > on still-draft standards. [this shouldn't need saying] > > * If no-one can be bothered to implement a pre-REC standard, then > that is evidence that that standard should not exist. [sure, there are > plenty of people for whom this would be too early to implement, but if > there aren't any early-adopters, what's the point?] > >> It was understood from the beginning of IVOA that standards would >> evolve and >> that first versions would likely need to change. I found something >> I wrote >> back in March 2004, concerning the registry standards, that I think >> remains >> relevant today: >> >> We need to reach agreements quickly, build to them, and iterate to >> improve >> them. We need to be willing to build and revise, or even in some >> cases >> throw away and start again. We have set up a standards process that >> recognizes change, and is intended to be responsive to change. I do >> not >> believe we can afford to set 2-3 year schedules for reaching >> consensus. If >> it takes this long, the community upon which we will utimately >> depend for >> support will see us as purveyors of snake-oil, and will blow us off. > > I agree with the sentiment, and agree with the need for iterations and > (particularly) discarding when necessary. Standards do need updating > and improving. But that doesn't imply making v1.0 standards throwaway. I don't know where this idea is coming from, Norman. > The problem is that we _do_ appear to have 2-3 year schedules for > reaching consensus. If that's too long (and I'd agree with 'snake > oil' for ambitious proposals in permanent draft), then we need to > shorten the process earlier, perhaps by insisting that v1 proposals > are less ambitious, but not by skipping an important late stage. > > A 'standard' which turns out to be unimplementable is also snake oil, > and I'd argue that it's _worse_ than one in permanent draft, because > at least the permanent doesn't pretend to be a fully thought-through > document. > > I appreciate that this may be a hard sell to funders (and I say this > while up to the elbows in my half-written grant proposals). You know > what you (plural) signed up for! A bit more on what funders expect... with a US perspective. At this point I don't think NSF or NASA care the least about how many standards we agree upon in the IVOA. In fact, they would rather see development efforts going into things that are more visible to astronomers and that directly have an impact on research. Do we have enough standards to support VO research tools? For the most part, I'd say yes. Further iterations will enhance capabilities and exploit new technologies. So the standards effort should not go dormant, but the balance between standards development and tools, interfaces, documentation, robustness, etc., needs to change in favor of the latter. cheers, Bob > All the best (and good luck), > > Norman > > > [1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi