From - Tue Feb 18 09:50:44 2003 X-UIDL: 3df25b31000008b3 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1I8oaFB006895 for ; Tue, 18 Feb 2003 09:50:36 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1I8oaT17738 for ; Tue, 18 Feb 2003 09:50:36 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAuiaiPI; Tue, 18 Feb 03 09:50:35 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18l3Os-0000Qb-00 for voql@ivoa.net; Tue, 18 Feb 2003 08:46:50 +0000 Received: (qmail 25564 invoked from network); 18 Feb 2003 08:47:12 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 18 Feb 2003 08:47:12 -0000 Reply-To: From: "Tony Linde" To: "voql" Subject: Query message format Date: Tue, 18 Feb 2003 08:46:51 -0000 Organization: University of Leicester Message-ID: <001001c2d72a$47d6e860$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: -----Original Message----- From: Tony Linde [mailto:ael@star.le.ac.uk] Sent: 16 February 2003 12:16 To: 'Registry_Ivoa_List' Subject: Query message format I've just proposed to the AstroGrid group that we base the format of messages containing queries (eg from client, portal or workflow component to registry or dataset) on the W3C XQuery standard: http://forum.astrogrid.org/read.php?TID=314&page=#971 I know there's no way that IVOA could determine a standard in time for AstroGrid (we need it now) but I wanted to find out if anyone knew of any 'just cause or impediment' why we should not use XQuery. Note that I'm not proposing XQuery as the Astronomical Query Language (ie something that an astronomer would type into a query processor) but as the format in which such a query would be passed from one component to another. Have a read of my proposal and let us know if there are any strong objections. We'll add any comments here to those of the AstroGrid group in the forum when our Technical Support Panel discusses the issue on 27th Feb. Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 AstroGrid Project Manager Fax: +44 (0)116 252 3311 Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 University of Leicester Email: ael@star.le.ac.uk Leicester, UK LE1 7RH Web: http://www.astrogrid.org From - Tue Feb 18 09:50:44 2003 X-UIDL: 3df25b31000008b4 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1I8p0FB007045 for ; Tue, 18 Feb 2003 09:51:00 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1I8oxM17784 for ; Tue, 18 Feb 2003 09:50:59 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAADXayUI; Tue, 18 Feb 03 09:50:58 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18l3PF-0000Qt-00 for voql@ivoa.net; Tue, 18 Feb 2003 08:47:13 +0000 Received: (qmail 25581 invoked from network); 18 Feb 2003 08:47:35 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 18 Feb 2003 08:47:35 -0000 Reply-To: From: "Tony Linde" To: "voql" Subject: FW: Query message format Date: Tue, 18 Feb 2003 08:47:14 -0000 Organization: University of Leicester Message-ID: <001101c2d72a$55a3c670$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: -----Original Message----- From: Wil O'Mullane [mailto:womullan@skysrv.pha.jhu.edu] Sent: 16 February 2003 23:52 To: Tony Linde Subject: Re: Query message format XPATH is great the implementations however tend to be slow - so while it is good to use at as a format beware of thinking of it as a querying solution. > I've just proposed to the AstroGrid group that we base the format of > messages containing queries (eg from client, portal or workflow > component to registry or dataset) on the W3C XQuery standard: > > http://forum.astrogrid.org/read.php?TID=314&page=#971 > > I know there's no way that IVOA could determine a standard in time for > AstroGrid (we need it now) but I wanted to find out if anyone knew of > any 'just cause or impediment' why we should not use XQuery. > > Note that I'm not proposing XQuery as the Astronomical Query Language > (ie something that an astronomer would type into a query processor) > but as the format in which such a query would be passed from one > component to another. > > Have a read of my proposal and let us know if there are any strong > objections. We'll add any comments here to those of the AstroGrid > group in the forum when our Technical Support Panel discusses the > issue on 27th Feb. > > Cheers, > Tony. > > __ > Tony Linde Phone: +44 (0)116 223 1292 > AstroGrid Project Manager Fax: +44 (0)116 252 3311 > Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 > University of Leicester Email: ael@star.le.ac.uk > Leicester, UK LE1 7RH Web: http://www.astrogrid.org From - Tue Feb 18 09:50:44 2003 X-UIDL: 3df25b31000008b5 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1I8pAFB007070 for ; Tue, 18 Feb 2003 09:51:10 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1I8p9k17810 for ; Tue, 18 Feb 2003 09:51:09 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_laWXI; Tue, 18 Feb 03 09:51:08 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18l3PP-0000Qy-00 for voql@ivoa.net; Tue, 18 Feb 2003 08:47:23 +0000 Received: (qmail 25586 invoked from network); 18 Feb 2003 08:47:45 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 18 Feb 2003 08:47:45 -0000 Reply-To: From: "Tony Linde" To: "'voql'" Subject: FW: Query message format Date: Tue, 18 Feb 2003 08:47:24 -0000 Organization: University of Leicester Message-ID: <001201c2d72a$5b81d9b0$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: -----Original Message----- From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] Sent: 17 February 2003 22:40 To: Tony Linde Cc: 'Registry_Ivoa_List' Subject: Re: Query message format Hi Tony, > I've just proposed to the AstroGrid group that we base the format of > messages containing queries (eg from client, portal or workflow > component to registry or dataset) on the W3C XQuery standard: > > Note that I'm not proposing XQuery as the Astronomical Query Language > (ie something that an astronomer would type into a query processor) > but as the format in which such a query would be passed from one > component to another. In my opinion, the most important requirement of the query interchange format is that it be easily converted into other forms. When distributing queries to many queryable services, you want the service implementer to be able to leverage off of existing capabilities as much as possible. This will mean converting the query into the form currently supported by the repository. This could include * an SQL query to a relational database * an XML Query to an XML database * an ASU query to an ASU interface * an SIA query to an SIA interface * a JVO query to the JVO grid. The conversion is not just a matter of transforming the syntax, of course. To leverage these existing systems, it will also involve transforming the metadata schema used in the query from some standard schema (e.g. like SIA's use of POS=...) into the schema supported by the local database. In my mind, if you want a message to be easily converted into another form, it should be in XML. This allows one to develop XSL stylesheets to do the transformation. (In fact, the XSL stylesheets could be created automatically from an XML-based configuration file.) The fact that an XML Query itself is not XML makes it difficult to transform into other forms. Brian Thomas and Ed Shaya have been working on a white paper (http://nvo.gsfc.nasa.gov/QueryMediator/) exploring a query framework based on an XML-encoded query syntax which I think could meet the requirement of easy conversion. We hope to experiment with this in the coming months. The use of an XML-encoded query as a query interchange format does not preclude AstroGrid's use of XML Query as its interchange format, particularly in the near-term. The idea is that it would be straightforward, in theory, to transform the XML-encoded query into XML Query and thereby accept queries from "outside" AstroGrid. cheers, Ray From - Tue Feb 18 09:55:44 2003 X-UIDL: 3df25b31000008b6 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1I8qqFB007400 for ; Tue, 18 Feb 2003 09:52:52 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1I8qqg17905 for ; Tue, 18 Feb 2003 09:52:52 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA1xaa_I; Tue, 18 Feb 03 09:52:51 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18l3R4-0000TQ-00 for registry@ivoa.net; Tue, 18 Feb 2003 08:49:06 +0000 Received: (qmail 25649 invoked from network); 18 Feb 2003 08:49:28 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 18 Feb 2003 08:49:28 -0000 Reply-To: From: "Tony Linde" To: "'Registry_Ivoa_List'" Subject: RE: Query message format Date: Tue, 18 Feb 2003 08:49:07 -0000 Organization: University of Leicester Message-ID: <001301c2d72a$98fb75d0$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Ray, I've relocated this thread to the VOQL list (voql@ivoa.net) - let's continue the discussion there. My apologies to all for the (slightly) inappropriate posting. Cheers, Tony. > -----Original Message----- > From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] > Sent: 17 February 2003 22:40 > To: Tony Linde > Cc: 'Registry_Ivoa_List' > Subject: Re: Query message format > > > Hi Tony, > > > I've just proposed to the AstroGrid group that we base the > format of > > messages containing queries (eg from client, portal or workflow > > component to registry or dataset) on the W3C XQuery standard: > > > > Note that I'm not proposing XQuery as the Astronomical > Query Language > > (ie something that an astronomer would type into a query processor) > > but as the format in which such a query would be passed from one > > component to another. > > In my opinion, the most important requirement of the query > interchange > format is that it be easily converted into other forms. When > distributing > queries to many queryable services, you want the service > implementer to be > able to leverage off of existing capabilities as much as > possible. This > will mean converting the query into the form currently > supported by the > repository. This could include > * an SQL query to a relational database > * an XML Query to an XML database > * an ASU query to an ASU interface > * an SIA query to an SIA interface > * a JVO query to the JVO grid. > > The conversion is not just a matter of transforming the > syntax, of course. > To leverage these existing systems, it will also involve transforming > the metadata schema used in the query from some standard > schema (e.g. like > SIA's use of POS=...) into the schema supported by the local > database. > > In my mind, if you want a message to be easily converted into another > form, it should be in XML. This allows one to develop XSL > stylesheets > to do the transformation. (In fact, the XSL stylesheets > could be created > automatically from an XML-based configuration file.) The > fact that an XML > Query itself is not XML makes it difficult to transform into > other forms. > > Brian Thomas and Ed Shaya have been working on a white paper > (http://nvo.gsfc.nasa.gov/QueryMediator/) exploring a query framework > based on an XML-encoded query syntax which I think could meet the > requirement of easy conversion. We hope to experiment with > this in the > coming months. > > The use of an XML-encoded query as a query interchange format > does not > preclude AstroGrid's use of XML Query as its interchange format, > particularly in the near-term. The idea is that it would be > straightforward, in theory, to transform the XML-encoded query > into XML Query and thereby accept queries from "outside" AstroGrid. > > cheers, > Ray > > > From - Tue Feb 18 10:35:44 2003 X-UIDL: 3df25b31000008b8 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1I9WBFB015247 for ; Tue, 18 Feb 2003 10:32:11 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1I9WBr19783 for ; Tue, 18 Feb 2003 10:32:11 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA6naWOM; Tue, 18 Feb 03 10:32:10 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18l46j-0001Wm-00 for voql@ivoa.net; Tue, 18 Feb 2003 09:32:09 +0000 Received: (qmail 28365 invoked from network); 18 Feb 2003 09:32:31 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 18 Feb 2003 09:32:31 -0000 Reply-To: From: "Tony Linde" To: "'voql'" Subject: RE: Query message format Date: Tue, 18 Feb 2003 09:32:10 -0000 Organization: University of Leicester Message-ID: <001801c2d730$9c975280$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001201c2d72a$5b81d9b0$b524d28f@bunyip> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ray, > In my opinion, the most important requirement of the query > interchange > format is that it be easily converted into other forms. Or, to restate, that it can be parsed and applied to different data stores? But it'd probably be more time consuming to write parsers for XQuery than translators of some XML format. Perhaps we need a 2-tier VOQL: if the metadata for the all datasets being queried says that they can all accept XQuery format queries, then the user formulating the query has a rich interface but if any does not have that, then the query format and interface is reduced to cope. > * an ASU query to an ASU interface > * an SIA query to an SIA interface > * a JVO query to the JVO grid. I don't know these. Isn't ASU an intermediate query interface which VOQL would supplant? And SIA is still a proposal and will presumably be amended to fit the standards? What is JVO? > The idea is that it would be > straightforward, in theory, to transform the XML-encoded query > into XML Query and thereby accept queries from "outside" AstroGrid. I don't think there'll be an 'AstroGrid' to be outside of. More a matter of those data centres which choose to use some of the AstroGrid components (possibly mixed with those from NVO, home grown ones etc.). That's why the interchange formats are important. One component of any VO will be a query construction interface (part of whichever portal or client the user chooses). This interface will know which data sources are being addressed by the query and will have to decode from what the user has entered into the interface into forms acceptable by the data sources themselves. Data sources which have xml or XQuery-able rdbms can take XQuery formats while others have to take a reduced xml format. How's this sound? Cheers, Tony. > -----Original Message----- > From: Tony Linde [mailto:ael@star.le.ac.uk] > Sent: 18 February 2003 08:47 > To: 'voql' > Subject: FW: Query message format > > > > > -----Original Message----- > From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] > Sent: 17 February 2003 22:40 > To: Tony Linde > Cc: 'Registry_Ivoa_List' > Subject: Re: Query message format > > > Hi Tony, > > > I've just proposed to the AstroGrid group that we base the format of > > messages containing queries (eg from client, portal or workflow > > component to registry or dataset) on the W3C XQuery standard: > > > > Note that I'm not proposing XQuery as the Astronomical > Query Language > > (ie something that an astronomer would type into a query processor) > > but as the format in which such a query would be passed from one > > component to another. > > In my opinion, the most important requirement of the query > interchange > format is that it be easily converted into other forms. When > distributing > queries to many queryable services, you want the service > implementer to be > able to leverage off of existing capabilities as much as > possible. This > > will mean converting the query into the form currently > supported by the > repository. This could include > * an SQL query to a relational database > * an XML Query to an XML database > * an ASU query to an ASU interface > * an SIA query to an SIA interface > * a JVO query to the JVO grid. > > The conversion is not just a matter of transforming the > syntax, of course. > To leverage these existing systems, it will also involve transforming > the metadata schema used in the query from some standard > schema (e.g. like > SIA's use of POS=...) into the schema supported by the local > database. > > In my mind, if you want a message to be easily converted into another > form, it should be in XML. This allows one to develop XSL > stylesheets > to do the transformation. (In fact, the XSL stylesheets > could be created > automatically from an XML-based configuration file.) The > fact that an XML > Query itself is not XML makes it difficult to transform into > other forms. > > Brian Thomas and Ed Shaya have been working on a white paper > (http://nvo.gsfc.nasa.gov/QueryMediator/) exploring a query framework > based on an XML-encoded query syntax which I think could meet the > requirement of easy conversion. We hope to experiment with > this in the > coming months. > > The use of an XML-encoded query as a query interchange format > does not > preclude AstroGrid's use of XML Query as its interchange format, > particularly in the near-term. The idea is that it would be > straightforward, in theory, to transform the XML-encoded query > into XML Query and thereby accept queries from "outside" AstroGrid. > > cheers, > Ray > > > From - Tue Feb 18 13:19:14 2003 X-UIDL: 3df25b31000008c3 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: 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 h1ICJhOL013823; Tue, 18 Feb 2003 13:19:43 +0100 (MET) Received: from there (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with SMTP id h1ICLXd28685; Tue, 18 Feb 2003 13:21:33 +0100 (MET) Message-Id: <200302181221.h1ICLXd28685@serapis.hq.eso.org> Content-Type: text/plain; charset="iso-8859-1" From: Andreas Wicenec Reply-To: awicenec@eso.org Organization: European Southern Observatory To: , "voql" Subject: Re: Query message format Date: Tue, 18 Feb 2003 13:19:42 +0100 X-Mailer: KMail [version 1.3.2] References: <001001c2d72a$47d6e860$b524d28f@bunyip> In-Reply-To: <001001c2d72a$47d6e860$b524d28f@bunyip> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Toni, thanks for this step. You can be certain to have my support on using XQuery together with XSL if necessary for interchange of query documents. I'm not so sure whether it will be sufficient for our needs, but doing something completely outside XML would be a bad start (to say the least). Andreas On Tuesday 18 February 2003 09:46, Tony Linde wrote: > -----Original Message----- > From: Tony Linde [mailto:ael@star.le.ac.uk] > Sent: 16 February 2003 12:16 > To: 'Registry_Ivoa_List' > Subject: Query message format > > > I've just proposed to the AstroGrid group that we base the format of > messages containing queries (eg from client, portal or workflow > component to registry or dataset) on the W3C XQuery standard: > > http://forum.astrogrid.org/read.php?TID=314&page=#971 > > I know there's no way that IVOA could determine a standard in time for > AstroGrid (we need it now) but I wanted to find out if anyone knew of > any 'just cause or impediment' why we should not use XQuery. > > Note that I'm not proposing XQuery as the Astronomical Query Language > (ie something that an astronomer would type into a query processor) but > as the format in which such a query would be passed from one component > to another. > > Have a read of my proposal and let us know if there are any strong > objections. We'll add any comments here to those of the AstroGrid group > in the forum when our Technical Support Panel discusses the issue on > 27th Feb. > > Cheers, > Tony. > > __ > Tony Linde Phone: +44 (0)116 223 1292 > AstroGrid Project Manager Fax: +44 (0)116 252 3311 > Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 > University of Leicester Email: ael@star.le.ac.uk > Leicester, UK LE1 7RH Web: http://www.astrogrid.org From - Tue Feb 18 17:48:52 2003 X-UIDL: 3df25b31000008e2 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1IGnEOL010490 for ; Tue, 18 Feb 2003 17:49:14 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1IGnEP10273 for ; Tue, 18 Feb 2003 17:49:14 +0100 (MET) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAABoaaeu; Tue, 18 Feb 03 17:49:13 +0100 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h1IGmCR06517 for ; Tue, 18 Feb 2003 10:48:12 -0600 Date: Tue, 18 Feb 2003 10:48:12 -0600 (CST) From: Ray Plante Reply-To: Ray Plante To: voql@ivoa.net Subject: Re: Query message format Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Tony, > > In my opinion, the most important requirement of the query > > interchange > > format is that it be easily converted into other forms. > > Or, to restate, that it can be parsed and applied to different data > stores? But it'd probably be more time consuming to write parsers for > XQuery than translators of some XML format. Yes, that is essentially correct. > Perhaps we need a 2-tier VOQL: if the metadata for the all datasets > being queried says that they can all accept XQuery format queries, then > the user formulating the query has a rich interface but if any does not > have that, then the query format and interface is reduced to cope. I would suggest that an XML-encoded query format need not be less rich than XQuery. It could be defined to allow lossless transformation back and forth. (The tricky part is bridging the relational--OO divide. That is, a query may be destined for both an SQL RDBMS and an XML-based database.) My questions about XQuery would be: who typically will accept XQuery queries? Those that can already accept them natively, or will people have build parser/translaters a la SIA? Is the XQuery parsing problem escapable? That doesn't mean we shouldn't allow the definition of services that accept XQuery. As a general interchange format, we should consider where the query will typically end up. If they will be compared agains XML data structures, then it makes sense. However, I don't see XML structures or databases overtaking RDBMSes anytime soon. I like to model the query situation as a continuum between two use cases: 1. A user forms a single query that will be transmitted to multiple repositories. This necessitates the use of standard metadata that all of the repositories support. The repositories must translate the standard metadata and query into a form its DB can handle. This is the model of the NVO cone search spec. A mediator in the middle may be needed to do some massaging of the query according to the repositories' capabilities. 2. A user forms a query that will go to a single repository. This query can make use of custom metadata specific only to that repository which they can advertise through a registry or "explain" service. We can imagine something in the middle in which a query includes both standard and custom metadata. Some of the standard metadata may be supported by only some of the repositories queried. The SIA goes part way to addressing the middle ground: it defines standard query metadata but also allows implementations to advertise its own custom inputs. > > * an ASU query to an ASU interface > > * an SIA query to an SIA interface > > * a JVO query to the JVO grid. > > I don't know these. Isn't ASU an intermediate query interface which VOQL > would supplant? And SIA is still a proposal and will presumably be > amended to fit the standards? What is JVO? Clearly, the SQL & XQuery cases are most important. Yes, ASU is meant to serve the same role, and yes, I would expect SIA to be amended. (The JVO project is prototyping a query language, JVO QL.) The point is that services exist today that support these interfaces. Some providers can choose to update as soon as a standard emerges; however, some may not. We can deal with this through a query mediator which has access to a registry that, as you suggested, understands the capabilities of the various query services and can adapt the query accordingly. In general, I don't see this legacy issue ever going away. Our standards will inevitablly change. We don't want to resist needed change because we will leave lots of services out in the cold. This is one area where query translation becomes important. > I don't think there'll be an 'AstroGrid' to be outside of. More a matter > of those data centres which choose to use some of the AstroGrid > components (possibly mixed with those from NVO, home grown ones etc.). I agree completely. (You mentioned, though, the need to make a choice now, I gathered driven by current AstoGrid targets.) > One component of any VO will be a query construction interface (part of > whichever portal or client the user chooses). This interface will know > which data sources are being addressed by the query and will have to > decode from what the user has entered into the interface into forms > acceptable by the data sources themselves. It would be best to try push as much of the query mediation as possible onto portals rather than end-user client apps. This would mean a simpler querying protocol that clients need to support. So one last question about XQuery: what fundemental capabilities of XQuery make it useful as an interchange format? hope this help, Ray From - Tue Feb 18 22:48:53 2003 X-UIDL: 3df25b31000008ec X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1ILlTOL016446 for ; Tue, 18 Feb 2003 22:47:30 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1ILlSU23068 for ; Tue, 18 Feb 2003 22:47:28 +0100 (MET) Received: from mta03-svc.ntlworld.com(62.253.162.43) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAJdaqdT; Tue, 18 Feb 03 22:47:27 +0100 Received: from bunyip ([213.105.123.90]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030218214343.FJBR14341.mta03-svc.ntlworld.com@bunyip>; Tue, 18 Feb 2003 21:43:43 +0000 Reply-To: From: "Tony Linde" To: "'Ray Plante'" , Subject: RE: Query message format Date: Tue, 18 Feb 2003 21:43:42 -0000 Organization: University of Leicester Message-ID: <027401c2d796$ceb0ba70$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ray, > I would suggest that an XML-encoded query format need not be less rich > than XQuery. It could be defined to allow lossless transformation back > and forth. I guess that's possible but given the syntax, functions, operators etc, I think it'd be extremely difficult to replicate every possible construct within XQuery as a tag in some xml structure. > database.) My questions about XQuery would be: who typically will accept > XQuery queries? Those that can already accept them natively, or will > people have build parser/translaters a la SIA? Is the XQuery parsing > problem escapable? I doubt anyone would be looking to build an XQuery parser to some old or complex format - it'd be easier to convert the data into XQuery-able format. Those who in 2-5 years time will be able to accept XQuery will be anyone storing data in xml form obviously plus anyone using any of the major rdbms (IBM, Microsft, Oracle etc), all of whom will shortly have native XQuery capability. > 1. A user forms a single query that will be transmitted to multiple > repositories. This necessitates the use of standard metadata > that all of the repositories support. What is needed is the lowest common denominator, but if they all support the richest query form then that should be allowed. > In general, I don't see this legacy issue ever going away. Agreed. But I suspect the major data sources (the newer ones at least) will be based on the major rdbms's so in 2+ years, XQuery is likely to be pretty much acceptable tender in all the major data centres. > simpler querying protocol that clients need to support. So one last > question about XQuery: what fundemental capabilities of XQuery make it > useful as an interchange format? In my reading it seemed that XQuery was being positioned to become a defacto standard for querying from any type of structured data storage. It seemed pointless for us to come up with something that did not at least use XQuery as its starting point. Cheers, Tony. > -----Original Message----- > From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] > Sent: 18 February 2003 16:48 > To: voql@ivoa.net > Subject: Re: Query message format > > > Hi Tony, > > > > In my opinion, the most important requirement of the query > > > interchange format is that it be easily converted into > other forms. > > > > Or, to restate, that it can be parsed and applied to different data > > stores? But it'd probably be more time consuming to write > parsers for > > XQuery than translators of some XML format. > > Yes, that is essentially correct. > > > Perhaps we need a 2-tier VOQL: if the metadata for the all datasets > > being queried says that they can all accept XQuery format queries, > > then the user formulating the query has a rich interface but if any > > does not have that, then the query format and interface is > reduced to > > cope. > > I would suggest that an XML-encoded query format need not be > less rich > than XQuery. It could be defined to allow lossless > transformation back > and forth. (The tricky part is bridging the relational--OO > divide. That > is, a query may be destined for both an SQL RDBMS and an XML-based > database.) My questions about XQuery would be: who > typically will accept > XQuery queries? Those that can already accept them natively, or will > people have build parser/translaters a la SIA? Is the XQuery parsing > problem escapable? > > That doesn't mean we shouldn't allow the definition of services that > accept XQuery. As a general interchange format, we should > consider where > the query will typically end up. If they will be compared agains XML > data structures, then it makes sense. However, I don't see > XML structures > or databases overtaking RDBMSes anytime soon. > > I like to model the query situation as a continuum between > two use cases: > > 1. A user forms a single query that will be transmitted > to multiple > repositories. This necessitates the use of > standard metadata > that all of the repositories support. The > repositories must > translate the standard metadata and query into a > form its DB > can handle. This is the model of the NVO cone search spec. > A mediator in the middle may be needed to do some > massaging of > the query according to the repositories' capabilities. > > 2. A user forms a query that will go to a single > repository. This > query can make use of custom metadata specific > only to that > repository which they can advertise through a registry or > "explain" service. > > We can imagine something in the middle in which a query includes both > standard and custom metadata. Some of the standard metadata may be > supported by only some of the repositories queried. The SIA > goes part way > to addressing the middle ground: it defines standard query > metadata but > also allows implementations to advertise its own custom inputs. > > > > * an ASU query to an ASU interface > > > * an SIA query to an SIA interface > > > * a JVO query to the JVO grid. > > > > I don't know these. Isn't ASU an intermediate query interface which > > VOQL would supplant? And SIA is still a proposal and will > presumably > > be amended to fit the standards? What is JVO? > > Clearly, the SQL & XQuery cases are most important. Yes, ASU > is meant to serve the same role, and yes, I would expect SIA > to be amended. (The JVO project is prototyping a query > language, JVO QL.) The point is that > services exist today that support these interfaces. Some > providers can > choose to update as soon as a standard emerges; however, some > may not. We > can deal with this through a query mediator which has access > to a registry > that, as you suggested, understands the capabilities of the > various query > services and can adapt the query accordingly. > > In general, I don't see this legacy issue ever going away. > Our standards > will inevitablly change. We don't want to resist needed > change because we > will leave lots of services out in the cold. This is one > area where query > translation becomes important. > > > I don't think there'll be an 'AstroGrid' to be outside of. More a > > matter of those data centres which choose to use some of > the AstroGrid > > components (possibly mixed with those from NVO, home grown > ones etc.). > > I agree completely. (You mentioned, though, the need to make > a choice > now, I gathered driven by current AstoGrid targets.) > > > One component of any VO will be a query construction > interface (part > > of whichever portal or client the user chooses). This > interface will > > know which data sources are being addressed by the query > and will have > > to decode from what the user has entered into the interface > into forms > > acceptable by the data sources themselves. > > It would be best to try push as much of the query mediation as > possible onto portals rather than end-user client apps. This > would mean a > simpler querying protocol that clients need to support. So one last > question about XQuery: what fundemental capabilities of > XQuery make it > useful as an interchange format? > > hope this help, > Ray > > > > From - Wed Feb 19 00:13:53 2003 X-UIDL: 3df25b31000008ed X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1INC6TS027947 for ; Wed, 19 Feb 2003 00:12:06 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1INC6k25962 for ; Wed, 19 Feb 2003 00:12:06 +0100 (MET) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA0MaiTY; Wed, 19 Feb 03 00:12:05 +0100 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h1INAwx08592; Tue, 18 Feb 2003 17:10:58 -0600 Date: Tue, 18 Feb 2003 17:10:58 -0600 (CST) From: Ray Plante Reply-To: Ray Plante To: Tony Linde cc: voql@ivoa.net Subject: RE: Query message format In-Reply-To: <027401c2d796$ceb0ba70$b524d28f@bunyip> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Tony, Since my last message, I found the subsequent discussion to your proposal on the AstroGrid wiki that touched on the issue of bridging XQuery and RDBMSes. I'm in the process of digesting some of the interesting links pointed to there. Many of the solutions described in those links seem to address the problem of, how do I get my RDBMS data to understand XQuery? Such a solution may be sufficient in the case where a user is interacting with a single database and refering to its native attributes directly. What is less clear is whether any can address the problem of converting queries containing standard metadata into native metadata (in the case where a user interacts with many databases uniformily). This is the model of the SIA and NVO cone search specs: positions/regions are queried in a standard way and the implementation converts that query into a native form. Today there is a wide variety of ways in which people implement these kinds of queries. If we have a standard way of expressing a sky position/region query but *not mandate how a position is stored within the database*, then a transformation on the sky position metadata must be done. > > database.) My questions about XQuery would be: who typically will > accept > > XQuery queries? Those that can already accept them natively, or will > > people have build parser/translaters a la SIA? Is the XQuery parsing > > problem escapable? > > I doubt anyone would be looking to build an XQuery parser to some old or > complex format - it'd be easier to convert the data into XQuery-able > format. Those who in 2-5 years time will be able to accept XQuery will > be anyone storing data in xml form obviously plus anyone using any of > the major rdbms (IBM, Microsft, Oracle etc), all of whom will shortly > have native XQuery capability. This argument lifts a few red flags to me: * It essentially places an requirement on the way data providers manage their data internally. * It imposes a cost of data conversion. * It doesn't address the issue of schema conversion (unless you place a requirement on the schema that provider use in their databases). > > 1. A user forms a single query that will be transmitted to multiple > > repositories. This necessitates the use of standard metadata > > that all of the repositories support. > > What is needed is the lowest common denominator, but if they all support > the richest query form then that should be allowed. As I hope I've made clear, I think there are two issues here: the query syntax and the metadata schema. An XQuery parser that comes with a database can address the first issue, but not the second. > > In general, I don't see this legacy issue ever going away. > > Agreed. But I suspect the major data sources (the newer ones at least) > will be based on the major rdbms's so in 2+ years, XQuery is likely to > be pretty much acceptable tender in all the major data centres. I'm not sure a spec based "Major" and "newer" is inclusive enough for the VO. > In my reading it seemed that XQuery was being positioned to become a > defacto standard for querying from any type of structured data storage. > It seemed pointless for us to come up with something that did not at > least use XQuery as its starting point. I certainly don't want to write XQuery off, particularly where things are going. I think it's a matter of what you are trying to accomplish. (Analogy: should we use UDDI as the basis for our registries?) This is probably where your suggestion of 2-tier system comes in. However, it seems to me at this point that XQuery as a query currency is appropriate more for the case of the user interacting with a single database in which the schema of the database is exposed to the user. It's not so good for broad-broadcasting queries (though I'm open to hearing how you would enable that). For the other tier, the solution should integrate easily with XQuery so that XQuery-capable services do not have to support two languages. cheers, Ray From - Wed Feb 19 10:53:54 2003 X-UIDL: 3df25b31000008f3 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1J9q0TS006269 for ; Wed, 19 Feb 2003 10:52:00 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1J9q0a12387 for ; Wed, 19 Feb 2003 10:52:00 +0100 (MET) Received: from unknown(211.167.66.198) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAfxaGky; Wed, 19 Feb 03 10:51:55 +0100 Received: from RsProxy (iota [192.168.3.14]) by lamost.org (8.10.2/8.10.2) with SMTP id h1J9mdx06156; Wed, 19 Feb 2003 17:48:39 +0800 Message-ID: <3E535335.4050404@bao.ac.cn> Date: Wed, 19 Feb 2003 17:49:41 +0800 From: Cui Chenzhou Organization: National Astronomical Observatory User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: zh-cn MIME-Version: 1.0 To: ael@star.le.ac.uk CC: "'Ray Plante'" , voql@ivoa.net Subject: Re: Query message format References: <029001c2d7f4$2fd426e0$b524d28f@bunyip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Tony Linde wrote: > Hi Ray, > > I'll clear up one thing first: > > ..... > >>What is less >>clear is whether any can address the problem of converting >>queries containing standard metadata into native metadata (in >>the case where a user interacts with many databases >>uniformily). > > > Good point. > > To generalise, the steps in a query are: > > 1. user constructs query, probably using interactive form > > 2. user submits query to workflow engine which constructs voql-type > query from form fields > > 3. query is 'parsed' to determine both the sources addressed and the > UCDs (for want of a better term) used > > 4. query is deconstructed into a plan (including voql sub-queries on > individual data sources and subsequent joins, requeries, etc) > > 5. individual voql sub-queries are translated to that database's > language > > 6. individual db queries have columns mapped from UCDs to internal > schema names > Should columns be mapped from UCDs to internal schema names first before its individual querie is translated to the database's language? > 7. plan is executed (includes steps for reverse mapping of individual > results back to UCD form) > > 8. results returned to user (in VOTable form) > > Wow! Big job whatever form we choose for voql. Hands up all those with > knowledge of constructing languages, parsers etc :) > > Cheers, > Tony. > -- ============================================================ Chenzhou Cui (Ph.D. Candidate, LAMOST project) National Astronomical Observatory | Tel: (8610)64877703-1320 Chinese Academy of Sciences | FAX: (8610)64878240 Datun Road 20A, Chaoyang District | Email: ccz@bao.ac.cn Beijing 100012, China | WWW: www.lamost.org/~cb ============================================================ From - Wed Feb 19 09:58:54 2003 X-UIDL: 3df25b31000008f1 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1J8tuTS026354 for ; Wed, 19 Feb 2003 09:55:56 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1J8tuf10064 for ; Wed, 19 Feb 2003 09:55:56 +0100 (MET) Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAa_aWPt; Wed, 19 Feb 03 09:55:55 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18lPxa-000514-00 for voql@ivoa.net; Wed, 19 Feb 2003 08:52:10 +0000 Received: (qmail 4176 invoked from network); 19 Feb 2003 08:52:31 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 19 Feb 2003 08:52:31 -0000 Reply-To: From: "Tony Linde" To: "'Ray Plante'" Cc: Subject: RE: Query message format Date: Wed, 19 Feb 2003 08:52:09 -0000 Organization: University of Leicester Message-ID: <029001c2d7f4$2fd426e0$b524d28f@bunyip> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ray, I'll clear up one thing first: > This argument lifts a few red flags to me: My statement there and later was badly worded. I didn't mean to imply either that we cater only for the newer/major data sources nor that those with XQuery-incompatible data should have to convert it to some compatible form. I fully accept that we have to cater for *all* possible sources of data and provide an easily implementable means of allowing such sources to play in the VO sandpit. > What is less > clear is whether any can address the problem of converting > queries containing standard metadata into native metadata (in > the case where a user interacts with many databases > uniformily). Good point. To generalise, the steps in a query are: 1. user constructs query, probably using interactive form 2. user submits query to workflow engine which constructs voql-type query from form fields 3. query is 'parsed' to determine both the sources addressed and the UCDs (for want of a better term) used 4. query is deconstructed into a plan (including voql sub-queries on individual data sources and subsequent joins, requeries, etc) 5. individual voql sub-queries are translated to that database's language 6. individual db queries have columns mapped from UCDs to internal schema names 7. plan is executed (includes steps for reverse mapping of individual results back to UCD form) 8. results returned to user (in VOTable form) Wow! Big job whatever form we choose for voql. Hands up all those with knowledge of constructing languages, parsers etc :) Cheers, Tony. > -----Original Message----- > From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] > Sent: 18 February 2003 23:11 > To: Tony Linde > Cc: voql@ivoa.net > Subject: RE: Query message format > > > Hi Tony, > ... From - Wed Feb 19 16:28:55 2003 X-UIDL: 3df25b3100000917 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1JFPjTS010801 for ; Wed, 19 Feb 2003 16:25:45 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1JFPiv26593 for ; Wed, 19 Feb 2003 16:25:44 +0100 (MET) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAo_aG7Z; Wed, 19 Feb 03 16:25:43 +0100 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h1JFOgB11025 for ; Wed, 19 Feb 2003 09:24:42 -0600 Date: Wed, 19 Feb 2003 09:24:42 -0600 (CST) From: Ray Plante Reply-To: Ray Plante To: voql@ivoa.net Subject: RE: Query message format In-Reply-To: <029001c2d7f4$2fd426e0$b524d28f@bunyip> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Wed, 19 Feb 2003, Tony Linde wrote: > To generalise, the steps in a query are: Yes, I think this is a good generalization that basically covers the use cases we've alluded to, and which we can evaluate specifications against. > 7. plan is executed (includes steps for reverse mapping of individual > results back to UCD form) Mental sticky: You might keep in mind the strategy used by Alex's SkyQuery application for joining results across databases. On Wed, 19 Feb 2003, Cui Chenzhou wrote: > > 6. individual db queries have columns mapped from UCDs to internal > > schema names > > Should columns be mapped from UCDs to internal schema names first > before its individual querie is translated to the database's language? I would recommend doing this at the same time. In general, there may not be a one-to-one mapping of requested UCDs and the internal columns; a single logical criterion (e.g. is position within this region?) may need to get translated into several coupled criteria in the native schema. (Or worse, broken up across multiple native queries). cheers, Ray From - Sat Feb 22 00:34:01 2003 X-UIDL: 3df25b31000009a0 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1LNUKP3003914 for ; Sat, 22 Feb 2003 00:30:20 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1LNUKw17253 for ; Sat, 22 Feb 2003 00:30:20 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA0OaGSH; Sat, 22 Feb 03 00:30:17 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1LNTAle026639; Fri, 21 Feb 2003 18:29:11 -0500 Message-ID: <3E56B69E.4080809@gsfc.nasa.gov> Date: Fri, 21 Feb 2003 18:30:38 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net CC: Cynthia Cheung Subject: a high level language Content-Type: multipart/mixed; boundary="------------070103050406070202030102" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------070103050406070202030102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is a first cut at a highest level astronomical query language. This is going to need some introduction so you can begin to see where we are going with this. The goal here is to create an XML language that can capture the scientific spirit of the NVO use cases. This requires using object/property relationships and therefore builds on many of concepts in AMASE such as the idea that the key items are the astronomical object and their classes. The scientist should be able to build up a query from a form or gui. An integrator service then analyses the voql and breaks it down to its atomic parts. The integrator checks the metadata registries to see which atomic parts go to which data centers. The integrator checks with the WSDL documents to create queries properly for each data center. I would imagine that XML Query will play a big role here. But, XML Query is meant for query on a specific XML database of well known schema, and is not appropriate at the distributed level. We can of course make voql look quite XML Queryish. When the responses come back, the integrator applies the logic functions to see which objects have all of the required data. It may send some results out to services and finally it forms the return tables applying the requested statistics. Thus, we need to get our metadata registries into shape so that this ontological type query can be useful (such as "these galaxies are members of this cluster", "these layers are regions of stars", "FRII is a subclass of radio-galaxy" etc). And, we need to develop and intelligent integrator. But, if Web Services are properly used, atleast the interactions between the services and the integrator will be quite straightforward. The recent development of WS at CDS, ADECC and the paper by Brian Thomas and myself are a good beginning down this road. But now I am starting the road from the scientists into the VO. A request has any number of "constraints" which specifies an object/@class and a number of properties (or properties within a range of values). As it is discovered that objects of this class are known the values and errors are saved to variables. These variables can be used in the following "constraints". Services may be used along the way, and we can only enter an element named "service" which allow for arbitrary attributes at this time. Finally, a "result" consists of a table where we specify which variables fall into each field. We may also do statistics on the variable and enter the results into that field. The schema does an xs:include on the Coords.xsd that Arnold Rots worked on. You can tell those elements because they begin with a capital letter. I did have to do some liberal editing on Coords to make it work well in this. Further annotation of the schema is coming. Notes on use case 1: Specifically this request says: Constrain results to clusters of galaxies with ROSAT X-ray measurements and images and at least one cataloged galaxy member. It must also have a name, RA, and DE (ie. The galaxies MAY also have a ROSAT X-ray flux (optional properties are in elements). The $variables do not set a range on the required measurement. The variable is set by the database. For a variable lists use @. Ed --------------070103050406070202030102 Content-Type: text/xml; name="useCase1.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="useCase1.xml" $clusterXray $image $clusterName $cz 0.6 $galaxyName $gRA $gDE $mType $gXray @images $clusterName $clusterXray $image $cz $galaxyName $galaxyName $gRA $gDE $gXray $mType @images @q --------------070103050406070202030102 Content-Type: text/xml; name="voql.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="voql.xsd" --------------070103050406070202030102 Content-Type: text/xml; name="coords.xsd" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="coords.xsd" --------------070103050406070202030102 Content-Type: image/png; name="voql_001.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="voql_001.png" iVBORw0KGgoAAAANSUhEUgAABRcAAAVIBAMAAADMs/BUAAAAGFBMVEX///+AgID//8AAAADA wMD/vr7+b3D/AAD24rXlAAAgAElEQVR4nO2dS5acuNpo+YOy3b3pEeSjBsAyOYBarhyAO3Xc rc457rpj5/QvEo/gJYGQhCS0t7MiiAje7PpAQvooCgAAAAAAANDzfw8Nn5+fnx46GM5z+P+F NrHh/54BGh5Dm1ggI3Q8hjaxQEboeAxtYoGM0PEY2sQCGaGDAgxEAzJCNCAjREMMMt5C7wSI gzhl/Ny+PYiXp+eHh4czdwmEIkoZnz6PPjx0UsLliUXGp4fm7/PTg3x7eJDDz82bGGpkfJA3 MMVvoXcY+CMWGR+ePgv5Pg9vz2Kw/SxU7IcJkhcmGhnFXyucUK+RUUTIhYxcPV6ZGGQUVTt3 GZvySvu2GhnhwkQj4+I0PZHxubmG5DR9dWKRsSvAiH8PUsThNC28lDJSgLk6sci4xcO0vgeu SCIyNhERGS9PIjJCDiAjRAMyQjQgI0TDY2gTC2SEjsfQJhbICB2PoU0skBE6HkObWCAjdDyG NrGwlvGhbcvTJ2xhOI3ha8rInZnkeFr/+gJVO8iYHMgI0YCMEA0Ry3iz2zJkTA5khGhARogG ZIRoQEaIhsvL+DBKiyJ6b+FovEQso5t706NbTE/0mEmSi8j48ND89f1ch6QUDyI+koQiGa4h 49D5/6Hr+//cZQHoEgJAElxNxofOxLuMXD0mw9Vk7C8YR5HRwV6CU7icjPfTtEjwyGk6JS4g o3BtWoBpk6E8ye8owETIdat27oFvGgPbjFEQITnIOHHviWTg0aKQ8TG0iQXtGfMDGSEakBGi ARkhGpARogEZIRpyqNqBREBGiAZk1PAUOvFMDsPj/b1+GGKQ8WZnkgsZ7WcBBiCjBmQ8F2TU gIyeedJ+7EFGATJ6Bhn3g4yeQcb9IKNn0pExfE5vZPTMvh2MjHACyAjRgIxm9DcJntoOXvRY cAkymvGg+QSWIKMZomOruEkt+rvKT/KO9fMTCSkckI2MjmR5uGcCeGp7XvffuJl/1mRTteOo nvFhnCNlJCNXjw5Axv3oZLSfO+yU8TG0iUWEMra5KGS6FE7TTkDG/UgZZwUYISMFGEcg436G nTNOz/NALmZnION+hp0zioMPJAZ3BzLuh4YSnkHG/SDjuVC1owEZzwUZNSDjuSCjBmQ8l4hl vNltGTImBzJqQMZzQUYNyOiZdBpK3Ow2NDoZaxVOl5IUyLgftzJWiu0snS4lKZBxP45lbILg 2nYio+JjTwwyhu92QGT0TDbdDqKjiYyrPpZvb6FXLRTIGAplZERGPcjoHiLjAmQMBZFxATKG QshYNgXqsi5E7WJVdIVrZNzgAjJG1xxbyliVVfPX6FjUYlhsJzIqPvYgo8BN1c5Ld6Oll7Gs Oxm7a0hkVHzsQUaBIxm7917GeoiM7XYio+Jjz2NICzuuLyOnae3HnsewHkquKmN/mqYAg4wG OJaxpJ5xBjLux3VkRMYZyLgfIqNnkHE/jmWsK2TUQtWOBtcyrm8nMvYgowb3pek1kLEHGTW4 lVHZBwYZOyKW8Wa3ZdHJ+Pz8psLJctIHGTUg47kgowZk9Ew6DSVudhuKjPGDjPtxLSPMQMb9 IKNn0pExfLcDZPRMNt0OogEZlSDj2SCjEmQ8G2RUgoxng4xKkPFskFFJNjJG02/al4zKhhfp ZCXNpmrn8vWMqiZpSuLLvYeM+4lcRkXyUSWpyvjoxy8jkFFPNpHx0YNcpiCjHlWKPSXxNSlH xv1ELqPZ7pRFmC+e1uUgyLifyGXcHRlL8SLHRcaDIKOe/ZFRlnMq4SQyHgQZ9XTJR2X6UZmt ou4y7VXyr/uhGWiTB8Qo4wyqdjQkIGNVtrlHyzarWZtpr0tx1n0sq2gj4wxk1BCnjIvko7LC sQ2AnYx1Pfxwl1FMgowHQUb9/MaRsRAvba49GRnHPxAZHXCz27KsZKxlDlJO09642W1ZRjKW XelFBEchoyi39D+0AwUy2nGz27IsZDQg3XpGZBRcSsZ078Ago+BSMqZ7bxoZBcjomXRkDN/t ABk9k023g2hARiXIeDa+ZDTvA4OMh0HGrfkps5qlku4MGc8GGZUg49kgo5JsZLxsv+nrynjd qp3L1zNeAGTcDzJ6hm4H+0FGzyDjfpDRM8i4H2T0DDLuBxk9g4z7QUbPION+kPFcqNrRELeM 6eQE3QsyaohbRuXzqx0v7zyQUUPkMiqShSKjB252W3Z9GRX7DRk9cLPbsuvLqEiJF1+D7r0g o4bIZVTst4RkTKehxM1uQ68vY123uSJmIKMHbnYben0ZFfsNGT1ws9vQLGSUWe/6VKFVmxUU GT0QvttBEjIWk1ShRcoyKkBGd/hNFiplLLqkoDUyegIZ9fMbR8bqnocRGX2AjPr5rclIZPQE MurnNz1NX6EAowAZ3XFO1U5Z9HWOyOiB8A0l3HBSPePQaiJdGa9btRNhPeOLsgniSlbZychr 86PS+0SuJ6M+id2stc1k5C8r88tGxkdHQtlwORlfNjZ4EhqnI5cr80PGE7mcjFvZPSehcTby l+X8kPFEribjVmCcGjf7qVzOL52coEqQcT9uZdxOe1zeCyv9yEP72XsZZ0cWMifrfQLIuB8P MpbzrSxH38mB8j6yePpk3577/kwhZAwAMjZfCBOvK+MMqnY0OJexrsqybXzYDJTSteaLsv1m RcbRKzIG5XoyNvo16olXOdC/d98sZSwLfWS8GsiowZGMQ/vDTrr24aeNX6J5tviurLv2NqIE U/Yjy4vFWjblrrtnlyeeMWKLiGW82W1ZPDJ274OMRdVGwaoPjjIirp2miYwCZBR4PU3Lhjay u4DyNN2BjOG52W1ZhDJOCjDtJWGpLcBcPTKm01DiZrehMcq4waqMmnrG5EHG/cR+ByZ5kHE/ Z9+bfr3XEC7uTd/bPyBjAMJ3Ozi71c64uno2crWUUdtSN40KoGy6HUTD7vaMr2MZZ+0Zi6WM Rk114wQZz2Z3S+/pjbzJyNXoHI6MAbiejPo+MCIwfn1eH3l8DkfGAFxPxu3HoI6n61uRtW+v pjKm0FwCGc9mJOOfGy5+nUzX7oa2gdnoHL5HxntFUNRkI2OU/aYNAuO0uDw6h0/bR05TKfd9 p+9V5FGTTdVOdPWMAn1o/DqdsBv57+bfWNWJjHUxeeLBXcYSGV1yRRnN6Bx9fZ2oOs21U8hc EqVMtCObokkfLyXjY1ANW5BxCI2Tc/hcxi7/mGiB0eYMLZDROcg4ucT8OsxvaKy7JmPXrEL8 jozuQEb9/FZl7Eo0REbHIOP6lPMCDKfpE0DG9cYOi6qdrgAju81QgPFD9jK+tFPWL1MpBxnL 9ce1CRKpZ5xB1Y6G0JHxpX2pn78svn0WkVEtYyJ3YGYgo4ZIZPyikFETGRO5Nz0DGTVEIqMq MtYVMp7FzW7LriKj+ppx9dHnPcjolJvdll1Dxi/LqS/UhGwGMmoILaN+fht9YFKQMZ2GEje7 Db28jIYN0mIEGfeDjJ5Bxv0go2fSkTF8twNk9Ew23Q6iwZ+MyYOMZ4OMSpDxbJBRCTKeDTIq QcazQUYl2cgYZb/pGOcXkGyqdjKoZ0weZNwPMnqGbgf7iVvGjYYSMxyvhBuQcT9xy7idI3xE nBnykHE/yOgZZNwPMnoGGfdzJRmjbDeBjPtBxnOhakdDAjIukoXWQzetyQ/IaAcy6ue3miy0 y7VTdKkbB5DRDmTUz281WajIuFPJzHht3p0hdx4yWnGz27JsZFzkZ6y7z90P7XPVkdGKm92W XVdGXbJQESOFjLX4uhkHGd1ws9uyy8rYsy5j81EOdlePccuYTkOJm92GZiHjarLQsi4SOU0j 434SkHEtWWjZJlNuCzDI6ISb3YZeX0ZVSrxy5WtktCN8t4PIZVQkCy3XspMlIaMCZHTH6ZFx DWS0Axn16JOFzkBGO5BRjz5Z6AxktAMZ9Vyg1Q4yno0vGc36wCCjFeEbSrjBX2++jSxk8Scl y6Zq5/L1jMh4Isi4RSYyPoY2sUDGbZDxNJDx8iDjfpDRM8i4H2T0DDLuBxk9g4z7QcZzoWpH AzKeCzJqQMZzQUYNyHguEct4s9syZLTm7GykyKghdxlNGqm5yLmHjBqQcT+HZEynocTtyObd QUZrkHHgdmTz7iCjNUYyHmmJgYz7Qca9yCLMF+MFpCNj+G4HyNhlBJA5KoYDM0oSUFftD/Ib axkVIKM70pZRopKxzeVTCBlLZEyBtGUs2yyk49yj5ZCdVLzLTALImAipy1h3iXCHpGbjtGdl RWRMifRknKYjlYlHq6oeco9KGeupjGJsZIyfBGXs3rsCjPBO5sPtco+2kbEgMu4ng37TvpjK KPWTMi5O044LMNet2qGe8TBTGWUi0nKUe7QcspMWMidpgYxbIONhzJ/B5aaekW4HGpBxL17v wDz6c2w3yBiKI08n9Hhv+tGXYQYgYyiQcQEyhgIZFyBjKJBxATKGol/js7ORUrWjIXcZDfOc WS8XGTUgIzJ2IGMokHHBzW7LkPEwyLjgZrdlyHiYUGuMjBqQ0TPpNJS42W0oMh4GGRfc7DYU GQ+DjAtudhuKjIdBxgXhux0go2ey6XYQDcioBBnPBhmVIOPZpCuj91yhyHg26cpo0ITsWK5Q ZDwbZFSSjYz0mz5MKBmvW7VDPeNhjsh4qJ0EMu4HGXdysKcq3Q4MQMZJMkZVxtDDffiR0QBk 3C3joewmyGgAMgoF61ZDZcbQAhk3QcbDzBI/VZU2Y2iBjJsg42GmyULLLiaqMoYWh3OFIqMB 2crYvfcy1tqMocXxyDiDqh0NyDjIqMkYWiDjJsh4mLmMbUFFmTEUGTdBxsMYV3ofrWecEbGM N7stQ8bDnHYHZgYyakDG3Ry7Nz0DGTUg426u3lDidmDrRiDjYZBxwe3A1o1AxsMg44Lbga0b gYyHOdIH5uIyhu92kLuMZlnIDiwom24H0YCMSpDxbJBRCTKeDTIqQcazSVlGzyDj2SCjkmxk pN/0YUiJtyC8jFTteAYZ94OMnqHbwX6Q0TPIuB9k9Awy7gcZPYOM+8ldRpOGEoeyhiLjfnKX 0eR50z1GufGQcT/IaM6xRI0tVO1oQEZzkHENZDyMlYwWPbOQUQMymmLXZzViGW9Ht6kFGQ+j ys9Yrx2m/stSvNj15kdGDcg4kbEq10JlPX63y3OCjBqQcZIstM26U4yyh9byZzl0KGtoOg0l bod25AAyHkaRLHT0NvliyI+HjCqQ8TCqZKFtelARHGVRZUiPN5LRLGsoMu4nWxm793my0NY4 oaa8RBxCZQaRMXy3A2ScJgtVnKadyagAGd2RvoxdstA2PWgxK9H0p+nSvgCjABndkbaMZhjW MyLj2eQko+EdGGQ8mzAyvqw0NfyiGWXyQ/fu/d40Mp5NGBnXRCo1o4xFRcYF4RtKuCGIjC+r u/SLepSxqKFkvG7VTt71jOselZpRRqIi4wJktFimYp9+UY8yEtWqD4x7GR89i7YHZDyOKqaV 98JKP0o9DAxlnGNZyA6kI0PG/SQuY9nvyXJ4k0PlfRRxN7lqb0KP6giRcQEyHmcqY8eajKWM jMi4BTIepyrKshJ/0jZpnHhbyjh6RUYNyHicqmhdbGQUf93bUsay0EdGzyDjftKT8d4SsfWv qETjQ6GhaM7QyFfKFondKPJiUVwz1qJ7i2yLaJ4VwiFU7WhIUMbufSxjUbUxcS0yFmEj4wxk 1JC0jPIc3f5rz9H1uowCZNwCGY8vqy3ASBWHAgyR0YKb3ZblLmO7E2fVO6syauoZzwUZNVxA xtmtGNM7MOeCjBrSlVF1b/r1Xgu4uDd9b+MQWdVONjIq7/ffd45qDNOmqmcwLEvRamdcJT0b pVrKaNZC4sDqIuMEZYuCYeeogoxxU9UzGJa1vtavYxln7RmLpYxGTciO5MJDxgnbMqqPiGFT 1TO4L2u1pff0Zt1klGp0DkfGBad0O9iUURkYjZuqnsF9WWt9YERg/Pq8Psr4HB5KRgXI2B8Y 3QExa6p6BqNl7WjF0Lcia99eLWU8kCUUGSes7+97AUUTGGOsKBkt689VF79Oxu42o319s5Fx rUi3DTJOmOzvIRnmqP53uV7VtNGqQVNV/4yXtaN5l+Icvp6fUeSRmDKqUT+WJRQZJxyRcRgy barqn/Gy1kLj1+no3Sh/N//Gqu6VcfT5WJZQZJwgd/U972XHRMaqLqpmBPEuX+uurap5U1X/ mC6rc/T1daLqerJQmelp9KnuU/AcSLLTkY2M+6t2hmyX6zJKDavWSfnatVWNrqnqgWUNoXFy Dl9PFlp0+Z0mKcjEQLu5DmS8btWOXsZxPsyiXshYD+1MxX4WErYm1uK1lKm3ihibqhqLv3oO X08WOsjYZgqVOUPvMtZGWUI7kFEy/Z9fERmf2tP0XUYZ9mRbVTlOfA2y3CxLkSy0HhKGDjlD T4mMjycJpyMWGetOxrrzUX2aHk+dhozr46uSha5kCkXGXeyXsc92uSjAPA0FmOJegCk0BZjk IuP6JYQiWWgnY3nPGdp9XSDjBgYyLpidpkdfToivqarhsl7a8euXqZQHKr2d1DMi4xrd/YRN GWO+A7N//JcmQH5ZfPt8/h0YZFxH3ml90owgiKyp6oFldTJ+sZbRyb1pZFxnkFHXasesqeoZ BIuMdo9T7aBqZ51BRs0RMWyqegbHStMOrhmRUYsrGdUtvQ2bqp7BARm/LKdBxgWnyKjs0THI qBzFtKnqGbit9FbuHOUesyNiGW92W7ZPRk2irX7nrDcMXLbI2mqqegZuZTTNQma7XGTclFFz RL5OZtmutrKp6hkgoydudlvmTsY/d+59xTkcGZWk01DiZrxtE9zJqBzl63SenbSqpqpngIye uBlv24S9MmowzSjRHRNFU9UzcC2jZ5BR4kXGITRO4gQyKklHRq/dDrzIqGiqajoXC9KWUQEy JrkoZPRFejLqm6qeATJ6Ij0Z9U1VzwAZPZGcjBtNVc8AGT2RnIwbDbLOABk9cUpDCafom6qe QciGEhKzxt7ZVO0EqGe8WmQ0akLWgoyrhJLxQteMkcj46Fwtc5KUUdNU9QyQ0RPpyWixKEcE l/F13npECzJKkHHHXExlHHXd3QcySpBxx1yG/IyjZBv18F6KxBKl+KLP4ThKarAPZJQg4465 DJGxrMp5lKyLNuHJOGNoKbvoGiwIGSXIuGMuXa6duuoS7hS1zDwm/kTap0okJqva4TZ9nqmM M6ja0YCMMkXbkHKsy0HWDVddPrKi7jO4IaMKZDw+l+52Sidjm2G6rrdllCkcjy8XGTVkK2P3 3hVg6t62iYziBJ1PZLwd3yoBMlrPRXeaLupilC8UGfUgo/VcRgWYop4UYAYZO0mRUQ8yWs9l Xp1TFosantnvhY96RmQUIOOMev5Yoime7sAgowAZjfFxbxoZBchozFVlDN/tABmNsZJRATIm uShk9AUyhlqWRR8YZDwAMu6ai1kWsmlalx0gowQZd80FGTuQMdSykHFB+IYSbrgv6kV/vTWb TtMd+UU1WdoyXrdqJ8J6xo3S6dS4ySM/ZvfYKtVkaWeUQEYNjmXUPGxLMjVuau40LYByskvK +OjWq0NcTsbNartJjJv+NBG1Uk6GjJ64moxbgXFq3NzcsXHqyZDRE1eTccf9jHthpReurIeB obDi/XHCyLjgojKW8r+7mdXoSdajJ6Z3I5d112d5+aD1ytuD1pFxwaVlvFPNh8cyViIylv1k ExlLGRmR8RyuJ2MpBBL/1ZWwTHa7awJcUVV1ez6ey1jeXxcyjl6TlXEGVTsanMvYmFiW4r/G v/6vdVEMLWWsCmVkLAv/kfFAQwmzLGQzkFGDIxm741TJ7DR1Kbp+9iaWwsGqGxKXgTJFg0AW S0S5peymlX2S+xnJi8Vu1Mlkbta4e/eeEm8GMmpwHhlFPJtERlmUqbqhlWtGdWQsToiMyDhw s9muaGUUp+l6fJquNKfpFpWMAmQ8h5vNdkUqY1uAKUtZgKmK7lVZgEkvMpo1rp2BjBpOq/Su xu8zGZX1jIX3esZIkoUio+B0GSO7AzMkC+3XoB9cyxha0IlfTXQy7rg3PWoNOFe3up8BF/em XT/bWiHjZsZQT8lCkVFwdqud1/GDgac/lePLsUo5mQcZ26r57YyhxaVlDN/t4Oz2jJN20lPj qrGML8rJfERGUdrakTG0sJdRATL6WNRGaHydyDht6a05h7+6l3Gopm9llLkYtzKGFgeShSKj JMY+MKIHyWi68U/V7ByumsztZvUy1nsyhhZExqOE6R1o1Jupb0XWvU1+VU3mTcbtjKEFMh4l jIx/bsk4mbBvtyhfp+fwPxWT+ZFRlF42M4YWyHiUQP2mjbp5Kk/G8xndJ3Mv4wJNxlDbekYF F5Axwn7Tm6FxNmX37evb60LVP9cnO0FGTcbQC9+BCS9j6JR4nXF//72qqttlrUF+xgFkvIfG 5Tnc+bJWiETGR+dqmYOMqpOxl2WtgIwDyBh6Wcg4gIzPxk1V3cqor6NfBRlXuYCML4FljCQL 2WNoEwtkbAJj20bxy/4+d8joCWRsT9NfXr7snkViMs6gakdDLDLunwUyegIZw0fGc0FGDXHI GPKa8VwilvFmt2XXkPHFrHoHGT1xs9uyK8gY9bLcg4wakNEz6TSUuNltKDLGDzJKkDEGkFGC jDGQjozhux1kK+OuNhEOlpNNtwM9gbodJLKsPW3HTPq6qEBGCTLqQMY5yBhsWcg4BxmDLWuX jPs6QmhBRgky6tiWURZhrHImC7KRMcp+04ks656Ysc0kcaeu5gmfbcimaod6xuPc9ZPJde7H pE9k0j6dARn3gozH6ZLstFFRDBRtkp2i7h5Bc6qMj4FFFCBjsGW1MnZRcZosVPxXIKMhyHhg 8ns6SGFdXfSRsU0WWhV3GcVYyLgXZDw+eVeAqbvI2CYLFTYSGY+BjMcnH07TbQHmniw0SAHm MayHEmQ8fVmzzPKyHmdIFipz4clTdYGMhiDj8cm3K73d1DPOoGpHAzIqcXMHZgYyakBGDS7u Tc9ARg3IqCEvGW92W4aMxydHxjk3uy1DxuOTI+Ocm92WIePxyXf1gXHfnhEZNWQr4870Y5Yr i4wdyKifHBmn3Ow2FBltJkfGKeG7HSDjuTIqQMYkF+VOxnNARgkyepjcGGSUIKOHyY1BRgky epjcGGSUIKOHyY3JRkb6TZ8+uTHZVO1Qz3j65MYgowQZPUxuDN0OJJeX8WXcpmHWJHvy29rk uxpKKGZuAjJKLi/jpBXYLH3d5LcvK5MbPWgaGbfJW8aX6b6cCDP9rVyZHBnnIKPFsmY6TULj 7Lcvy8mRcQ4yHl/Wy3xnjo2b/VQuJzeS8fX4g1SRUXJxGRc2lffCSv9bPQwMxRBzGUfztYeq HQ2Jy1iOdqYcLu+/idRNVZvhadQhf5Zrp6eWSSS6L+rJQRrN1x5k1HBlGUsZGXfJWLbJa1Uy Vsi4Se4y1pX0rf1byjh6Vcgo8471eZRF4qf2i7qo+5xkRT4y3uy2LHMZy6IsxX/ybyljWWxH xiFLqMz21CYLFX993tC6QMad5CnjkO1TCigTH7fSiJJG2f8mLxbFNWMtLgdl4s/JTZVexjZL aJuYsTNQaFn3Ocn6+Tpae2TUkJ6MPa2MZRu4irXT9K7I2GUJLcqxjDKZcm+jXWRMp6HE7egm tmQvozhN16rTdMe2jIOF99N05ew0jYySy8vYFmBKZQFmV2S8Zwkt61EBpnZVgEFGyfVlnLIq o7aecR929YzpyBi+28GVZIzyDkw23Q70XLTbwbDM+c58vXe5X9ybvicUC3xvWgEyJrmoO/NW O+P8D7PfKmTcBhltFjrdl69jGWftGQtk3AYZbZi29J5mxpn8Vo3O4cioAhmtljq+oyIC41fF b+Nz+KE+MMi4TZb9pkfoUob1rcjat9eFjDuzkPV8PbqO2VTtZF3P2PCnRpjuqrFtYzY6hyOj CmS0Qx0Yp+fh0Tk8ThkfQ5tYIKMtf2p86X77u/k3VhUZVSCjRzqNXl8nNpFRQgUyemQIjZNz ODKqQEafrJ5mkVEFMp4OMqpARo+sr1TgVaVqR8OFZVxv9YWMKpDRHy/tStUvUymRUQUyeuSl famfvyy+DUfEMt7stgwZdXQyflmX0aihhE220CnIqOH6Mioio1ETMpuceFOQUcPVZVReM54l YzoNJW6Ht1GCjDqalfqyXDFkVHE7vI0SZDTnmIzHW9ciowQZ1zggo1Vf1cAylvsKaGLUtmpH WWzbVbzbfMiEyb46SKIytukYlXlCy7qYp6owJ3C3g3J7lH4sKeOkJ9tkmzX/935ZH2ntIRMn kKiM7R5X5gmt+59s8pskJuNUubFOe2TcfsjECSQqY5tpR5UnVKYns878lJaMs+6/443eI2Ol +B4Z15nKqMsTKmTMJTK+vbUyzo0b6aSRsS/e7XjIxAmkJGN3dd3JqMkTepfRJltoAjJ2++P/ VlLGrOQv2jGKJsXRCSQkY093najJE3rVyNiZUg8/d3naVmWUL8MO66YbEvNXo1E+73rIxAkk K6M2T6iPAszpVTvLb8Yhrh6UMZFxMquFjNqHTJjsq4MkK6M2T2hZF9eQsXuiQ7tZ8jKkbIts bTZUAxnlzqm6/Vb1xbupjKNXZNyHSaX3/YiYE7jbgVz3RaroohpOAMVSxtbVarbpQ97pYXb1 amTUP2TCZF8d5OIy+r8D82iv3YzxvZW2YCZNqtt6VREh7zLWw6Mg7tO1hZrJEyTGMspL6lHx rh9f+ZCJA/vqINeWsfB/b/rRtYt9MaWNjIOMslzWlswsI2MxyNiN8nlamiYyGpCVjIvTtFbG EQdO0+PlI+M+cpKxfyRdV/AYnaZLqwJMsVqAITIak5OMe0bdXbVTzGqHVmU8Vs+YrYyaFlEr WGQLnXJa1Y6BjMZ3YOq1UT7b34HJVkbDLGRXllFzb3r0BImte9OfV+5NG+bbQkZkHMk4b7Xz ZiTjfJxXZFMQGEkAACAASURBVNwLMg5IGW9iRaY6jZ8gsUfGWXvGN2TcCzKOtelkfJl9bSbj dKRxzn9kjJDTZdxXQBtkVGWf1pb47jJO+sCMVUbGGAjVUGKIUX/si/y9jH/Ovh+tpP688Xlt nK/9tMgYA6nJONPp62gl98g4c3mYFhljIDkZpzqNV3KPjM/zrzuQMQbSkbFPibdu0/OWjB0T l+/TImMMhOp2YHa7U2CZn1EP3Q5iABklyBgDyCgJIKOyJuq8VYkNZJQEkFHZt/a8VYkNZJQg YwxkI2N0z5tGxgXBq3Z2E15Gt1U7Shnnz9/NB2SURCPjvb1vhgTudmBAHjLee0JkCDJKIpKx RMb1jz2Pluqt7XRTLiljm6xmsl+QUfGx59GNgZOdbsoVZRz6ho/2CzIqPvY8ujFwstNNuYyM 3Y0WhYziF2Rc+9jz6MbA8U43nuIyMnbvRMYtqNrRgIzngowaPBVgZvsFGXuQUQP1jOcSsYw3 uy1LRMas78DMQEYN3Js+F2TUgIyeSaehxM1uQ5ExfpBRgowxgIySADJqcrk4WU6CpCNj+G4H rvtNK7t5O1lOgmTT7UBPkK6qyDgDGSXIGAPIKEHGGEBGCRklYgAZJcgYA9nIGF2/aViQTdVO dPWMsAAZJcgYA3Q7kCBjDCCjBBljABklyBgDyCiJqaGEk6UkCTJKYmpC5mQpSYKMEmSMEKp2 NCDjuSCjBlp6nwsyaqCr6rlELOPNbsvilnFIK0En/jvIqOEcGUlv0oOMGnzk2qnKuhZP3b7v l4xlTKehxM1uQ6OUsSzqNhEZMgqQURIoWWhTXpnLSLJQ1cceZBT4yM9IZByRjozhux0go2ey 6XagJ9Tj2trTNAWYFmSURPPswKzrGZFREo2MWd+BQUZJNDJmfW8aGSXIGAPZyBhdv2lkXJBN 1U6U9YxrIKPiYw8yCkgW6hm6HUhIFhoDyChBxhhARgkyxgAySpAxBpBRQkaJGEBGCTJGCFU7 GpDxXJBRAzKeCzJqQMZziVjGm92WIWNyIKMGZDwXZNSAjJ5Jp6HEzW5Do5ORZKELkFESUxMy J0tJEmSUIGMMpCNj+G4HyOiZbLod6KHbQQwgoyQaGemqugkyul/UeA9U0yFk1IGM7hc12gPl WEbSm2yAjO4XJRM/yUyh1T3VDjJucwEZo+w33aUgIzK2ZFO1E0894yhZ6IqMJAtVfexBRoEb GXuIjAvodiBBxhhARklAGZsCTEEBRoKMkkAyKvYLMq597Hm0Ek+5043IQ0buwCg/9jxaqrcE Gbk3vQAZJcgYIVTtaEDGc0FGDch4Lsiowa2MJAvdImIZb3ZbFp2MZCHbAhk1IOO5IKMGZPRM Og0lbnYbiozxg4ySIDLCDGSUIGMMpCNj+G4HyOiZbLod6CEbUwwgowQZYwAZJcgYA8goQcYY QEbJPhmfHjo+M+xleNdRuICM0fSbhr1ct2oHGZMDGSEa6HYA0YCMEA3ICNGAjBANyAjRgIwQ DVTtQDQgI0QDMkI0RCzjzW7L9snI0yUjIncZeYZaRCDjOsgYAGRcBxkDgIzrkBosAMi4Rta5 jcMRsYyndDsg63v8ZC9jxs/DiI68ZKzrYvRoyQIZ4yIrGdvHVk1XFhnj4foyLp4uOVnZnJ8u GR3Xl7F7JzLGzwVk3F+1g4yRcN2qHYN6RlGAma0sMgYAGZUri4xnk3u3A+7ARAQyrsO96QAg 4zrIGABkXAcZA4CM6yBjAHKXkadLRkTuVTs8tioikBEZowEZkTEaIpbxZrdlyJgcyAjRgIwQ DcgI0YCMEA3ICNEQsYwRPK4NYgAZIRqQEaIhGxlJFho/2chISrz4QUafCwcjLiAjyUKT47pV O7T0Tg5kXIOuqkHIvdvBeLWq6RAyng0yDpRjGUlvEgBkbCys6+a/apQvFBmDgIx9FrKayBia bGVcJAudyEiy0BDkKmMPkTEicq3a6UHGiEDGVsamAFNQgAkMMipXFhnPJmIZb3ZbZiMjd2CC gIzrcG86AMi4DjIGABnXQcYAIOM6yBiA3GUkWWhERCyj124Hd8hCFjvIiIzRgIzIGA3IiIzR kJGMEDvICNFwARn3Ve1ARFy3agcZkwMZIRpy73YAEYGMEA3XlfFB0ij59PDAcBrDl5URrgIy QjQgI0TDBap24CogI0QDMkI0xCDjLfROgDhARogGZIRoQEaIBmSEaIhCxv7epbhlyXC+wzHI COAJZIRoQEZwQqnMSNNxH3X87cQ/ZAQnlLt/L9e/LpARHLFfxqly6w/mA7Bgt4yl4vsCGcER mzK+vbUDc+Oq1UGA4+hlvBdWFuOV9+INMoITlDLKH6rhZSnj/VtkBCcoZZRBDxnhRKROzelW Ppe5Hp5uVpfy7IyMcCKtjPcHPo7eiqWMdaNqMbqINJVxs4p9XtEOOdHL2JRTegvbsNjKKMov vSDTOzBlKUdc3I7ZXpqjseByDJFRvA4hsaw9RUaHY8HlMDtNzydERnBIJ2NXgGneugKMjJU7 ZTRc2vZYfUU75MVEj0XJIYSMhpehcB30Mu67A3NwaS3VaNGzinbIjMP3pl/v51Kba8ZyPHF3 nVoiY57slnHeauftsIyluDytSnmVWsl6JFFEL+8V7ciYKbtlnPnxelzGel5wL8TgqASPjJmy X8Zy9rVRkXd8b6W+V2m2dUoyQt5lFJepyJgjmzfo7s6NvxWB8S+DxXRyDRVJXUisuzciI0j+ UD7usUM1oslCJjIuTtPICC27ZSymX/81fL/DnLGMXQGmbyA0Ok2XFGAyZ7+Mf6x/bSrjnlGR MU/2yzgJjX/dv3YrI3dgwC8GMnJvGvyCjBANyAjn4PaaERnBAgMZ9/WBQUY4yn4Zd5Td5yV4 AMcgI0QDMkI0ICOcg8k1I4BXkBGiARkhJZARogEZIRqQEc6Ba0aIBmSEaHDUUMLvSgJ07GhC RiI8OAdkhGhARjgHNy29ad8NDkBGiAYLGUfpGZERzoHICNEwzbVTtc/katM9ycw7BTLCWUxT 4nUpx6SMbU6yAhnBCTuuGSfJQvsHcnUmFu33yAgOMC3AiBN0+ySkTsb2N2QEewxlvD+Cq644 TcPprBVgWhkpwMDJULUD0YCMcA7cDoRoQEaIBmSElEBGiIY9fWCQEU5hXxaykGsI18BZ5lqf Kwl5gIwQDcgIKUFGCYgGZIRoQEY4BxI/QTQgI0QDMkJKICNEAzJCNOyV8aHh+fn5oYfhY8Ne D2bUOLxm/PwMDniyOp5Jg4yxgYyWo0iQ0QkZy7gDZDwVZNSBjKeCjDqQ8VQylpFrxthARstR JMjoBGS0HEWCjE7IWMYdmMs40rK9uwD7QUYde2W8785xjMRFQ5BRh4GMTw+fm7+Hh6fPT+JV RMWH5t+TiI/ND6GPcxJkLKPDa8ZnGRMb+YSKjYzP4lWo+LmVkyC5D6vjmTTuZXxQycjV4z6s jmfSeIiMz6rICLuwOp5Xx/Y0/fzwmdO0AV4PZuoYVO008olySuPdw1RGCjD78XowU8e60vth WtkDerwezKg54Q5MExGRcT9U7ViOIkE4JyCj5SgSZHRCxjLuABlPBRl1IOOpIKMOZDyVjGXk mjE2kNFyFAkyOgEZLUeRIKMTMpZxB2fK+NQnnPmcxzAyGkJkPBVk1IGMp5KxjFwzxgYyWo4i QUYnIKPlKBJkdELGMu4AGU8FGXUY95u2ORIuZpIKVO2Yg4yeQMYZbnsHWoOMdDuwHUXi4vgI GZ+WvQhFt4Xr9btGxhkRyrjinOxDczUXkfEAJ8vY5ut5au/ifn6Wf9fM2oOM5pzaUOK5le6h i4UPT2Lw4ZpZe5DRnIAyPoh0ACIzwCWz9iDjjMjuwIxlFEkpWv8umrWHqp0ZEcvYnqY/j07T F8vag4wzopRRFGDE3GQB5qFT8HpZe5DRnLNl1HCtrD3IaE48Ml4saw8ymhOPjBcDGWdEeM2Y Dcg4AxnDgYwzkDEcyGgOMnoCGc2h28GpIKMOZDyVjGWM7JoRkNF2FEk0MsaQRMcguc587a2O Z9JcUcZoQUZrkNEVyGgNvQNd8Vn7sQMZdaQmY7wRGhn1RNg70JZ4ZZxBt4MZyBgOZJyBjOFA RnOQ0RPIaE5qDSWQ8cKkKGN7t0Om6HnaeefjfJBxRmR3YBzJ2PWUkTJG1G2Gqh0915RRpKGQ /V1lz1bZz/Wh7fYaFGTUc00Zu67+bX9/oWL3MXCQREZrUpXxYSFj6KtHZLQmVRllop5pZHQw d8s103zsQEYdycp4j4xPXf4eTtNRc91rxlEBRspIASZ6rinjYrafo0hchox6spDx6SGOjODI aE36MsYCMlqTWreDWNZjCd0OrElNxnhBRj2RXTNeG2TUg4wngox6kPFEkNEaZHQFMlqTWreD eKFqx5rUZHQXoV9qBV+crBkyzqB3oIYX1aYelHEG3Q5mIKOGl7KuV7ceGb2AjBqIjNGRsYxN ZFzd1Ne3rw5mj4zm5NtQQhkZkTEUGcs4i4zDB2T0QmR3YCKTcbaFtjJStaMHGTVIGUW9YtW8 FiJMdpESGb2AjBpaGcW/siqr7k18h4yhyFDG/k6L2KyJjF29IzKGIkMZu3rElcjYbioyhgIZ OU2fA9eMayxkpABzBsi4xljGNZDRC8i4BjLGCjIuQMZQpNbtIBkZ10FGHanJ6ABkDEJk14yR gIxBQMY1ehlVfWCQ0QvIuMbQkvvPNwVfj8wWGa1BRmSMhtS6HTjgHBmp2jEnNRndVe0g47nQ O3ANN73/tqDbwQxkXAMZg4CMayBjrCCjJ5DRnHwbSngGGc1BRk8g44zI7sBcW0aqdvQg4xrI GARkXGOroYTAfs2Q0ZyMZdRsbWm/ZshoTsYyqpKFFsgYiIxl1GwtMrqHa8Y1RpFRtbXl25vt miHjDGRcY09kREbnIOMaisg45NopkDEQGcs428KxmcgYhNS6HbjOtTNKFlpWpci3I/aIAxnX QUYdqcnoAHUWsva9QEYfRHbNGAnLZKFNOGydrJHRG8i4xkpkLNq3msjoD2RcQ32aRsawIOOQ LJTTdGhS63bgACq9YyU1GbkDkyr0DlzDk4wz6HYwAxnXQMYgIOMayBgryLgGMgYh44YSuj4w yBiCfGXUZCET2C4FGWdEdgfm2jJStaMHGddAxiAg4xrIGCs5y+gWZLQGGV2BjHsp6/vfBGR0 BTLqWTet3B5lCTJugYx6FKZV26MsQMYtkFFPb1o5/bpcGWULZNwCGfehMQ4ZXYGMu+gj4VB4 KYfeccl1O0hGxnWQsaMs6y6jRzm8JCejA/Y0lKjNjUVGPZ1pXWQUCRNGHmYvo3Z7kdE1ExlH r8j4rE8WiozumchYFURGCZExCCKnkfwrZHlFXjOKcFCK97YUk7GMmmShRfFq/GhVZDTCJjIa Hpn1I+FiJvbsiozWMlK1s03qMjrsduA3MiLjOuN6RmT0FRln0O1gnbuMx+sZ7Y5MS4Qyln0q PPkn7gYU7S5CRk+4uANjd2RaIpSx6lOPlVXR5yKTub2R8Txe3/5qBzKUcZwsVOQdaxwUKciK NgdZV/uIjOdhLOP1Gkq0KfG6yFg0Mg4hst1BX+2Wgoy7QcZBxrLPXltzmj6Fcv7hDRm7Akxb bqna07RNAYaqnb10/V/knm/8+wMZV6t2quFpMMjonT5CviHjqozlcHsUGT1Sjd9ekZHbgQEp 2zYT8pKoFhkTuu+RcR1k9EmXteP17VW+/9V9jYzrIKNP/mhl/Pvv9r3/GhnXQUavDKFxHBhz llHbBwYZvfLHOMfW8G2+Mm5kIUPG80FGZDyfecanjtS6HSQj4zrIKKnWvUtNRgcgY3BaGctq 1gUrZxndgoz7aWWsyqqcfb0PZNwCGffTy1ggo5/ZIuN+iIw9yBgcy2tGF4crrn7TrqFqZz+i JeOKeqnJmExKPGQ0Bxk9QbcDc5DRE8hoTr4y6htKHE0ZurWiXg9m6mQs446tRsZTybehhD5Z aAsynkrGMu7YamQ8lYxl1KbEazFpYkvVjjUZy7hjq5HxVDKWcR4Zy/u+qNsE6Mh4LhnLON/E u4wy6Y4YQMZTyVzGWmTZkTnx2kQ7bdpQmTXUNP0TMlqTu4xt2rF6NCDSHcjYWCDjyWQo4zhZ 6ELGGhnDkaGM+shYIGMwkHHlNE0BJgzIKAoxrYx1nzZU5sgSPyPjqaTW7cCljF7vwKyDjDpS k9EBg4yKvAYjkPFUcpaRyBgZGctY1uXWViPjqeQs4/a2I+OpZCzjjq1GxlNJrduBAwz6wFC1 cyqpyXheSjzTXGTIaA0yupJx34p6PZipg4zIGA3IiIzRkLOMXkFGc/JtKOEZZDQHGT2BjOYg oyuo2rEGGV2BjNYgoyuQ0RpkdAUyWoOMrkBGa/KVcU9DiXV2rRkympOxjEd3WblrzZDRnIxl 3JEsdBVk9EXGMh7dZcjoi4xl3JEsdJXy7W3HmiGjOal1O4ghMu6ScR1k1JGajA6YR8ZRjtBh 4B41ZbetshgFUWT0RcYydltWrspYTfoOTs7nyOiLzGUUmUHrok8U2g6JD0JGmXdHDNUyf2gt s/IUyOiPzGVsk4/dM5B1uULvGcmav36wz02GjL7IUMZJstBa5mO858Uby1jXXWRExnNIrduB AybXjJ2H40g4SRzafnVARqp2zElNRk/JQtdllNeQyHgamctYyrSgfYGlO02LAkybOFTK2BZk ZAFGJ+O+FfV3JC9A5jIeARl9gYzGIKMvkNEYZPRFxg0lju4yZPQFMhqDjL5ARmOo2vFFxjIe 7gODjJ7IV8Z9WcjW2bFmyGgOMiJjNCAjMkYDMiJjNOQso1uQ0RpkdAUyWoOMrkBGa5DRFcho TWrdDpKRcR1k1JGajA5AxlhBRlcgozXI6ApktCY+GZUNGO4SPcreKfO/2XzWJ33ebihxUFZk tCZCGVWrcJdk6/fFbCZZ7LaakCFjKOLrdqBM4jlI8ri+itO8idX6tM/byULdyEjVjjkRyqha BZlMWxxj1Tp/Uc9lLOo5kREZzYlQRlUSz6psj7G6ifZoLvPtGhn2ZWM5r8cfpTqCbgfmRCjj 6vLL7jkDn9WBUcTOvvwx5Lsb0izen1OwFRmRMRQRytinpytkXsQuT2IpX+Qxvn+uSjk0bIMc GMtYln3az37650VkLOe7ABlDEaGMYnFdQJvL+DZExnJY+XK2MWMZKxEZy/v0cgGzyIiM0RBf Q4lWxiG5Tb0mY/OzzOFZyiGhnDwfz2UsR5PKF7mAWa6dIS9onysZGUMRq4yj7GBy+RMZy+b8 26x5Y2E7VMm/pYxVsRUZ28xj3VuFjGGJSMZJEk+Z430soyiBlPWXz/UX+XMpgpoMZlLG9mQr 8ntW/Uzki7xmFNG1m36MXE6XbKy2l5GqHWsiknERscaJ3keRUa52FxnboaobYXHNuBkZizb7 nbBQnPDlV8gYiphlVJymi+40XW6epovRpPJlfTlt4kVkDE68MuoLMMLSShZgSnUBZjsy3gsw Rd2Xq5ExFJHKuGBetaPemJmM6npG1VyQMRTJyNhmuYn4DgwyWpOKjGJVRfqvz8pGOw1vd43m 21XdHUPGWElQRmVd3R8jGeetdgpkjJ8UZXxUjPA2knEWGitkTIAUZVRcNb5OZJy29JYpPr/u Ww4yhiKibgdbfVPuMr6sdYGpZxmZJpNKVb/uW44bGddBRh3xybhW+Gi55y9WZQf7Oppd34ps mHYmoyYL2Xg2u0FGa1KQsW8kdpdRpdFkftV4C0fncGSMlRhlVJ0/R8m090j0Mp10mBgZYyVG GReu/S3/xqFv3aPZDLtvX99eJ4ohY6wkIePg054HsNzpZPt7JvLB3n9bIKM1EXU70MjY+2Qm 4z00TsLdOTJStWNOGjL2gfHNLCXe5Dy8thyXIKM1ccqoxsHlgicZZ9DtwJxLy7g+R2SMldhl nH9pIuMLMqZF5DIufDKR8UvbtPHLLMkdMsZKfA0lpt/NfTI/TX95+fKyuRz3IKM5kcu48OmI jM+rMrpOFjoDGc1JRMZnGxnXIyMp8aIjERktIqPqmpFkodGRhIzHrxlfVuZKZIyV+GWc+uSu 0tt1slBktCZ2Gec4lFG1qcgYioxlHCLjLEMjMoYiYxlVm4qMochcxrajVzUpVyNjKHKX8Z6H bAAZQ5GhjJNkocgYEXF2O1CTTGRcBxl1pCaju+UgY3QgIzJGQ+YyroGMoUDGBcgYCmRcgIyh iLzbgQ+4AxMrqcnI7cALg4wLeFxbKDKW0XGy0BnIaE6+MrrOQjYDGc1BRmSMhgwbSiBjrCAj MkZDzjK6haoda5DRFchoDTK6AhmtQUZXIKM1yOgKZLQGGV2BjNYgoyuQ0RpkdAUyWpOvjK6T hSKjNRnLqNpUZAxFat0OHMroN1noOsioIzUZ3S3Hc2RcBxl1ZCyj32Sh6yCjjoxlVG0qMoYi YxmJjLGRsYyqTUXGUKTW7cABYxllstBC5gsdNpWuqqFITUbH9Yxt4qc291MPMoYiQxkXyUKb +FiMqhzpqhqKDGVcRsYKGaMAGaWMDk7TM5DRHGSUp2lkjAEaSixAxlAg4wJkDAUyLqBqJxTI uAAZQ4GMC5AxFMi4ABlDkbGMjpOFIqM1+croOgsZMlqDjMgYDciIjNGAjMgYDTnL6BZktCa1 bgfJyLgOMupITcZ4l4OM1iCjK5DRGmR0BTJag4yuQEZrkNEVyGhNat0OHEDVTqykJuMJDSUO yoqM1mQso2pT3UROuh2Yg4wLkDEUyLgAGUOBjAvoHRiKfBtKrMtYyjKM/UKQ8QCdjKWqaFl3 Wdjlvp0UQMe7WFkynYzdyqgsuMYho3yxXwgyHqCXcWsUuW8nYXTsjvKU1yMP79Ni1MlRj0XG 6piMVO1YYyLj9PCNj5iBjNPrgrGAIWQsRZ7QshpOAMgYEhMZZ9eXI3n2y/iy8v1UEqNDfoSx jDIHmUyJV9T9jkDGUOyQ8fXtLynj3LjRIduW8e2tlXFeYBoZeJaM/QWrWHzzOpNRXD0jYxi2 ZCy74/Z56VFxL4NsyNiN+LQy4qj0GuSasSYyxsNSxqmXZfeyJqP84i5juXySRVmNR1yVUb6M JTE65EfgNB0rSxmnShnIuPJUlehlLMWzDmpkjIOxjLXM4SoPjXiV5UsTGatS/nWHWD7Ror0y i1fGBcfrGZHRmomM94v5JqS1sWIuY1lLx+7TjiNjO2Fxf5yFmF+xlFHOoa1LiU7Gw3dgkNGa SdFSHIq5jLJ02d2JmdynaRwTX44nH2RsY2xV9DKOR5ze3BnNPwoZC7KQBWeIjHenDkdG4XMh w2IxjYzPCUTGgse1BWf3aXqM9jRdLU/TawaYyugAZIycTsauErg+KKO8uVb0ZdSivdW2HHGx YBcNE/aDjJGjrvTuXnbIqCZOGVUNjJAxMKfcgVkb0Vn7wf0MlwNes5Ctg4w7OHRv+n7U9t2b FsyNfu1/CNBVFRnjZFNGsSer+feGMq612nm7qoxU7Rxml4yz9oxvR2ScGf1qKqO7qh1kjJVd Mk5Fej0m48vs67uMRw75Ec6JwHQ7OIyuD8xdxkkBdOzRdh+YQcZJH5hX4zCEjDnwh+qc1fBX 31VVfTpTnvIGehnnYzo5xiYgY/TsknEm0mgn75dxZvTXYRanXzN6BRkt2JCx27cKj4xk/HP2 dQ8yQsc+GScijXeygYwTo7/eZ4GMsA8HEmxllNhFvDJStXMayLgFMp7G9WQkWWiynCBjLI1r kTF2Lihj2ac0mYGMsXNBGVWbioyxc8Frxq4f7QI6ZMXOBWVUbSoyxs4FZZxFxuEDMsbO9a8Z kTEZXMi4QQgZRb2i7MlYyrwDclPpkBU7scjobjnjvt6yt3jXrxYZo+cEGc+iv9MiNmsiY1fv iIyxcyEZ1ZGx3VRkjJ0sZOQ0nQZXvmakAJMYRw7P4kjofw4h4xpU7cTOkcOzOBL6n2O5N42M sXPk8CyOhIN5xCvjDLod+MPB4UHGZ2R0goPDg4zPyOgEB4fn4teMM5DRHxdsKKFO5/LVfiHI 6JHryeg6C9kMZPTH9dozkhIvWZDRcM2Q0R/IaLhmyOiPK14zugUZTwMZt0DG00DGLZDxNK54 zegWZDwNZNwCGU8DGbdAxtPgmnELZDyNWLodJCPjOsjoglhkdLccz8lC10FGF1y0d+AayBg7 F5TRb7LQdZDRBReUUbWpyBg7F7xm9JssdB1kdMGRw7M4Evqf6TcN+zhyeBZHQv/z2d0OSBaa KkcOz+JIOJiHvw5ZtjLOoNuBPxwcnhhldJgsdAYy+sPB4YlSRndZyGYgoz8cHJ5Yrhk9JQud gYz+uFBDiQ7XyUJnIKM/spCR03QaXKg9Y4fnZKFU7fjjojKugYyxg4yGa4aM/rjoNeMayBg7 yGi4ZsjoD2Q0XDNk9AfXjIZrhoz+uKCMjpOFIuNpXE9GspAly/WuGZExWWLpdpCMjOsgowti kdElyJgoF+od6AlkPA1k3AIZTwMZt0DG07jiNaNbkPE0XByuSPpNe4KqndNwcbhiq2d0CzKe hovDFdsdGK/Q7cAfLo6PCxkfOkaDsQxPQUZ/OPDIiYzJgIz+cHF8rl2AmYGM/oiloUQyIKM/ kNEQZPRHLO0Zk4GqHX8goyHI6A9kNAQZ/cE1oyHI6A9kNAQZ/YGMhiCjP7hmNAQZ/YGMhiCj P86T8aUoa/2fg1XxDzL647xrRmXakQEHq+IfZPTHed0ONmUs/a+KN5DRBefJ+Li1KsiYO+e1 sH7cWpXy7e20lXENMrogGhllorBkqySR0QXnySivGcvl03e7x7TIV2TMmpMLMCtPgh5kLJEx c5wcCf3PExmrUv6JGFkV8q97Im8qMlK14w8Xx2efjI9icd2Tq9qhUgz2D7BCRnBxfDZkbIol 4k+ejUcyykdXNYO9jOKhvMnKSLcDF7g4PvtuBz6KxfUy1lUtrhbHMiYdGZHRBS6Oz95708X8 NF1d+1+oLQAABLBJREFU5jSNjC5wcXyMZBQFGCGfLMDUogCDjNByZqsdLanUMyKjP86T8VG/ IqncgUFGf0QjYyr3pqna8UdEMhbImDnRXDMWyJg9yGgIMvojpj4wyJg5Z/YOVD65asDByvgG Gf2BjIYgoz+Q0RBk9AcyGoKM/iCjhCHI6I9knr8SN8joAmR0AjK6ABmdgIwuQEYnIKMLkNEJ yOgCZHQCMrrAyZHon/r4OY9hZPSECxkBGZ0Q+ihehdDH8RKEPohXIfRxvAShD+JVCH0cL0Ho g3gVQh/HS0DVjhtCH8dLgIxuCH0cLwEyOoGqHRcgoxOQ0QXI6ARkdAEyOgEZXdDecG12Z3/v leFDw6GPIwAAAAAAAAAAAAAAAAAAAAAAAABAOP758X6In6FXHC7Hfw66iIyX58f7r/Uf3rv3 7z/b/5pvvn3/2Rjx/rP5+OH9/T7qJ+nJ97ksH4Q/n369z77VuPi7QMaceX+fydJLdZdR/BND P/798e/7rw9Sxu8jNz6081DK+GGyhO8a3ZAxaz7OVCkWMrY6tu/v395/f2xl/PlpJGOhkLF5 +fSzmCzhg043ZMwaIaOIdW3E+/HzvfkkvpCn4U//fv/24/uv9/cmmn0r5Bn3/f1TK+MvodW3 91a2b4WcR3MeF5N/+lXIUCkkbGbcTP1Tfi8X+B/p1YffH38V3//98U0MNHP8+Lv4t/hY/K/4 3Sy0+NRcCnxqzPzUffqBjFnwUQrzPvy9v//qB0VUa87LnYyNCR9/i8j1Xcr48f3fD2LcbyIe /vjdzeOX/OvH//D+v/++Sxnb7+UCW7GKXx+aM/i374UYEN79/PivWJtGSfHXXBF8em8HxadP yJgFH5tI15x++79P/36Sl4jikwyFjUo/+6vGD01Z5/3Hjx+yAPPj9z/vH3+Ly0gR7f77/eeP ZqRfTVR8/9RM/e8nOf67/ELE3r4c0xVfGsdEJPwoZGu8ey++NUsu/m1k/CT+vn1vYuy/n761 n34iYx5IGX9LE8Vr45Uw73crYxMKf/++yygj4/f33sz/NjI2+jXn7+L7b3kZ2Xz6IWX89p82 Mv7zz0LG1qtvDf98aBADTRz9V8RCIePvfuDHuwiOyJgT4ppRnGJ/tq8ffou4134hfvz9PpJR XjN+ev/Ulmca8z7+Fn4WQrFexncp4z/NbOQ144e5jB87GYtvxT/Fh+KDGBAXm9++tw42Z/9m 4NeHRlpkzA0p489/5Im5ef30qz1N/yNlbM7L77/uMsrS9Mffn3725n38/UHWUjaO9qfpD//I 0/SvT3oZxVn6f+I8LQZ+NNeM/37sTtPyTP1bjMdpOjva4kYfGT/9FiXfvgDzobkk/K8IlK2M sp7xg9B1KK0U0pB+HkNkbM7z/TXju5BRvsnFdV7998OvD/9rrgz/IwZ+NJHw14dORllkEYX0 T+0gMmbEj/fvshpbVvD8FGHyw1C1Iypf/m2/FDLKOzCNGkLG5vd/mrPrB1HmbQxrq8K/yyoc cZp+by8rZZ1RW3X0YSKjsO9dFFPkQCGrdrprRlGZ81vUY3ZVO8gI27TViN/MJvqkq9XuTuGi VmftniEyggopo+LGtpKdMn5c++Hn/wcSoppsCDAmZwAAAABJRU5ErkJggg== --------------070103050406070202030102-- From - Sun Feb 23 17:04:04 2003 X-UIDL: 3df25b31000009bb X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1NG42o3026187 for ; Sun, 23 Feb 2003 17:04:02 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1NG42u23893 for ; Sun, 23 Feb 2003 17:04:02 +0100 (MET) Received: from mta02-svc.ntlworld.com(62.253.162.42) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA04aGQU; Sun, 23 Feb 03 17:04:01 +0100 Received: from bunyip ([213.105.123.90]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030223160019.ROJA4529.mta02-svc.ntlworld.com@bunyip> for ; Sun, 23 Feb 2003 16:00:19 +0000 Reply-To: From: "Tony Linde" To: "'voql'" Subject: RE: Query message format Date: Sun, 23 Feb 2003 16:00:20 -0000 Organization: University of Leicester Message-ID: <004c01c2db54$aab48bd0$0e01a8c0@bunyip> 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.3416 In-Reply-To: <001201c2d72a$5b81d9b0$b524d28f@bunyip> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: > In my mind, if you want a message to be easily converted into another > form, it should be in XML. I just noticed the following in an XQuery doc from an IBM Systems Jounal article: "It is an objective of the XML Query Working Group to define two syntaxes for XQuery: one that is expressed in XML, and one that is optimized for human writing and understanding." Ref: http://www.research.ibm.com/journal/sj/414/chamberlin.pdf (D. Chamberlin, IBM SYSTEMS JOURNAL, VOL 41, NO 4, 2002, p598) The author, Don Chamberlin, 'serves as one of IBM's representatives to the W3C XML Query Working Group and as an editor of the XQuery language specification.' So, XQuery does (or will - certainly for VO timescales) meet one of Ray's criteria. Cheers, Tony. > -----Original Message----- > From: Ray Plante [mailto:rplante@poplar.ncsa.uiuc.edu] > Sent: 17 February 2003 22:40 > To: Tony Linde > Cc: 'Registry_Ivoa_List' > Subject: Re: Query message format > > ... From - Sun Feb 23 17:49:04 2003 X-UIDL: 3df25b31000009bc X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1NGlqo3029921 for ; Sun, 23 Feb 2003 17:47:52 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1NGlqi24781 for ; Sun, 23 Feb 2003 17:47:52 +0100 (MET) Received: from mta02-svc.ntlworld.com(62.253.162.42) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAmfaGzW; Sun, 23 Feb 03 17:47:51 +0100 Received: from bunyip ([213.105.123.90]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030223164411.SWOX4529.mta02-svc.ntlworld.com@bunyip> for ; Sun, 23 Feb 2003 16:44:11 +0000 Reply-To: From: "Tony Linde" To: Subject: RE: a high level language Date: Sun, 23 Feb 2003 16:44:11 -0000 Organization: University of Leicester Message-ID: <004f01c2db5a$cb01af20$0e01a8c0@bunyip> 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.3416 In-Reply-To: <3E56B69E.4080809@gsfc.nasa.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: > Here is a first cut at a highest level astronomical query language. This looks good, Ed. I'm not sure I could get my head around it all based just on the sample query and schema - I'll wait for 'further annotation of the schema' before commenting on too much. One general issue that perhaps needs to be addressed is the distinction between the query and the workflow construction. I imagine the workflow as a description of all the steps that are required to get the user a final result. These steps would include queries, object selection, data analysis, re-querying, visualisation etc - everything an astronomer does now in the course of getting a result. At one extreme, each step that the user inserts into the workflow must address only one service (eg querying a single data source) and it is up to the user to construct data merges, sub-selects based on previous queries etc. thus building up the complete workflow. At the other extreme, the entire workflow could be seen as a 'query', ie everything needed to produce the user's result. In the middle, one could imagine that a single step is defined as something which produces a useful (possibly retained) result (though not, perhaps, the final result), so could include queries, sub-queries etc but all automated and with no saving of intermediate data. Likewise, functional steps where data is analysed or visualised would also be single steps. Where do you think the distinction lies with your VOQL? (Being still a programmer at heart, the first option is certainly the easiest from the p.o.v. of building a workflow GUI - and will probably be the first to be implemented.) I would guess that VOQL is *only* a query language, so only acts on data sources, though mediated by the Web Service fronting the data centre or data source itself. Do we also need a VOWL: VO Workflow Language? (Perhaps not, will a workflow need to be exchanged between job control services?) How far do we want to push the VOQL towards a VOWL? Cheers, Tony. > -----Original Message----- > From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] > Sent: 21 February 2003 23:31 > To: voql@ivoa.net > Cc: Cynthia Cheung > Subject: a high level language > > > > Here is a first cut at a highest level astronomical query language. > This is going to need some introduction so you can begin to > see where > we are going with this. The goal here is to create an XML > language that > can capture the scientific spirit of the NVO use cases. This requires > using object/property relationships and therefore builds on many of > concepts in AMASE such as the idea that the key items are the > astronomical object and their classes. The scientist should > be able to > build up a query from a form or gui. An integrator service then > analyses the voql and breaks it down to its atomic parts. The > integrator checks the metadata registries to see which atomic > parts go > to which data centers. The integrator checks with the WSDL > documents to > create queries properly for each data center. I would imagine > that XML > Query will play a big role here. But, XML Query is meant for > query on a > specific XML database of well known schema, and is not appropriate at > the distributed level. We can of course make voql look quite XML > Queryish. When the responses come back, the integrator applies the > logic functions to see which objects have all of the required > data. It > may send some results out to services and finally it forms the return > tables applying the requested statistics. > > Thus, we need to get our metadata registries into shape so that this > ontological type query can be useful (such as "these galaxies are > members of this cluster", "these layers are regions of > stars", "FRII is > a subclass of radio-galaxy" etc). And, we need to develop and > intelligent integrator. But, if Web Services are properly > used, atleast > the interactions between the services and the integrator will > be quite > straightforward. The recent development of WS > at CDS, ADECC and the paper by Brian Thomas and myself are a good > beginning down this road. But now I am starting the road from the > scientists into the VO. > > A request has any number of "constraints" which specifies an > object/@class and a number of properties (or properties > within a range > of values). As it is discovered that objects of this class are known > the values and errors are saved to variables. These variables can be > used in the following "constraints". Services may be used along the > way, and we can only enter an element named "service" which allow for > arbitrary attributes at this time. Finally, a "result" > consists of a > table where we specify which variables fall into each field. We may > also do statistics on the variable and enter the results into > that field. > > The schema does an xs:include on the Coords.xsd that Arnold > Rots worked > on. You can tell those elements because they begin with a capital > letter. I did have to do some liberal editing on Coords to > make it work > well in this. > > Further annotation of the schema is coming. > > Notes on use case 1: > Specifically this request says: > Constrain results to clusters of galaxies with ROSAT X-ray > measurements and images and at least one cataloged galaxy > member. It must also have a name, RA, and DE (ie. The > galaxies MAY also have a > ROSAT X-ray flux (optional > properties are in elements). The $variables do not set > a range on the > required measurement. The variable is set by the database. > For a variable lists use @. > > Ed > > From - Sun Feb 23 23:04:05 2003 X-UIDL: 3df25b31000009c0 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1NM4Lo3028500 for ; Sun, 23 Feb 2003 23:04:21 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1NM4Lp03143 for ; Sun, 23 Feb 2003 23:04:21 +0100 (MET) Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAr9aWig; Sun, 23 Feb 03 23:04:20 +0100 Received: (from borne@localhost) by rings.gsfc.nasa.gov (8.9.3/8.9.3) id RAA27897; Sun, 23 Feb 2003 17:00:32 -0500 (EST) From: Kirk Borne Message-Id: <200302232200.RAA27897@rings.gsfc.nasa.gov> Subject: Re: a high level language To: ael@star.le.ac.uk Date: Sun, 23 Feb 2003 17:00:32 -0500 (EST) Cc: voql@ivoa.net In-Reply-To: <004f01c2db5a$cb01af20$0e01a8c0@bunyip> from "Tony Linde" at Feb 23, 2003 04:44:11 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Tony. Just a few comments on your message... In working with Ed Shaya and Brian Thomas on this voql (VO Query Language), I believe that the driving concept is that this voql will capture a single user query to the VO. It is not intended to capture the entire research process: query, retrieve, analyze, refine query, resubmit, re-analyze, etc. i.e, it is not intended to capture the one extreme workflow case that you mentioned. That's why we still need humans in the loop. On the other hand, voql captures far more than a one-step-at-a-time query. For example, the voql (XML-ized user query) should be able to capture this science query: "give me optical emission line lists for IR-luminous AGN that were Xray-selected". This query involves multi-wavelength data and multi-modal data (catalogs, spectra), and thereby the query must be parsed and distributed to appropriate data centers and maybe the data need to be shipped to some service (e.g., to generate line lists from optical spectra). This relatively simple query is already complex enough and distributed enough that a standard query format (hence XML) is certainly needed. Thus, voql does more than the other extreme case that you mentioned. The user may subsequently choose to refine the query after seeing the results, or filter the results, or expand the query, or a million other things. Then a new voql will be generated to handle each subsequent query. The workflow (or query plan) is handled at the "integrator" level, by (what I would call) a query manager, which not only dispenses pieces of the voql to the relevant data centers and/or service providers, but it also integrates and fuses the returning query results. VOQL is a standardized language to capture scientist's queries to the distributed heterogeneous collections that comprise the VO. If all data collections were identical (schema, interfaces, metadata), then a VOQL would not be needed. XML Query and SQL would suffice in such instances, but that is not the world in which our data and information resources and services live. Ed's initial voql concept is able to capture complex and simple queries. The apparent simplicity of the schema belies the complexity that it can support, and vice versa. - Kirk Borne > From mdolensk@eso.org Sun Feb 23 11:48 EST 2003 > Reply-To: > From: "Tony Linde" > To: > Subject: RE: a high level language > Date: Sun, 23 Feb 2003 16:44:11 -0000 > > > Here is a first cut at a highest level astronomical query language. > > This looks good, Ed. I'm not sure I could get my head around it all > based just on the sample query and schema - I'll wait for 'further > annotation of the schema' before commenting on too much. > > One general issue that perhaps needs to be addressed is the distinction > between the query and the workflow construction. > > I imagine the workflow as a description of all the steps that are > required to get the user a final result. These steps would include > queries, object selection, data analysis, re-querying, visualisation etc > - everything an astronomer does now in the course of getting a result. > > At one extreme, each step that the user inserts into the workflow must > address only one service (eg querying a single data source) and it is up > to the user to construct data merges, sub-selects based on previous > queries etc. thus building up the complete workflow. > > At the other extreme, the entire workflow could be seen as a 'query', ie > everything needed to produce the user's result. > > In the middle, one could imagine that a single step is defined as > something which produces a useful (possibly retained) result (though > not, perhaps, the final result), so could include queries, sub-queries > etc but all automated and with no saving of intermediate data. Likewise, > functional steps where data is analysed or visualised would also be > single steps. > > Where do you think the distinction lies with your VOQL? > > (Being still a programmer at heart, the first option is certainly the > easiest from the p.o.v. of building a workflow GUI - and will probably > be the first to be implemented.) > > I would guess that VOQL is *only* a query language, so only acts on data > sources, though mediated by the Web Service fronting the data centre or > data source itself. Do we also need a VOWL: VO Workflow Language? > (Perhaps not, will a workflow need to be exchanged between job control > services?) > > How far do we want to push the VOQL towards a VOWL? > > Cheers, > Tony. > > > -----Original Message----- > > From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] > > Sent: 21 February 2003 23:31 > > To: voql@ivoa.net > > Cc: Cynthia Cheung > > Subject: a high level language > > > > > > > > Here is a first cut at a highest level astronomical query language. > > This is going to need some introduction so you can begin to > > see where > > we are going with this. The goal here is to create an XML > > language that > > can capture the scientific spirit of the NVO use cases. This requires > > using object/property relationships and therefore builds on many of > > concepts in AMASE such as the idea that the key items are the > > astronomical object and their classes. The scientist should > > be able to > > build up a query from a form or gui. An integrator service then > > analyses the voql and breaks it down to its atomic parts. The > > integrator checks the metadata registries to see which atomic > > parts go > > to which data centers. The integrator checks with the WSDL > > documents to > > create queries properly for each data center. I would imagine > > that XML > > Query will play a big role here. But, XML Query is meant for > > query on a > > specific XML database of well known schema, and is not appropriate at > > the distributed level. We can of course make voql look quite XML > > Queryish. When the responses come back, the integrator applies the > > logic functions to see which objects have all of the required > > data. It > > may send some results out to services and finally it forms the return > > tables applying the requested statistics. > > > > Thus, we need to get our metadata registries into shape so that this > > ontological type query can be useful (such as "these galaxies are > > members of this cluster", "these layers are regions of > > stars", "FRII is > > a subclass of radio-galaxy" etc). And, we need to develop and > > intelligent integrator. But, if Web Services are properly > > used, atleast > > the interactions between the services and the integrator will > > be quite > > straightforward. The recent development of WS > > at CDS, ADECC and the paper by Brian Thomas and myself are a good > > beginning down this road. But now I am starting the road from the > > scientists into the VO. > > > > A request has any number of "constraints" which specifies an > > object/@class and a number of properties (or properties > > within a range > > of values). As it is discovered that objects of this class are known > > the values and errors are saved to variables. These variables can be > > used in the following "constraints". Services may be used along the > > way, and we can only enter an element named "service" which allow for > > arbitrary attributes at this time. Finally, a "result" > > consists of a > > table where we specify which variables fall into each field. We may > > also do statistics on the variable and enter the results into > > that field. > > > > The schema does an xs:include on the Coords.xsd that Arnold > > Rots worked > > on. You can tell those elements because they begin with a capital > > letter. I did have to do some liberal editing on Coords to > > make it work > > well in this. > > > > Further annotation of the schema is coming. > > > > Notes on use case 1: > > Specifically this request says: > > Constrain results to clusters of galaxies with ROSAT X-ray > > measurements and images and at least one cataloged galaxy > > member. It must also have a name, RA, and DE (ie. The > > galaxies MAY also have a > > ROSAT X-ray flux (optional > > properties are in elements). The $variables do not set > > a range on the > > required measurement. The variable is set by the database. > > For a variable lists use @. > > > > Ed From - Mon Feb 24 10:49:06 2003 X-UIDL: 3df25b31000009c5 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1O9kMlh028943 for ; Mon, 24 Feb 2003 10:46:23 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1O9kMW01877 for ; Mon, 24 Feb 2003 10:46:22 +0100 (MET) Received: from ntp2c.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAmEaiQd; Mon, 24 Feb 03 10:46:21 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by artemis.le.ac.uk with smtp (Exim 3.16 #1) id 18nF87-0002Bo-00 for voql@ivoa.net; Mon, 24 Feb 2003 09:42:35 +0000 Received: (qmail 18311 invoked from network); 24 Feb 2003 09:42:57 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 24 Feb 2003 09:42:57 -0000 Reply-To: From: "Tony Linde" To: Subject: RE: a high level language Date: Mon, 24 Feb 2003 09:42:34 -0000 Organization: University of Leicester Message-ID: <000a01c2dbe9$0f221530$b524d28f@bunyip> 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.3416 In-Reply-To: <200302232200.RAA27897@rings.gsfc.nasa.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Kirk, Thanks for the reply. > This query involves > multi-wavelength data and multi-modal data (catalogs, spectra), and > thereby the query must be parsed and distributed to > appropriate data centers and maybe the data need to be > shipped to some service (e.g., to generate line lists from > optical spectra). This is what I assumed from Ed & Brian's document and why I raised the question. I can see that a *query* language might cover more than a simple single-dataset query, eg selecting from a join of distributed datasets with sub-selects etc. - the sort of thing you can do at the moment using SQL on the more advanced databases (though without the distributed bit). However, when it comes to shipping intermediate data to another service for analysis, reduction etc., I would consider this to be *workflow*, requiring a separate description using a workflow language (as in the commercial world with the recent development of BPEL4WS). > VOQL is a standardized language to capture scientist's > queries to the distributed heterogeneous collections that > comprise the VO. There I would agree. But the VO comprises more than data services, it includes functional services such as those to 'generate line lists'. Pushing the results of a query to such services, or using the results of a query in another, later, query amount to workflow construction. There is a danger that, in trying to combine queries and workflow in a single language, we will overcomplicate the matter and reduce the chance of using or extending existing efforts in the development of query and workflow languages. Cheers, Tony. > -----Original Message----- > From: Kirk Borne [mailto:borne@rings.gsfc.nasa.gov] > Sent: 23 February 2003 22:01 > To: ael@star.le.ac.uk > Cc: voql@ivoa.net > Subject: Re: a high level language > > ... From - Mon Feb 24 16:34:06 2003 X-UIDL: 3df25b31000009d1 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1OFOHDp022847 for ; Mon, 24 Feb 2003 16:32:48 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OEEL020115 for ; Mon, 24 Feb 2003 15:14:21 +0100 (MET) Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA4_aisN; Mon, 24 Feb 03 15:14:20 +0100 Received: from rings.gsfc.nasa.gov (rings.gsfc.nasa.gov [128.183.190.139]) by rings.gsfc.nasa.gov (8.9.3/8.9.3) with SMTP id JAA28939; Mon, 24 Feb 2003 09:10:33 -0500 (EST) Message-Id: <200302241410.JAA28939@rings.gsfc.nasa.gov> Date: Mon, 24 Feb 2003 09:10:33 -0500 (EST) From: Kirk Borne Reply-To: Kirk Borne Subject: RE: a high level language To: voql@ivoa.net, ael@star.le.ac.uk MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JZGZLlTnh6Q4Dwkp5luBtg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Tony: thanks for clarifying distinctions between workflow and query, and between data services and functional services. This is in fact a distinction that Ed, Brian, and I discussed, but somehow I mangled it in my example. It is perhaps appropriate and prudent therefore to keep those "functional" workflow actions separate from the VOQL's query actions. - Kirk > From: "Tony Linde" > To: > Subject: RE: a high level language > Date: Mon, 24 Feb 2003 09:42:34 -0000 > > Hi Kirk, > > Thanks for the reply. > > > This query involves > > multi-wavelength data and multi-modal data (catalogs, spectra), and > > thereby the query must be parsed and distributed to > > appropriate data centers and maybe the data need to be > > shipped to some service (e.g., to generate line lists from > > optical spectra). > > This is what I assumed from Ed & Brian's document and why I raised the > question. I can see that a *query* language might cover more than a > simple single-dataset query, eg selecting from a join of distributed > datasets with sub-selects etc. - the sort of thing you can do at the > moment using SQL on the more advanced databases (though without the > distributed bit). > > However, when it comes to shipping intermediate data to another service > for analysis, reduction etc., I would consider this to be *workflow*, > requiring a separate description using a workflow language (as in the > commercial world with the recent development of BPEL4WS). > > > VOQL is a standardized language to capture scientist's > > queries to the distributed heterogeneous collections that > > comprise the VO. > > There I would agree. But the VO comprises more than data services, it > includes functional services such as those to 'generate line lists'. > Pushing the results of a query to such services, or using the results of > a query in another, later, query amount to workflow construction. > > There is a danger that, in trying to combine queries and workflow in a > single language, we will overcomplicate the matter and reduce the chance > of using or extending existing efforts in the development of query and > workflow languages. > > Cheers, > Tony. > > > -----Original Message----- > > From: Kirk Borne [mailto:borne@rings.gsfc.nasa.gov] > > Sent: 23 February 2003 22:01 > > To: ael@star.le.ac.uk > > Cc: voql@ivoa.net > > Subject: Re: a high level language > > > > ... +------------------------------------+-------------------------------------+ | Dr. Kirk D. Borne | mailto:Kirk.Borne@gsfc.nasa.gov | | Institute for Science & Technology, Raytheon (IST@R) | | NASA Goddard Space Flight Center | | | Astrophysics Data Facility | Phone: 301-286-0696 | | Code 631 | or 301-286-2772:Kathy Starling | | Greenbelt, MD 20771 | FAX: 301-286-1771 | +------------------------------------+-------------------------------------+ US Virtual Observatory: http://us-vo.org/ Staff page: http://rings.gsfc.nasa.gov/~borne/bio_borne_kirk.html From - Mon Feb 24 21:09:07 2003 X-UIDL: 3df25b31000009e2 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1OK7JCx018428 for ; Mon, 24 Feb 2003 21:07:20 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OK7Ji08579 for ; Mon, 24 Feb 2003 21:07:19 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAPyaqWq; Mon, 24 Feb 03 21:07:18 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1OK6Fle030337 for ; Mon, 24 Feb 2003 15:06:15 -0500 Message-ID: <3E5A7B17.5000403@gsfc.nasa.gov> Date: Mon, 24 Feb 2003 15:05:43 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: voql@ivoa.net Subject: Re: a high level language References: <200302241410.JAA28939@rings.gsfc.nasa.gov> In-Reply-To: <200302241410.JAA28939@rings.gsfc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: I just want to reiterate that I think VOQL should be a means for the astronomer to clearly specify what astronomical knowledge he/she wants. It should not require the astronomer to know how data is arranged at each of the data centers, nor all of the steps required. Astronomical data is held in a bewildering assortment of ways. There are object oriented data centers (IPAC, CDS and AMASE), there are thousands of catalogs at CDS each in their own eccentric logical arrangement (yes, they are all in a similar numeric format, but each is ontologically unique), object-relational databases, XML databases (GSFC), log entry observations, and into the future one can expect this to only get more complex. The average astronomer can not be expected to be able to properly layout an optimal workflow. The astronomer thinks "I am interested in objects with such and such properties" and VOQL should allow a description of these constraints, even if they are quite complex or detailed (eg. red-giants with white dwarf companions and proper motions greater than x and variable by less than y%). Additionally, the astronomer says, "while selecting objects that fit this criterion, keep track of the following other properties of such objects." It is sobering how quickly the detailed work flow for such queries gets beyond what humans can reliably handle. The astronomer doesn't know if it is better to first get index numbers of records that fit the criteria and then later extract additional properties or to do both at the same time. Are we looking through tables or querying object databases? Are we looking at tables of red-giants or white dwarfs or proper motions or binary stars? Are there tables specifically of variability or do we need to look at photometry catalogs and look for time variations? How do we do a many way cross-correlation, because the intermediate return has some tables with some properties and other tables have other properties although some tables have a few of each? Etc. So now the detractors say, well if you don't know how to do this, how do you expect the machine to know better? The answer is that computers simply are better at the restrictive problem here and repetitive task breakdown and assignment. To be sure, it will take us some time to find the appropriate set of algorithms and "workflow" language to automate this. But once done it should evolve quite slowly. Next the detractor says, "I can break your example down easily. Go to an all-sky binary star catalogs and get lists of binaries with red-giant/white dwarf members, then send the list of ra/dec positions to a proper motion resource and have it delete candidates with low proper motions. Then send that list to a variable star resource and have it delete highly variable ones. What is so hard about that, I can set up the entire workflow for that in about 20 minutes?" First of all, I agree that the user should indeed have access to individual resources in this simple manner. And this may get the user some objects that fulfill the criteria. But what if the user needs a more thorough search. Let's say that it is not easy to see white dwarfs around red-giants, so one is likely to get only a few hits from the general catalogs. Inevitably a more in depth search is required. There are many useful sources for each of the desired properties, most do not have all sky coverage, so coverage maps need to be examined for proper overlap. Now we are talking about matching with SLOAN and 2-MASS and PSS and a few dozen other cataloged data sources, perhaps some were published in the last few months. The workflow development rapidly grows to a couple of days. "This will be ruinous," says the conservative. "How is a machine to know when enough is enough? Perhaps it will attempt photometery on all objects on each and every image of the sky ever taken in a desperate attempt to answer your query as thoroghly as technologically possible?" Yes, this is a concern. On the other hand, maybe that is what the user has in mind. For requests that have options that would take more than a few minutes the user should first be sent a high level summary of the possible paths to satisfy the request and estimates of the time required. The user then selects one of these options before any such action. So, the concern is, and always has been, what prevents a single user from tying up vast resources too often? There must be time alotments or financial costs to put limits on what users do. Admittedly, this level of automated service will not even begin to come together before the final year of the NVO grant. But it is useful to carefully outline and agree on the properties of the (pen)ultimate user interface before beginning to develop a system. The alternative is everyone marching in a different direction because each sees a different end goal. Back to annotation. Ed Kirk Borne wrote: >Tony: thanks for clarifying distinctions between workflow and query, >and between data services and functional services. This is in fact >a distinction that Ed, Brian, and I discussed, but somehow I mangled >it in my example. It is perhaps appropriate and prudent therefore >to keep those "functional" workflow actions separate from the VOQL's >query actions. > >- Kirk > > > > >>From: "Tony Linde" >>To: >>Subject: RE: a high level language >>Date: Mon, 24 Feb 2003 09:42:34 -0000 >> >>Hi Kirk, >> >>Thanks for the reply. >> >> >> >>>This query involves >>>multi-wavelength data and multi-modal data (catalogs, spectra), and >>>thereby the query must be parsed and distributed to >>>appropriate data centers and maybe the data need to be >>>shipped to some service (e.g., to generate line lists from >>>optical spectra). >>> >>> >>This is what I assumed from Ed & Brian's document and why I raised the >>question. I can see that a *query* language might cover more than a >>simple single-dataset query, eg selecting from a join of distributed >>datasets with sub-selects etc. - the sort of thing you can do at the >>moment using SQL on the more advanced databases (though without the >>distributed bit). >> >>However, when it comes to shipping intermediate data to another service >>for analysis, reduction etc., I would consider this to be *workflow*, >>requiring a separate description using a workflow language (as in the >>commercial world with the recent development of BPEL4WS). >> >> >> >>>VOQL is a standardized language to capture scientist's >>>queries to the distributed heterogeneous collections that >>>comprise the VO. >>> >>> >>There I would agree. But the VO comprises more than data services, it >>includes functional services such as those to 'generate line lists'. >>Pushing the results of a query to such services, or using the results of >>a query in another, later, query amount to workflow construction. >> >>There is a danger that, in trying to combine queries and workflow in a >>single language, we will overcomplicate the matter and reduce the chance >>of using or extending existing efforts in the development of query and >>workflow languages. >> >>Cheers, >>Tony. >> >> >> >>>-----Original Message----- >>>From: Kirk Borne [mailto:borne@rings.gsfc.nasa.gov] >>>Sent: 23 February 2003 22:01 >>>To: ael@star.le.ac.uk >>>Cc: voql@ivoa.net >>>Subject: Re: a high level language >>> >>>... >>> >>> > >+------------------------------------+-------------------------------------+ >| Dr. Kirk D. Borne | mailto:Kirk.Borne@gsfc.nasa.gov | >| Institute for Science & Technology, Raytheon (IST@R) | >| NASA Goddard Space Flight Center | | >| Astrophysics Data Facility | Phone: 301-286-0696 | >| Code 631 | or 301-286-2772:Kathy Starling | >| Greenbelt, MD 20771 | FAX: 301-286-1771 | >+------------------------------------+-------------------------------------+ > US Virtual Observatory: http://us-vo.org/ > Staff page: http://rings.gsfc.nasa.gov/~borne/bio_borne_kirk.html > > > From - Mon Feb 24 21:29:07 2003 X-UIDL: 3df25b31000009e3 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1OKTkCx023305 for ; Mon, 24 Feb 2003 21:29:46 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OKTja10336 for ; Mon, 24 Feb 2003 21:29:45 +0100 (MET) Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA1fa4lu; Mon, 24 Feb 03 21:29:44 +0100 Received: from rings.gsfc.nasa.gov (rings.gsfc.nasa.gov [128.183.190.139]) by rings.gsfc.nasa.gov (8.9.3/8.9.3) with SMTP id PAA01444; Mon, 24 Feb 2003 15:25:59 -0500 (EST) Message-Id: <200302242025.PAA01444@rings.gsfc.nasa.gov> Date: Mon, 24 Feb 2003 15:25:59 -0500 (EST) From: Kirk Borne Reply-To: Kirk Borne Subject: Re: a high level language To: voql@ivoa.net Cc: Kirk.Borne@gsfc.nasa.gov, edward.j.shaya.1@gsfc.nasa.gov MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: M369o1XYLnXnWxGuJ9/vQg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Ed's comments elaborate on the rationale for a VO Query Language, but let's not forget the point ... VOQL is a language in a standard format (XML) for specifying queries to distributed heterogeneous astronomical information resources. How that gets wrapped by workflows or query management tools or query cost functions is all TBD and subject to much more discussion. As it stands, the VOQL schema that Ed circulated is a foundation (or building block) for all of that, in the same way that VOTable is a foundation for lots of other VO-related things. - Kirk > Date: Mon, 24 Feb 2003 15:05:43 -0500 > From: Ed Shaya > CC: voql@ivoa.net > Subject: Re: a high level language > > I just want to reiterate that I think VOQL should be a means for the > astronomer to clearly specify what astronomical knowledge he/she wants. > It should not require the astronomer to know how data is arranged at > each of the data centers, nor all of the steps required. Astronomical > data is held in a bewildering assortment of ways. There are object > oriented data centers (IPAC, CDS and AMASE), there are thousands of > catalogs at CDS each in their own eccentric logical arrangement (yes, > they are all in a similar numeric format, but each is ontologically > unique), object-relational databases, XML databases (GSFC), log entry > observations, and into the future one can expect this to only get more > complex. The average astronomer can not be expected to be able to > properly layout an optimal workflow. > > The astronomer thinks "I am interested in objects with such and such > properties" and VOQL should allow a description of these constraints, > even if they are quite complex or detailed (eg. red-giants with white > dwarf companions and proper motions greater than x and variable by less > than y%). Additionally, the astronomer says, "while selecting objects > that fit this criterion, keep track of the following other properties of > such objects." It is sobering how quickly the detailed work flow for > such queries gets beyond what humans can reliably handle. The > astronomer doesn't know if it is better to first get index numbers of > records that fit the criteria and then later extract additional > properties or to do both at the same time. Are we looking through > tables or querying object databases? Are we looking at tables of > red-giants or white dwarfs or proper motions or binary stars? Are there > tables specifically of variability or do we need to look at photometry > catalogs and look for time variations? How do we do a many way > cross-correlation, because the intermediate return has some tables with > some properties and other tables have other properties although some > tables have a few of each? Etc. > > So now the detractors say, well if you don't know how to do this, how do > you expect the machine to know better? The answer is that computers > simply are better at the restrictive problem here and repetitive task > breakdown and assignment. To be sure, it will take us some time to find > the appropriate set of algorithms and "workflow" language to automate > this. But once done it should evolve quite slowly. > > Next the detractor says, "I can break your example down easily. Go to > an all-sky binary star catalogs and get lists of binaries with > red-giant/white dwarf members, then send the list of ra/dec positions > to a proper motion resource and have it delete candidates with low > proper motions. Then send that list to a variable star resource and > have it delete highly variable ones. What is so hard about that, I can > set up the entire workflow for that in about 20 minutes?" > > First of all, I agree that the user should indeed have access to > individual resources in this simple manner. And this may get the user > some objects that fulfill the criteria. But what if the user needs a > more thorough search. Let's say that it is not easy to see white dwarfs > around red-giants, so one is likely to get only a few hits from the > general catalogs. Inevitably a more in depth search is required. There > are many useful sources for each of the desired properties, most do not > have all sky coverage, so coverage maps need to be examined for proper > overlap. Now we are talking about matching with SLOAN and 2-MASS and > PSS and a few dozen other cataloged data sources, perhaps some were > published in the last few months. The workflow development rapidly > grows to a couple of days. > > "This will be ruinous," says the conservative. "How is a machine to > know when enough is enough? Perhaps it will attempt photometery on all > objects on each and every image of the sky ever taken in a desperate > attempt to answer your query as thoroghly as technologically possible?" > Yes, this is a concern. On the other hand, maybe that is what the user > has in mind. For requests that have options that would take more than a > few minutes the user should first be sent a high level summary of the > possible paths to satisfy the request and estimates of the time > required. The user then selects one of these options before any such > action. So, the concern is, and always has been, what prevents a single > user from tying up vast resources too often? There must be time > alotments or financial costs to put limits on what users do. > > Admittedly, this level of automated service will not even begin to come > together before the final year of the NVO grant. But it is useful to > carefully outline and agree on the properties of the (pen)ultimate user > interface before beginning to develop a system. The alternative is > everyone marching in a different direction because each sees a different > end goal. > > Back to annotation. > > Ed > > > > > > Kirk Borne wrote: > > >Tony: thanks for clarifying distinctions between workflow and query, > >and between data services and functional services. This is in fact > >a distinction that Ed, Brian, and I discussed, but somehow I mangled > >it in my example. It is perhaps appropriate and prudent therefore > >to keep those "functional" workflow actions separate from the VOQL's > >query actions. > > > >- Kirk > > > > > > > > > >>From: "Tony Linde" > >>To: > >>Subject: RE: a high level language > >>Date: Mon, 24 Feb 2003 09:42:34 -0000 > >> > >>Hi Kirk, > >> > >>Thanks for the reply. > >> > >> > >> > >>>This query involves > >>>multi-wavelength data and multi-modal data (catalogs, spectra), and > >>>thereby the query must be parsed and distributed to > >>>appropriate data centers and maybe the data need to be > >>>shipped to some service (e.g., to generate line lists from > >>>optical spectra). > >>> > >>> > >>This is what I assumed from Ed & Brian's document and why I raised the > >>question. I can see that a *query* language might cover more than a > >>simple single-dataset query, eg selecting from a join of distributed > >>datasets with sub-selects etc. - the sort of thing you can do at the > >>moment using SQL on the more advanced databases (though without the > >>distributed bit). > >> > >>However, when it comes to shipping intermediate data to another service > >>for analysis, reduction etc., I would consider this to be *workflow*, > >>requiring a separate description using a workflow language (as in the > >>commercial world with the recent development of BPEL4WS). > >> > >> > >> > >>>VOQL is a standardized language to capture scientist's > >>>queries to the distributed heterogeneous collections that > >>>comprise the VO. > >>> > >>> > >>There I would agree. But the VO comprises more than data services, it > >>includes functional services such as those to 'generate line lists'. > >>Pushing the results of a query to such services, or using the results of > >>a query in another, later, query amount to workflow construction. > >> > >>There is a danger that, in trying to combine queries and workflow in a > >>single language, we will overcomplicate the matter and reduce the chance > >>of using or extending existing efforts in the development of query and > >>workflow languages. > >> > >>Cheers, > >>Tony. > >> > >> > >> > >>>-----Original Message----- > >>>From: Kirk Borne [mailto:borne@rings.gsfc.nasa.gov] > >>>Sent: 23 February 2003 22:01 > >>>To: ael@star.le.ac.uk > >>>Cc: voql@ivoa.net > >>>Subject: Re: a high level language > >>> > >>>... > >>> > >>> +------------------------------------+-------------------------------------+ | Dr. Kirk D. Borne | mailto:Kirk.Borne@gsfc.nasa.gov | | Institute for Science & Technology, Raytheon (IST@R) | | NASA Goddard Space Flight Center | | | Astrophysics Data Facility | Phone: 301-286-0696 | | Code 631 | or 301-286-2772:Kathy Starling | | Greenbelt, MD 20771 | FAX: 301-286-1771 | +------------------------------------+-------------------------------------+ US Virtual Observatory: http://us-vo.org/ Staff page: http://rings.gsfc.nasa.gov/~borne/bio_borne_kirk.html From - Mon Feb 24 22:04:07 2003 X-UIDL: 3df25b31000009e4 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1OKvbDX029034 for ; Mon, 24 Feb 2003 22:02:31 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OKbi210678 for ; Mon, 24 Feb 2003 21:37:44 +0100 (MET) Received: from nrcvicex1a.hia.nrc.ca(204.174.103.8) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAH8aO2u; Mon, 24 Feb 03 21:37:43 +0100 Received: from frodo (anim11sny35ia.bc.hsia.telus.net [216.232.81.76]) by nrcvicex1.hia.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1GCV8XYB; Mon, 24 Feb 2003 12:36:50 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Patrick Dowler Organization: National Research Council Canada To: voql@ivoa.net Subject: Re: a high level language Date: Mon, 24 Feb 2003 12:36:52 -0800 User-Agent: KMail/1.4.3 Cc: Ed Shaya References: <3E5A7B17.5000403@gsfc.nasa.gov> In-Reply-To: <3E5A7B17.5000403@gsfc.nasa.gov> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200302241236.52343.patrick.dowler@nrc-cnrc.gc.ca> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On February 24, 2003 12:05, Ed Shaya wrote: > I just want to reiterate that I think VOQL should be a means for the > > astronomer to clearly specify what astronomical knowledge he/she wants. > It should not require the astronomer to know how data is arranged at > each of the data centers, nor all of the steps required. This point cannot be over-emphasized. Storage data management by services/institutions will vary alot and it must remain a hidden implementation detail - with plenty of freedom on the part of a service to implement in a suitable fashion. > > The astronomer thinks "I am interested in objects with such and such > properties" and VOQL should allow a description of these constraints, With the ention of the word "constraints", I'll jump in here: Our work at CADC and some of my past work has been in the area of constraint systems. The great advantage of constraint-based systems is that they do not, in the general case, specify a query system per se. The same constraint system can be applied as a query, a processing (typically filtering) step, a theorem-prover, etc. Since VOQL is still young, I suggest that instead of inventing a "query language" we will be better servced by a constraint toolkit. The advantages are many: - easy to convert to a query - easy to apply as a processing or filtering step - easy to build a UI that allows users to construct constraint systems since constraints are "things" to be created and manipulated - easy (well, easier :-) validate Although I don't go crazy for this sort of thing: - easy to serialize as XML (constraints are things with simple parent-child relations between them and the expressions, operators, and constants in use) My 2c (although I guess Canadians should up that to 3c), -- Patrick Dowler Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) From - Tue Feb 25 08:34:08 2003 X-UIDL: 3df25b31000009f1 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1P7TWZv017783 for ; Tue, 25 Feb 2003 08:32:34 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OKhad10874 for ; Mon, 24 Feb 2003 21:43:36 +0100 (MET) Received: from nrcvicex1a.hia.nrc.ca(204.174.103.8) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAT7aiov; Mon, 24 Feb 03 21:43:35 +0100 Received: from frodo (anim11sny35ia.bc.hsia.telus.net [216.232.81.76]) by nrcvicex1.hia.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1GCV8XYG; Mon, 24 Feb 2003 12:42:42 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Patrick Dowler Organization: National Research Council Canada To: voql@ivoa.net Subject: Re: a high level language Date: Mon, 24 Feb 2003 12:42:44 -0800 User-Agent: KMail/1.4.3 References: <200302242025.PAA01444@rings.gsfc.nasa.gov> In-Reply-To: <200302242025.PAA01444@rings.gsfc.nasa.gov> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> Status: On February 24, 2003 12:25, Kirk Borne wrote: > Ed's comments elaborate on the rationale for a VO Query Language, > but let's not forget the point ... VOQL is a language in a standard > format (XML) for specifying queries to distributed heterogeneous > astronomical information resources. Here I would like to strongly DISAGREE. There is no need to a-priori define VOQL in terms of XML. XML is a serialization format that one uses to exchange structured text. It is a huge mistake to pre-suppose that anything is fundamentally an XML thing. It is an even bigger mistake to "design with XML". I am not saying XML will or should not be part of the solution; it should not be goal... I suppose this comment could be addressed to every IVOA mailing list, but I'll leave it here for now. -- Patrick Dowler Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) From - Tue Feb 25 03:49:08 2003 X-UIDL: 3df25b31000009e9 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1P2iaqC017790 for ; Tue, 25 Feb 2003 03:48:42 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OLjAK13098 for ; Mon, 24 Feb 2003 22:45:10 +0100 (MET) Received: from mta02-svc.ntlworld.com(62.253.162.42) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA16a4Kz; Mon, 24 Feb 03 22:45:10 +0100 Received: from bunyip ([213.105.123.90]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030224214123.WBHY4529.mta02-svc.ntlworld.com@bunyip> for ; Mon, 24 Feb 2003 21:41:23 +0000 Reply-To: From: "Tony Linde" To: Subject: RE: a high level language Date: Mon, 24 Feb 2003 21:41:23 -0000 Organization: University of Leicester Message-ID: <005901c2dc4d$79c21430$b524d28f@bunyip> 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.3416 In-Reply-To: <3E5A7B17.5000403@gsfc.nasa.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Ed, Thanks for that - it succinctly explains what you eventually want. Unfortunately it is well beyond current capabilities. This should not place me in your 'detractor' class - I want the same thing - it is what attracted me to the VO projects in the first place - recognition of the possibilities. To put it into context, take Google, one of the best search engines ever - how often do you get exactly and only what you wanted to find? > red-giants with white > dwarf companions and proper motions greater than x and > variable by less than y%) That's a great example. Every word - nouns, adjectives, conjunctions, values - is problematic. Rather than a query language or a workflow language, what you're after is a natural language processor backed up by astronomical knowledge and an ability to learn. Excellent! Let's go for it. BUT While we're researching the ability to do this, we need to get stuck into building the early releases of the VO. And for that we need to take a few steps back (a mile or two :) and look at what we can achieve now. A VOQL that can be built and interpreted now. Cheers, Tony. > -----Original Message----- > From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] > Sent: 24 February 2003 20:06 > Cc: voql@ivoa.net > Subject: Re: a high level language > > > > I just want to reiterate that I think VOQL should be a > means for the > astronomer to clearly specify what astronomical knowledge > he/she wants. > It should not require the astronomer to know how data is arranged at > each of the data centers, nor all of the steps required. > Astronomical > data is held in a bewildering assortment of ways. There are object > oriented data centers (IPAC, CDS and AMASE), there are thousands of > catalogs at CDS each in their own eccentric logical arrangement (yes, > they are all in a similar numeric format, but each is ontologically > unique), object-relational databases, XML databases (GSFC), > log entry > observations, and into the future one can expect this to only > get more > complex. The average astronomer can not be expected to be able to > properly layout an optimal workflow. > > The astronomer thinks "I am interested in objects with such and such > properties" and VOQL should allow a description of these constraints, > even if they are quite complex or detailed (eg. red-giants > with white > dwarf companions and proper motions greater than x and > variable by less > than y%). Additionally, the astronomer says, "while > selecting objects > that fit this criterion, keep track of the following other > properties of > such objects." It is sobering how quickly the detailed work flow for > such queries gets beyond what humans can reliably handle. The > astronomer doesn't know if it is better to first get index numbers of > records that fit the criteria and then later extract additional > properties or to do both at the same time. Are we looking through > tables or querying object databases? Are we looking at tables of > red-giants or white dwarfs or proper motions or binary stars? > Are there > tables specifically of variability or do we need to look at > photometry > catalogs and look for time variations? How do we do a many way > cross-correlation, because the intermediate return has some > tables with > some properties and other tables have other properties although some > tables have a few of each? Etc. > > So now the detractors say, well if you don't know how to do > this, how do > you expect the machine to know better? The answer is that computers > simply are better at the restrictive problem here and repetitive task > breakdown and assignment. To be sure, it will take us some > time to find > the appropriate set of algorithms and "workflow" language to automate > this. But once done it should evolve quite slowly. > > Next the detractor says, "I can break your example down > easily. Go to > an all-sky binary star catalogs and get lists of binaries with > red-giant/white dwarf members, then send the list of ra/dec > positions > to a proper motion resource and have it delete candidates with low > proper motions. Then send that list to a variable star resource and > have it delete highly variable ones. What is so hard about > that, I can > set up the entire workflow for that in about 20 minutes?" > > First of all, I agree that the user should indeed have access to > individual resources in this simple manner. And this may get > the user > some objects that fulfill the criteria. But what if the user needs a > more thorough search. Let's say that it is not easy to see > white dwarfs > around red-giants, so one is likely to get only a few hits from the > general catalogs. Inevitably a more in depth search is > required. There > are many useful sources for each of the desired properties, > most do not > have all sky coverage, so coverage maps need to be examined > for proper > overlap. Now we are talking about matching with SLOAN and > 2-MASS and > PSS and a few dozen other cataloged data sources, perhaps some were > published in the last few months. The workflow development rapidly > grows to a couple of days. > > "This will be ruinous," says the conservative. "How is a machine to > know when enough is enough? Perhaps it will attempt > photometery on all > objects on each and every image of the sky ever taken in a desperate > attempt to answer your query as thoroghly as technologically > possible?" > Yes, this is a concern. On the other hand, maybe that is > what the user > has in mind. For requests that have options that would take > more than a > few minutes the user should first be sent a high level summary of the > possible paths to satisfy the request and estimates of the time > required. The user then selects one of these options before any such > action. So, the concern is, and always has been, what > prevents a single > user from tying up vast resources too often? There must be time > alotments or financial costs to put limits on what users do. > > Admittedly, this level of automated service will not even > begin to come > together before the final year of the NVO grant. But it is useful to > carefully outline and agree on the properties of the > (pen)ultimate user > interface before beginning to develop a system. The alternative is > everyone marching in a different direction because each sees > a different > end goal. > > Back to annotation. > > Ed > > > > > > Kirk Borne wrote: > > >Tony: thanks for clarifying distinctions between workflow > and query, > >and between data services and functional services. This is > in fact a > >distinction that Ed, Brian, and I discussed, but somehow I > mangled it > >in my example. It is perhaps appropriate and prudent > therefore to keep > >those "functional" workflow actions separate from the VOQL's query > >actions. > > > >- Kirk > > > > > > > > > >>From: "Tony Linde" > >>To: > >>Subject: RE: a high level language > >>Date: Mon, 24 Feb 2003 09:42:34 -0000 > >> > >>Hi Kirk, > >> > >>Thanks for the reply. > >> > >> > >> > >>>This query involves > >>>multi-wavelength data and multi-modal data (catalogs, > spectra), and > >>>thereby the query must be parsed and distributed to > >>>appropriate data centers and maybe the data need to be > >>>shipped to some service (e.g., to generate line lists from > >>>optical spectra). > >>> > >>> > >>This is what I assumed from Ed & Brian's document and why I > raised the > >>question. I can see that a *query* language might cover more than a > >>simple single-dataset query, eg selecting from a join of > distributed > >>datasets with sub-selects etc. - the sort of thing you can > do at the > >>moment using SQL on the more advanced databases (though without the > >>distributed bit). > >> > >>However, when it comes to shipping intermediate data to another > >>service for analysis, reduction etc., I would consider this to be > >>*workflow*, requiring a separate description using a > workflow language > >>(as in the commercial world with the recent development of BPEL4WS). > >> > >> > >> > >>>VOQL is a standardized language to capture scientist's > >>>queries to the distributed heterogeneous collections that > >>>comprise the VO. > >>> > >>> > >>There I would agree. But the VO comprises more than data > services, it > >>includes functional services such as those to 'generate > line lists'. > >>Pushing the results of a query to such services, or using > the results > >>of a query in another, later, query amount to workflow construction. > >> > >>There is a danger that, in trying to combine queries and > workflow in a > >>single language, we will overcomplicate the matter and reduce the > >>chance of using or extending existing efforts in the development of > >>query and workflow languages. > >> > >>Cheers, > >>Tony. > >> > >> > >> > >>>-----Original Message----- > >>>From: Kirk Borne [mailto:borne@rings.gsfc.nasa.gov] > >>>Sent: 23 February 2003 22:01 > >>>To: ael@star.le.ac.uk > >>>Cc: voql@ivoa.net > >>>Subject: Re: a high level language > >>> > >>>... > >>> > >>> > > > >+------------------------------------+----------------------- > --------------+ > >| Dr. Kirk D. Borne | > mailto:Kirk.Borne@gsfc.nasa.gov | > >| Institute for > Science & Technology, Raytheon (IST@R) | > >| NASA Goddard Space Flight Center | > | > >| Astrophysics Data Facility | Phone: 301-286-0696 > | > >| Code 631 | or > 301-286-2772:Kathy Starling | > >| Greenbelt, MD 20771 | FAX: 301-286-1771 > | > >+------------------------------------+----------------------- > --------------+ > > US Virtual Observatory: http://us-vo.org/ > > Staff page: > http://rings.gsfc.nasa.gov/> ~borne/bio_borne_kirk.html > > > > > > > From - Tue Feb 25 08:29:09 2003 X-UIDL: 3df25b31000009eb X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1P7TWXb017783 for ; Tue, 25 Feb 2003 08:30:03 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OM0Ib13487 for ; Mon, 24 Feb 2003 23:00:18 +0100 (MET) Received: from mta06-svc.ntlworld.com(62.253.162.46) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAHIaWvA; Mon, 24 Feb 03 23:00:17 +0100 Received: from bunyip ([213.105.123.90]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030224215632.MWRM4022.mta06-svc.ntlworld.com@bunyip> for ; Mon, 24 Feb 2003 21:56:32 +0000 Reply-To: From: "Tony Linde" To: Subject: RE: a high level language Date: Mon, 24 Feb 2003 21:56:36 -0000 Organization: University of Leicester Message-ID: <005a01c2dc4f$9a442700$b524d28f@bunyip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <200302241236.52343.patrick.dowler@nrc-cnrc.gc.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h1P7UKX1017963 Status: Hi Patrick, > Our work at CADC and some of my past work has been in the > area of constraint systems. Do you have some refs? Thanks, Tony. > -----Original Message----- > From: Patrick Dowler [mailto:patrick.dowler@nrc-cnrc.gc.ca] > Sent: 24 February 2003 20:37 > To: voql@ivoa.net > Cc: Ed Shaya > Subject: Re: a high level language > > > On February 24, 2003 12:05, Ed Shaya wrote: > > I just want to reiterate that I think VOQL should be a > means for > > the > > > > astronomer to clearly specify what astronomical knowledge he/she > > wants. It should not require the astronomer to know how > data is arranged at > > each of the data centers, nor all of the steps required. > > This point cannot be over-emphasized. Storage data management > by services/institutions will vary alot and it must remain a > hidden implementation detail - with plenty of freedom on the > part of a service to implement in a suitable fashion. > > > > > The astronomer thinks "I am interested in objects with such > and such > > properties" and VOQL should allow a description of these > constraints, > > With the ention of the word "constraints", I'll jump in here: > > Our work at CADC and some of my past work has been in the > area of constraint systems. The great advantage of > constraint-based systems is that they do not, in the general > case, specify a query system per se. The same constraint > system can be applied as a query, a processing (typically > filtering) step, a theorem-prover, etc. > > Since VOQL is still young, I suggest that instead of > inventing a "query language" we will be better servced by a > constraint toolkit. The advantages are many: > > - easy to convert to a query > - easy to apply as a processing or filtering step > - easy to build a UI that allows users to construct > constraint systems since > constraints are "things" to be created and manipulated > - easy (well, easier :-) validate > > Although I don't go crazy for this sort of thing: > > - easy to serialize as XML (constraints are things with > simple parent-child relations > between them and the expressions, operators, and constants in use) > > My 2c (although I guess Canadians should up that to 3c), > > > -- > Patrick Dowler > Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045 > Canadian Astronomy Data Centre | Centre canadien de > donnees astronomiques > National Research Council Canada | Conseil national de > recherches Canada > Government of Canada | Gouvernement du Canada > 5071 West Saanich Road | 5071, chemin West Saanich > Victoria, BC | Victoria (C.-B.) > From - Tue Feb 25 00:29:07 2003 X-UIDL: 3df25b31000009e7 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1ON5csK019590 for ; Tue, 25 Feb 2003 00:23:57 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1OMTT314458 for ; Mon, 24 Feb 2003 23:29:29 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAn3aapC; Mon, 24 Feb 03 23:29:28 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1OMSAle005797; Mon, 24 Feb 2003 17:28:15 -0500 Message-ID: <3E5A9C58.3090905@gsfc.nasa.gov> Date: Mon, 24 Feb 2003 17:27:36 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Patrick Dowler CC: voql@ivoa.net Subject: Re: a high level language References: <3E5A7B17.5000403@gsfc.nasa.gov> <200302241236.52343.patrick.dowler@nrc-cnrc.gc.ca> In-Reply-To: <200302241236.52343.patrick.dowler@nrc-cnrc.gc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Patrick, VOQL should be driven by the science user scenarios. And in fact there are a few constraint-based reasoning requirements there. For example, finding fast moving objects puts constraints on positions at different times. And, obtaining ranges in a color requires constraints on differences of fluxes in 2 bands. So, one needs to allow some arithmetic on the variables of the constraints. But, we don't want to introduce things like fuzzy constraint satisfaction (where one associates an importance weighting for each constraint) until/unless one has a real science use case that requires it. If you do have specific science cases that require more than simple arithmetic in the constraint variables, let us know. Ed Patrick Dowler wrote: >On February 24, 2003 12:05, Ed Shaya wrote: > > >> I just want to reiterate that I think VOQL should be a means for the >> >>astronomer to clearly specify what astronomical knowledge he/she wants. >> It should not require the astronomer to know how data is arranged at >>each of the data centers, nor all of the steps required. >> >> > >This point cannot be over-emphasized. Storage data management by >services/institutions will vary alot and it must remain a hidden implementation >detail - with plenty of freedom on the part of a service to implement in a >suitable fashion. > > > >>The astronomer thinks "I am interested in objects with such and such >>properties" and VOQL should allow a description of these constraints, >> >> > >With the ention of the word "constraints", I'll jump in here: > >Our work at CADC and some of my past work has been in the area of >constraint systems. The great advantage of constraint-based systems is >that they do not, in the general case, specify a query system per se. The >same constraint system can be applied as a query, a processing (typically >filtering) step, a theorem-prover, etc. > >Since VOQL is still young, I suggest that instead of inventing a "query language" >we will be better servced by a constraint toolkit. The advantages are many: > >- easy to convert to a query >- easy to apply as a processing or filtering step >- easy to build a UI that allows users to construct constraint systems since > constraints are "things" to be created and manipulated >- easy (well, easier :-) validate > >Although I don't go crazy for this sort of thing: > >- easy to serialize as XML (constraints are things with simple parent-child relations > between them and the expressions, operators, and constants in use) > >My 2c (although I guess Canadians should up that to 3c), > > > > From - Tue Feb 25 18:49:09 2003 X-UIDL: 3df25b3100000a21 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1PHkmSk016664 for ; Tue, 25 Feb 2003 18:46:49 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1PHkmp12739 for ; Tue, 25 Feb 2003 18:46:48 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAw3aq4y; Tue, 25 Feb 03 18:46:47 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1PHjile023549 for ; Tue, 25 Feb 2003 12:45:45 -0500 Message-ID: <3E5BABA1.9070807@gsfc.nasa.gov> Date: Tue, 25 Feb 2003 12:45:05 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: voql@ivoa.net Subject: Re: a high level language References: <200302242025.PAA01444@rings.gsfc.nasa.gov> <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> In-Reply-To: <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: Patrick, We design some things in UML and some things in XML Schema here. It is not really that big a deal, especially when the goal is the exchange of metadata terms and/or queries. Schema does miss out in expressing certain inheritance rules, but we can keep track of these if they occur. There are a number of technical problems with working in a group with UML, but if everyone agrees to work on this in UML then fine lets do it. But even in our OMG task force on an international standard for telemetry and commanding, we all came to the conclusion early on that it was most practical to develop with Schema and at the end convert to UML for OMG approval (OMG is the home of Model Driven Architecture). After we did convert to UML noone want to use it because it did not add anything and we did not have anything to add to it. For exchange languages (the L in VOQL) it is just is that way. For UML, we would need to agree on an exchange language of the UML which may mean we need to agree on UML development environment. Right now the latest standard is XMI version 1.3, but not all UML viewers take that, or they take it only partially. One might be able to convert to GIF, but even a moderate size UML becomes too combersome to use this way. Then there is the issue of finding a good UML editor, since most except Rosetta are not that great either. Rosetta is very expensive. The practical fact is that XML has inexpensive and sophisticated schema editors that are very easy to learn. As for your main point that we should not, right now, insist that the final VOQL be an XML language, I can go along with that. Who knows what is coming next and maybe we will all agree to use CORBA instead? But, as a practical matter, I think developing in XML and providing examples in XML is good enough for now. Ed Patrick Dowler wrote: >On February 24, 2003 12:25, Kirk Borne wrote: > > >>Ed's comments elaborate on the rationale for a VO Query Language, >>but let's not forget the point ... VOQL is a language in a standard >>format (XML) for specifying queries to distributed heterogeneous >>astronomical information resources. >> >> > >Here I would like to strongly DISAGREE. There is no need to a-priori define >VOQL in terms of XML. XML is a serialization format that one uses to >exchange structured text. It is a huge mistake to pre-suppose that anything >is fundamentally an XML thing. It is an even bigger mistake to "design with >XML". I am not saying XML will or should not be part of the solution; it >should not be goal... > >I suppose this comment could be addressed to every IVOA mailing list, >but I'll leave it here for now. > > > From - Thu Feb 27 12:09:14 2003 X-UIDL: 3e5baf6500000027 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RB9I3O017684 for ; Thu, 27 Feb 2003 12:09:19 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RB9GC13061 for ; Thu, 27 Feb 2003 12:09:16 +0100 (MET) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAlfaGGz; Thu, 27 Feb 03 12:09:15 +0100 Received: from TAURUS.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3/3.7W00121514) with ESMTP id UAA20655 for ; Thu, 27 Feb 2003 20:05:27 +0900 (JST) Message-Id: <5.0.2.5.2.20030227195454.04693640@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 27 Feb 2003 20:04:05 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Re: a high level language In-Reply-To: <3E5BABA1.9070807@gsfc.nasa.gov> References: <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> <200302242025.PAA01444@rings.gsfc.nasa.gov> <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear Everyone, I am Masatoshi Ohishi of the National Astronomical Observatory of Japan, and has been assigned as a coordinator to develop our common VOQL. I was so sorry that I could not participate to your debate for the last several days. I was attending to other international meeting as a delegate from Japanese Government, and, therefore, was unable to respond you all. Japan has developed our own Query Language (JVO QL) based on the standard SQL, with some extensions to apply to astronomy. We aimed to DEFINE its functions, and we have not considered which language to use, such as XML, UML, etc. We believe we can choose it later after we have defined which functions we really need to exchange query information. Our document on JVOQL was originally written in Japanese (it's our default language !), and my colleague is preparing its English version. I will submit the document to this exploder soon. I am looking forward to having your constructive comments to our document. Cheers, Masatoshi From - Thu Feb 27 16:44:14 2003 X-UIDL: 3e5baf6500000032 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RFjb3O010688 for ; Thu, 27 Feb 2003 16:45:37 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RFjbu25555 for ; Thu, 27 Feb 2003 16:45:37 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA2eaG5X; Thu, 27 Feb 03 16:45:36 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1RFiKle016966; Thu, 27 Feb 2003 10:44:20 -0500 Message-ID: <3E5E3220.3050005@gsfc.nasa.gov> Date: Thu, 27 Feb 2003 10:43:28 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql , metadata Subject: new version of high level languge Content-Type: multipart/mixed; boundary="------------080607050403040708030902" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------080607050403040708030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have made numerous additions/changes, most notably adding arithmetic, logic, inequalities, so that one can take response variables and put constraints on them. I tried to be consistent with MathML whereever appropriate. I did not get in all of the annotation that I hoped, but there are some short statements about each Type. You can see an extensive auto generated documentation along with the latest schemas at http://nvo.gsfc.nasa.gov/impress/ql/voql.xsd Also, the spaceTime parts are now in a separate namespace, but for some reason I had to drop all default values to do this, don't understand why. Ed --------------080607050403040708030902 Content-Type: text/xml; name="useCase1.xml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="useCase1.xml" @clusterXray @image @clusterName 0.6 @cz @galaxyName @gRA @gDE @mType @gXray @@images @Xraybrightness @galaxyName 3.0E3 @clusterName @clusterXray @image @cz @galaxyName @galaxyName @gRA @gDE @gXray @mType @@images @@q --------------080607050403040708030902-- From - Thu Feb 27 16:54:14 2003 X-UIDL: 3e5baf6500000034 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RFrK3O012165 for ; Thu, 27 Feb 2003 16:53:20 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RFrJl25940 for ; Thu, 27 Feb 2003 16:53:19 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_cayQY; Thu, 27 Feb 03 16:53:18 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1RFqHle017447; Thu, 27 Feb 2003 10:52:17 -0500 Message-ID: <3E5E33FD.9040807@gsfc.nasa.gov> Date: Thu, 27 Feb 2003 10:51:25 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: voql , metadata Subject: Re: new version of high level languge References: <3E5E3220.3050005@gsfc.nasa.gov> In-Reply-To: <3E5E3220.3050005@gsfc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Oops, that is not the URL for the documentation. Here it is: http://nvo.gsfc.nasa.gov/ql/voql_doc/voqla.html Sorry about that. Ed Shaya wrote: > > I have made numerous additions/changes, most notably adding > arithmetic, logic, inequalities, > so that one can take response variables and put constraints on them. > I tried to be consistent with MathML whereever appropriate. I did not > get in all of the annotation that I hoped, but there are some short > statements about each Type. You can see an extensive auto generated > documentation along with the latest schemas at > > http://nvo.gsfc.nasa.gov/impress/ql/voql.xsd > > Also, the spaceTime parts are now in a separate namespace, but for > some reason I had to > drop all default values to do this, don't understand why. > > Ed > >------------------------------------------------------------------------ > > > > > > > > @clusterXray > @image > @clusterName > > > 0.6 > @cz > > > > @galaxyName > > > > @gRA > > > > > > > > @gDE > > > > @mType > > @gXray > @@images > > > > > > > > > > > > @Xraybrightness > > @galaxyName > > > > 3.0E3 > > > > > > > @clusterName > @clusterXray > @image > @cz > > > > @galaxyName > > > > > @galaxyName > @gRA > @gDE > @gXray > @mType > @@images > @@q > > > > > > From - Thu Feb 27 16:59:15 2003 X-UIDL: 3e5baf6500000035 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RFui3O012711 for ; Thu, 27 Feb 2003 16:56:44 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RFuh326138 for ; Thu, 27 Feb 2003 16:56:43 +0100 (MET) Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAADRaG8Y; Thu, 27 Feb 03 16:56:42 +0100 Received: from rings.gsfc.nasa.gov (rings.gsfc.nasa.gov [128.183.190.139]) by rings.gsfc.nasa.gov (8.9.3/8.9.3) with SMTP id KAA06838; Thu, 27 Feb 2003 10:52:40 -0500 (EST) Message-Id: <200302271552.KAA06838@rings.gsfc.nasa.gov> Date: Thu, 27 Feb 2003 10:52:40 -0500 (EST) From: Kirk Borne Reply-To: Kirk Borne Subject: Re: a high level language To: voql@ivoa.net, masatoshi.ohishi@nao.ac.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bRmd1uDlOMHFVLgxduxVFA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Masatoshi: thank you for your message and for the information. We will look forward to reading your JVOQL document. - Kirk Borne > Date: Thu, 27 Feb 2003 20:04:05 +0900 > To: voql@ivoa.net > From: Masatoshi OHISHI > Subject: Re: a high level language > > Dear Everyone, > > I am Masatoshi Ohishi of the National Astronomical Observatory of Japan, > and has been assigned as a coordinator to develop our common VOQL. > > I was so sorry that I could not participate to your debate for the last > several days. I was attending to other international meeting as a delegate > from Japanese Government, and, therefore, was unable to respond you all. > > Japan has developed our own Query Language (JVO QL) based on the > standard SQL, with some extensions to apply to astronomy. We aimed to > DEFINE its functions, and we have not considered which language to use, > such as XML, UML, etc. We believe we can choose it later after we have > defined which functions we really need to exchange query information. > > Our document on JVOQL was originally written in Japanese (it's our default > language !), and my colleague is preparing its English version. I will submit > the document to this exploder soon. > > I am looking forward to having your constructive comments to our document. > > Cheers, > > Masatoshi +------------------------------------+-------------------------------------+ | Dr. Kirk D. Borne | mailto:Kirk.Borne@gsfc.nasa.gov | | Institute for Science & Technology, Raytheon (IST@R) | | NASA Goddard Space Flight Center | | | Astrophysics Data Facility | Phone: 301-286-0696 | | Code 631 | or 301-286-2772:Kathy Starling | | Greenbelt, MD 20771 | FAX: 301-286-1771 | +------------------------------------+-------------------------------------+ US Virtual Observatory: http://us-vo.org/ Staff page: http://rings.gsfc.nasa.gov/~borne/bio_borne_kirk.html From - Thu Feb 27 18:44:15 2003 X-UIDL: 3e5baf650000003a X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RHjY3O005357 for ; Thu, 27 Feb 2003 18:45:34 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RHjYY02283 for ; Thu, 27 Feb 2003 18:45:34 +0100 (MET) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAChaqDe; Thu, 27 Feb 03 18:45:32 +0100 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h1RHiH707018 for ; Thu, 27 Feb 2003 11:44:17 -0600 Date: Thu, 27 Feb 2003 11:44:17 -0600 (CST) From: Ray Plante Reply-To: Ray Plante To: voql@ivoa.net Subject: voql requirements In-Reply-To: <5.0.2.5.2.20030227195454.04693640@mail.mtk.nao.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: It's great to see some activity on this list. In particular, it's good to see a variety of ways we might approach a VO QL. One thing I believe will greatly help us to discern which solutions to go with is a set of requirements for our query language. One of the benefits of evaluating solutions in terms of requirements is that you often find that several solutions are good enough to do the job; discussion then can focus on any extra advantages or disadvantages the solution brings. I would recommend that we begin assembling such requirements on this list or on the Wiki site (http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL). Interested people should attempt to state their favorite requirments in concise sentences, separated from discussion. At some point, we can assemble everyone's favorites into a big list, and add/subtract/edit from there. That said, here are my two favorite requirements which I've alluded to in earlier discussion: 1. The query message format should be easy to parse and transform into other forms. The transformation may be syntactic (e.g. into SQL) and/or semantic, in which the metadata terms are altered. 2. The query language itself should be defined independently of the metadata and functions that can be used in the query. The language, thus, should be extensible for use with any metadata schema. What the 2nd requirement means is we should leave out of the core language references to such things as sky positions/regions, measurements, and object types. These should be considered metadata defined in a separate standard. And because they operate on metadata, I feel functions should also be defined separately from the core language itself. cheers, Ray From - Thu Feb 27 21:39:15 2003 X-UIDL: 3e5baf650000003d X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RKbI3O011132 for ; Thu, 27 Feb 2003 21:37:18 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RKbHa10441 for ; Thu, 27 Feb 2003 21:37:17 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAVVaazu; Thu, 27 Feb 03 21:37:16 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1RKa8le001734 for ; Thu, 27 Feb 2003 15:36:09 -0500 Message-ID: <3E5E7684.4000602@gsfc.nasa.gov> Date: Thu, 27 Feb 2003 15:35:16 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql Subject: Re: voql requirements 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/) Status: Ray, My requirements for a query language are: 1. Allow for machine readable (parseable) expression of the user science cases to the greatest extent, within reason. And, be reasonably certain that it can be useful for the much wider set of astronomical queries. 2. Be a coherent, logical, and small language (ie., easy to learn, use, and remember). 3. Allow for easy web form entry. 4. Be useful to astronomers who do not have prior knowledge of the data centers or of how the data is arranged at the data centers. A corollary is that the language is immutable with respect to rearrangements of data at the data centers. (Should I say resources instead of data centers?). 5. It should be possible for each constraint within the query language to be interpreted as a set of actions that will be accomplished by a distributed set of resources, services, and registries, each embued with well described data and metadata. The services must include an integration service that provides for final evaluation of the logical constraints. 6. Be easily extensible. I totally agree with your requirement #1. And I agree to the spirit of your #2, but it is somewhat in conflict with my #1. You see, we can make a kernel that is totally independent of metadata. In fact, what we have right now is quite close to that. All we have to do is put the math, image and measurement properties into separate schema and then have a schema that inherits the kernel and the specific properties. This is already the case with spatial and temporal coordinates. However, without these metadata specific terms, one can not actually express the user science cases. So, let me try this one out on you. 7. There should be a kernel that is essentially metadata independent, a second layer that addresses broad classes of astronomical data (ie. that makes the language astronomical in nature but not likely to change with metadata choices), and then however many additional layers to make the language complete. Ed Ray Plante wrote: >It's great to see some activity on this list. In particular, it's good to >see a variety of ways we might approach a VO QL. One thing I believe will >greatly help us to discern which solutions to go with is a set of >requirements for our query language. One of the benefits of evaluating >solutions in terms of requirements is that you often find that several >solutions are good enough to do the job; discussion then can focus on any >extra advantages or disadvantages the solution brings. > >I would recommend that we begin assembling such requirements on this list >or on the Wiki site (http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL). >Interested people should attempt to state their favorite requirments in >concise sentences, separated from discussion. At some point, we can >assemble everyone's favorites into a big list, and add/subtract/edit from >there. > >That said, here are my two favorite requirements which I've alluded to in >earlier discussion: > >1. The query message format should be easy to parse and transform into > other forms. The transformation may be syntactic (e.g. into SQL) > and/or semantic, in which the metadata terms are altered. > >2. The query language itself should be defined independently of the > metadata and functions that can be used in the query. The language, > thus, should be extensible for use with any metadata schema. > >What the 2nd requirement means is we should leave out of the core language >references to such things as sky positions/regions, measurements, and >object types. These should be considered metadata defined in a separate >standard. And because they operate on metadata, I feel functions should >also be defined separately from the core language itself. > >cheers, >Ray > > > > From - Thu Feb 27 21:49:15 2003 X-UIDL: 3e5baf650000003e X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RKkM3O013130 for ; Thu, 27 Feb 2003 21:46:22 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RKkMH10750 for ; Thu, 27 Feb 2003 21:46:22 +0100 (MET) Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAjUaO_u; Thu, 27 Feb 03 21:46:21 +0100 Received: from stsci.edu (dsl081-096-059.den1.dsl.speakeasy.net [64.81.96.59]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id ADO00649 (AUTH gaffney); Thu, 27 Feb 2003 15:46:18 -0500 (EST) Message-ID: <3E5E792D.60702@stsci.edu> Date: Thu, 27 Feb 2003 13:46:37 -0700 From: Niall Gaffney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Shaya CC: voql , metadata Subject: Re: new version of high level languge References: <3E5E3220.3050005@gsfc.nasa.gov> <3E5E33FD.9040807@gsfc.nasa.gov> In-Reply-To: <3E5E33FD.9040807@gsfc.nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: I think this is a great start on a query language. As someone who might write a client to use the VO, this is what I would love to have to get my information. One thing I want to reflect a little on a broader issue. The question is how much buy in cost do we expect VO service providers to have to bear and what will the VO provide to aid in this? I know we want it to be as "small as possible". Supporting this query language though seems to create a significantly larger buy in cost than say our cone searches or SIA mostly due to is flexability. For a some participant, this would require significantly more effort to support. I'm not saying that this is a bad thing, as we do want the VO to be useful (and not being able to do some of these things would essentially make it not very usefull at all), but we have to recognize this. Making services use a common data model is essental to the VO but we do have to look at this issue and explore where to draw the line of who does what conversions and manipulations to maximize participation and functionallity of the VO as a whole. Requiring all services to implement such things as math and unit conversions in the query language and expect all providers to support that (correctly) is one of these things we should look at. To reduce buy in for this very flexable query language, do we (the VO) anticipate providing some black box VO middle ware that would allow providers to describe their holdings and access methods in some way and have the black box use the access methods to get the data and then do the conversions and handling of the math? I recognize that in many cases it would be strait forward to create an XSLT that could convert this query into SQL that is optimized for their database for an XML/SQL guru. I don't know if that would be true for many potential providers, nor how many this would scare off simply as they do not have the resources. I also don't know if it is reasonable to try to make a generic black box as each system can be so different. Alternately do we want to have different extensions to the query language and have the service know how to reveal which extensions it can use, either by interogation or in fields in the registry (or both with efficient harvesting). Supports Math, Supports Unit Conversions, Supports 3D geometry queries...whatever. This gives me goosebumps as I know what this sort of thing has done to many other languages such as SQL. Then those who wanted to provide advanced services like unit conversion and math could do so and clients that needed these services could restrict who they query to only the advanced ones they need. Or do we simply have many different VO query entry points. Cone Search and SIA like services stay with us as the simplest entry level for queries. VOQL then becomes a higher entry level (and perhapse has a simple way to cast itself into a cone search interface or a SIA interface). These advanced services can easily provide wrappers to act as Cone Searches or SIA searches. Then the clients use the services that are at the level of complexity they need to do what they need to do knowing the lower they get the more data they can access, but the higher they go the less they have to do, but the more complex a system they have to support. I know this is a bit off topic, but this query provides a good example for this issue and one that I think these groups should make some recomendations on for the rest of the VO to look into. Niall Ed Shaya wrote: > > Oops, that is not the URL for the documentation. Here it is: > http://nvo.gsfc.nasa.gov/ql/voql_doc/voqla.html > Sorry about that. > > > Ed Shaya wrote: > >> >> I have made numerous additions/changes, most notably adding >> arithmetic, logic, inequalities, >> so that one can take response variables and put constraints on them. >> I tried to be consistent with MathML whereever appropriate. I did >> not get in all of the annotation that I hoped, but there are some >> short statements about each Type. You can see an extensive auto >> generated documentation along with the latest schemas at >> >> http://nvo.gsfc.nasa.gov/impress/ql/voql.xsd >> >> Also, the spaceTime parts are now in a separate namespace, but for >> some reason I had to >> drop all default values to do this, don't understand why. >> >> Ed >> >> ------------------------------------------------------------------------ >> >> >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://www.vo.org/ql >> voql.xsd"> >> >> >> >> > project="ROSAT">@clusterXray >> > quality="@q">@image >> @clusterName >> >> >> 0.6 >> @cz >> >> >> >> @galaxyName >> >> >> >> @gRA >> >> >> >> > coord_epoch="@epoch" coord_ref_frame="FK5"/> >> >> >> >> @gDE >> >> >> >> > name="mType">@mType >> >> > name="Xraybrightness" units="@xrayUnits">@gXray >> > quality="@@q">@@images >> >> >> >> >> >> >> >> >> >> >> >> @Xraybrightness >> >> @galaxyName >> >> >> >> 3.0E3 >> >> >> >> >> >> >> > units="unitless">@clusterName >> > units="Jansky">@clusterXray >> @image >> @cz >> >> >> >> @galaxyName >> >> >> >> >> > units="unitless">@galaxyName >> @gRA >> @gDE >> @gXray >> @mType >> @@images >> @@q >> >> >> >> >> >> > From - Fri Feb 28 05:39:15 2003 X-UIDL: 3e5baf6500000043 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1S4aTNb014300 for ; Fri, 28 Feb 2003 05:36:29 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1S4aS823374 for ; Fri, 28 Feb 2003 05:36:28 +0100 (MET) Received: from postal.sdsc.edu(132.249.20.114) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAB_aOPT; Fri, 28 Feb 03 05:36:27 +0100 Received: (from moore@localhost) by postal.sdsc.edu (8.11.6/8.11.6/server/53) id h1S4WTU06267; Thu, 27 Feb 2003 20:32:29 -0800 (PST) Mime-Version: 1.0 X-Sender: moore@pop.sdsc.edu Message-Id: In-Reply-To: <3E5E792D.60702@stsci.edu> References: <3E5E3220.3050005@gsfc.nasa.gov> <3E5E33FD.9040807@gsfc.nasa.gov> <3E5E792D.60702@stsci.edu> Date: Thu, 27 Feb 2003 20:26:56 -0800 To: voql , metadata , owner-metadata@us-vo.org From: Reagan Moore Subject: Re: new version of high level language Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: We have the technology to map from an XML specification of attributes, values, and operations on values, to the SQL required by a particular database (Oracle, DB2, Sybase, SQLServer, PostgresSQL, Informix). This capability has been used within the Extensible Metadata Catalog, part of the Storage Resource Broker technology. The technology does require the registration of the table structure, foreign keys, and schema of each database for the automation of the SQL generation. We can use UCDs as tokens to manage semantic interoperability. This would require the association of UCDs with the variables currently being used within the collection. Are there other types of databases in current use? Reagan Moore >I think this is a great start on a query language. As >someone who might >write a client to use the VO, this is what I would love to have to get >my information. > >One thing I want to reflect a little on a broader issue. The question >is how much buy in cost do we expect VO service providers to have to >bear and what will the VO provide to aid in this? I know we want it to >be as "small as possible". Supporting this query language though seems >to create a significantly larger buy in cost than say our cone searches >or SIA mostly due to is flexability. For a some participant, this would >require significantly more effort to support. I'm not saying that this >is a bad thing, as we do want the VO to be useful (and not being able to >do some of these things would essentially make it not very usefull at >all), but we have to recognize this. Making services use a common data >model is essental to the VO but we do have to look at this issue and >explore where to draw the line of who does what conversions and >manipulations to maximize participation and functionallity of the VO as >a whole. Requiring all services to implement such things as math and >unit conversions in the query language and expect all providers to >support that (correctly) is one of these things we should look at. > >To reduce buy in for this very flexable query language, do we (the VO) >anticipate providing some black box VO middle ware that would allow >providers to describe their holdings and access methods in some way and >have the black box use the access methods to get the data and then do >the conversions and handling of the math? I recognize that in many >cases it would be strait forward to create an XSLT that could convert >this query into SQL that is optimized for their database for an XML/SQL >guru. I don't know if that would be true for many potential providers, >nor how many this would scare off simply as they do not have the >resources. I also don't know if it is reasonable to try to make a >generic black box as each system can be so different. > >Alternately do we want to have different extensions to the query >language and have the service know how to reveal which extensions it can >use, either by interogation or in fields in the registry (or both with >efficient harvesting). Supports Math, Supports Unit Conversions, >Supports 3D geometry queries...whatever. This gives me goosebumps as I >know what this sort of thing has done to many other languages such as >SQL. Then those who wanted to provide advanced services like unit >conversion and math could do so and clients that needed these services >could restrict who they query to only the advanced ones they need. > >Or do we simply have many different VO query entry points. Cone Search >and SIA like services stay with us as the simplest entry level for >queries. VOQL then becomes a higher entry level (and perhapse has a >simple way to cast itself into a cone search interface or a SIA >interface). These advanced services can easily provide wrappers to act >as Cone Searches or SIA searches. Then the clients use the services >that are at the level of complexity they need to do what they need to do >knowing the lower they get the more data they can access, but the higher >they go the less they have to do, but the more complex a system they >have to support. > >I know this is a bit off topic, but this query provides a good example >for this issue and one that I think these groups should make some >recomendations on for the rest of the VO to look into. > >Niall > > >Ed Shaya wrote: > >> >> Oops, that is not the URL for the documentation. Here it is: >> http://nvo.gsfc.nasa.gov/ql/voql_doc/voqla.html >> Sorry about that. >> >> >> Ed Shaya wrote: >> >>> >>> I have made numerous additions/changes, most notably adding >>> arithmetic, logic, inequalities, >>> so that one can take response variables and put constraints on them. >>> I tried to be consistent with MathML whereever appropriate. I did >>> not get in all of the annotation that I hoped, but there are some >>> short statements about each Type. You can see an extensive auto >>> generated documentation along with the latest schemas at >>> >>> http://nvo.gsfc.nasa.gov/impress/ql/voql.xsd >>> >>> Also, the spaceTime parts are now in a separate namespace, but for >>> some reason I had to >>> drop all default values to do this, don't understand why. >>> >>> Ed >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>> xsi:schemaLocation="http://www.vo.org/ql >>> voql.xsd"> >>> >>> >>> >>> >> project="ROSAT">@clusterXray >>> >> quality="@q">@image >>> @clusterName >>> >>> >>> 0.6 >>> @cz >>> >>> >>> >>> @galaxyName >>> >>> >>> >>> @gRA >>> >>> >>> >>> >> coord_epoch="@epoch" coord_ref_frame="FK5"/> >>> >>> >>> >>> @gDE >>> >>> >>> >>> >> name="mType">@mType >>> >>> >> name="Xraybrightness" units="@xrayUnits">@gXray >>> >> quality="@@q">@@images >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> @Xraybrightness >>> >>> @galaxyName >>> >>> >>> >>> 3.0E3 >>> >>> >>> >>> >>> >>> >>> >> units="unitless">@clusterName >>> >> units="Jansky">@clusterXray >>> @image >>> @cz >>> >>> >>> >>> @galaxyName >>> >>> >>> >>> >>> >> units="unitless">@galaxyName >>> @gRA >>> @gDE >>> @gXray >>> @mType >>> @@images >>> @@q >>> >>> >>> >>> >>> >>> >> > > From - Thu Feb 27 22:54:15 2003 X-UIDL: 3e5baf6500000040 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1RLt83O003525 for ; Thu, 27 Feb 2003 22:55:08 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1RLt8u13316 for ; Thu, 27 Feb 2003 22:55:08 +0100 (MET) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA25ayaA; Thu, 27 Feb 03 22:55:07 +0100 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h1RLrxe07825; Thu, 27 Feb 2003 15:53:59 -0600 Date: Thu, 27 Feb 2003 15:53:59 -0600 (CST) From: Ray Plante Reply-To: Ray Plante To: Ed Shaya cc: voql Subject: Re: voql requirements In-Reply-To: <3E5E7684.4000602@gsfc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ed, > I totally agree with your requirement #1. And I agree to the spirit of > your #2, but it is somewhat in conflict with my #1. You see, we can > make a kernel that is totally independent of metadata. In fact, what we > have right now is quite close to that. All we > have to do is put the math, image and measurement properties into > separate schema > and then have a schema that inherits the kernel and the specific > properties. This is already the case with spatial and temporal > coordinates. > However, without these metadata specific > terms, one can not actually express the user science cases. So, let me > try this one out on you. While I admit I haven't had a chance to study your latest documents closely, I would want to be pretty hard-nosed about this. The way I see it, voql + metadata ==> support for science use cases Thus, we can't answer queries without metadata. The importance of this separation is in that it ensures that the voql does not depend on the metadata. This makes it easier to evolve the schema or swap in a different one. E.g. if the application doesn't like the metadata model (use of measurements, positions, whatever) it can use its own model. Another advantage of separating out the metadata part of the problem is that it makes it easier to leverage metadata models used in other VO contexts (e.g. query results/VOTable, registry records, etc.) By tying the metadata model to the query language makes this harder to use metadata consistantly across the VO. > 7. There should be a kernel that is essentially metadata independent, a > second layer that > addresses broad classes of astronomical data (ie. that makes the > language astronomical in nature but not likely to change with metadata > choices), and then however many additional layers to make the language > complete. I think that we would need to motivate any interdependence of the VO query syntax and the metadata you plug into it; otherwise, this looks like a implementation specification. That is, can we have successful solution in which this requirement is not met? Nevertheless, I'll look at your stuff to better understand the connections between the syntax and the metadata. cheers, Ray From - Fri Feb 28 01:34:15 2003 X-UIDL: 3e5baf6500000042 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1S0XFNb019943 for ; Fri, 28 Feb 2003 01:33:15 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1S0XFp17764 for ; Fri, 28 Feb 2003 01:33:15 +0100 (MET) Received: from nrcvicex1a.hia.nrc.ca(204.174.103.8) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAWiaySI; Fri, 28 Feb 03 01:33:14 +0100 Received: from frodo (cadc-nat.vic.hia.nrc.ca [206.12.3.36]) by nrcvicex1.hia.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1GCV8662; Thu, 27 Feb 2003 16:32:20 -0800 Content-Type: text/plain; charset="iso-8859-1" From: Patrick Dowler Organization: National Research Council Canada To: ael@star.le.ac.uk, voql@ivoa.net Subject: Re: a high level language Date: Thu, 27 Feb 2003 16:32:24 -0800 User-Agent: KMail/1.4.3 References: <005a01c2dc4f$9a442700$b524d28f@bunyip> In-Reply-To: <005a01c2dc4f$9a442700$b524d28f@bunyip> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200302271632.24544.patrick.dowler@nrc-cnrc.gc.ca> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On February 24, 2003 13:56, Tony Linde wrote: > Hi Patrick, > > > Our work at CADC and some of my past work has been in the > > area of constraint systems. > > Do you have some refs? Sorry to be tardy in replying - I was home sick for a couple of days :-( I don't have any good reference material for the constraint package that we have developed, but it is simple enough that I'll include something right here. I should note that this way of doing it has the added advantage of separating the query language and the meta-data (which is "content" in the constraint system). We have a java package (toolkit) which can be used to construct constraints. A set of constraints forms a query - not counting the specification of output format, which we handle separately. More exactly, a constraint set specifies a "set of things" namely the things which satisfy the constraints. How one views the set of things (ie. the output of the query) is a separate issue. So, out package has the following classes (I show the constructor for each because that shows how they relate and are built). Indentation shows class hierarchy. Expression Constant(String | Number | ??) Property(String) Operator Add(Expression, Expression) Sub(Expression, Expression) Mul(Expression, Expression) Div(Expression, Expression) Size(...) Area(...) etc... Constraint Known(Property) cruft: arg should be an Expression Unknown(Property) cruft: arg should be an Expression Eq(Expression,Expression) Leq(Expression,Expression) Geq(Expression,Expression) Between(Expression,Expression,Expression) Contains(Property.Interval, Number) cruft: 2nd arg should be type-safe Constant Intersect(Property.Shape, Shape) cruft: 2nd arg should be type-safe Constant Note: Property.Interval and Property.Shape are subclasses of Property that let one enforce some type safety in constraint construction... we're currently rather ambivalent about compile-time vs. runtime type checking (experimental stage :-) Other note: any mention of a Property in any Expression implies a Known constraint for that that Property. Known is just a way of saying "I want to see it or include it, but I don't care about the value". Where does the meta-data fit in? It is the content of the Property objects. What about boolean operators? In a constraint-based system, a set of constraints are implicitly AND. One could easily implement an OR as a Constraint type: Or(Constraint, Constraint) How does this relate to other VO stuff? The types of values (as used in Constant or Property objects) are at the base of both the constraint system and the data model. For example, if you want to have polygons in a data model, you need polygon-compatible Property and Constant objects in the constraint system and you need Constraint types that know deal with those types. Why is it soooooo OO? Anyone whose written a parser will recognize the above classes as the nodes of a parse tree. We came to the realisation that all over our systems we had to deal with parse trees: the query generators convert a parse tree to SQL, the UI creates a parse tree from UI elements, etc. So the natural choice for a model of the query is a constraint system (parse tree). Then we can operate solely in the domain of the constraints throughout most of our software. Examples: x <= 2 y + 1 > 5 z is known becomes: new Leq( new Property("x"), new Constant(2) ) new Geq( new Operator.add( new Property("y"), new Constant(1) ), new Constant(5) ) new Known( new Property("z") ) Note that the "cone search" service can be expressed as: new Intersect( new Property("position_equ"), new Circle2D(ra, dec, radius) ) Of course, it is trivial to serialise a parse tree in a tree-oriented text format ike XML, and the first thing the software at the other end will do is convert the XML document back into a tree (data structure) again. Anyway, we have a Java package that does this, but it is closely tied with our data model package (really it is a "types" package of things missing from or done incorrectly in java2). It wouldn't be too hard to implement this in other languages, but I'm more throwing it out there as a way to do a QL that isn't a "language" because I think that way leads to lots of complication and pain. If anyone has more interest in this stuff, let me know. -- Patrick Dowler Tel/Tél: (250) 363-6914 | Fax: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) From - Fri Feb 28 10:14:15 2003 X-UIDL: 3e5baf650000004b X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1S9C2Nb009128 for ; Fri, 28 Feb 2003 10:12:02 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1S9C2e00070 for ; Fri, 28 Feb 2003 10:12:02 +0100 (MET) Received: from mailsend.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAmPaOia; Fri, 28 Feb 03 10:12:01 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18ogV6-0000fj-00 for voql@ivoa.net; Fri, 28 Feb 2003 09:08:16 +0000 Received: (qmail 7554 invoked from network); 28 Feb 2003 09:08:37 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 28 Feb 2003 09:08:37 -0000 Date: Fri, 28 Feb 2003 09:08:15 +0000 (GMT) From: Clive Page To: voql , metadata Subject: Re: new version of high level language In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Thu, 27 Feb 2003, Reagan Moore wrote: > We have the technology to map from an XML specification of > attributes, values, and operations on values, to the SQL required by > a particular database (Oracle, DB2, Sybase, SQLServer, PostgresSQL, > Informix). > The technology does require the registration of the table structure, > foreign keys, and schema of each database for the automation of the > SQL generation. > Are there other types of databases in current use? That depends what you mean by "types". Quite a number of well-used astronomical data archives don't rely on commercial or even free RDBMS, they use an astronomer-written DBMS. The LEDAS facility here, for example (ledas-www.star.le.ac.uk) now supports searching of USNO-B1.0 - but this isn't loaded into any DBMS, but uses the WCSTOOLS software written at CfA which access the USNO-B data files in their distribution format, and unpacks them on the fly. Seems efficient enough to me for simple cone searches (we don't yet support cross-matching with other catalogues). Other places do something similar: when I asked Francois Ochsenbein if he had managed to ingest the whole of USNO-B1.0 (over a billion rows) into Sybase he told me that it was too large and he hadn't even attempted it. I don't know how Vizier serves it up (maybe Francois can tell us) but I expect CDS wrote the software in-house. So these systems don't speak SQL at all. There are also one or two facilities using object-oriented DBMS - we use O2 here for our internal XMM-Newton operations, and are about to make its interface public. This speaks OQL - semi-standarized, but not the same as SQL. By the way, you left MySQL of your list of RDBMS - perhaps the most widely used one in astronomy? -- Clive Page, Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From - Fri Feb 28 08:59:15 2003 X-UIDL: 3e5baf6500000047 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1S7v1Nb026689 for ; Fri, 28 Feb 2003 08:57:02 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1S7v0F27190 for ; Fri, 28 Feb 2003 08:57:01 +0100 (MET) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAx2aOg1; Fri, 28 Feb 03 08:56:57 +0100 Received: from TAURUS.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3/3.7W00121514) with ESMTP id QAA15235 for ; Fri, 28 Feb 2003 16:53:09 +0900 (JST) Message-Id: <5.0.2.5.2.20030228164854.0478a4d0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Fri, 28 Feb 2003 16:51:50 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Document on JVO Query Language In-Reply-To: <5.0.2.5.2.20030227195454.04693640@mail.mtk.nao.ac.jp> References: <3E5BABA1.9070807@gsfc.nasa.gov> <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> <200302242025.PAA01444@rings.gsfc.nasa.gov> <200302241242.44695.patrick.dowler@nrc-cnrc.gc.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_3400409==_" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: --=====================_3400409==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Everyone, As I promised you yesterday, At 20:04 03/02/27 +0900, Masatoshi OHISHI wrote: >Our document on JVOQL was originally written in Japanese (it's our default >language !), and my colleague is preparing its English version. I will submit >the document to this exploder soon. I am going to distribute our document (PS file) on JVO QL. Any comments (except for brushing up English (^_^!!! ) are welcome ! Cheers, Masatoshi --=====================_3400409==_ Content-Type: application/postscript; name="JVOQL.ps" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="JVOQL.ps" JSFQUy1BZG9iZS0yLjAKJSVDcmVhdG9yOiBkdmlwcyhrKSA1LjkyYSBDb3B5cmlnaHQgMjAwMiBS YWRpY2FsIEV5ZSBTb2Z0d2FyZQolJVRpdGxlOiBKVk9RTC5kdmkKJSVQYWdlczogNwolJVBhZ2VP cmRlcjogQXNjZW5kCiUlQm91bmRpbmdCb3g6IDAgMCA1OTYgODQyCiUlRW5kQ29tbWVudHMKJURW SVBTV2ViUGFnZTogKHd3dy5yYWRpY2FsZXllLmNvbSkKJURWSVBTQ29tbWFuZExpbmU6IGR2aXBz IC1EIDYwMCAtbyBKVk9RTC5wcyBKVk9RTC5kdmkKJURWSVBTUGFyYW1ldGVyczogZHBpPTYwMCwg Y29tcHJlc3NlZAolRFZJUFNTb3VyY2U6ICBUZVggb3V0cHV0IDIwMDMuMDIuMjg6MTIyNQolJUJl Z2luUHJvY1NldDogdGV4Yy5wcm8KJSEKL1RlWERpY3QgMzAwIGRpY3QgZGVmIFRlWERpY3QgYmVn aW4vTntkZWZ9ZGVmL0J7YmluZCBkZWZ9Ti9Te2V4Y2h9Ti9Ye1MKTn1CL0F7ZHVwfUIvVFJ7dHJh bnNsYXRlfU4vaXNscyBmYWxzZSBOL3ZzaXplIDExIDcyIG11bCBOL2hzaXplIDguNSA3MgptdWwg Ti9sYW5kcGx1czkwe2ZhbHNlfWRlZi9AcmlnaW57aXNsc3tbMCBsYW5kcGx1czkwezEgLTF9ey0x IDF9aWZlbHNlIDAKMCAwXWNvbmNhdH1pZiA3MiBSZXNvbHV0aW9uIGRpdiA3MiBWUmVzb2x1dGlv biBkaXYgbmVnIHNjYWxlIGlzbHN7CmxhbmRwbHVzOTB7VlJlc29sdXRpb24gNzIgZGl2IHZzaXpl IG11bCAwIGV4Y2h9e1Jlc29sdXRpb24gLTcyIGRpdiBoc2l6ZQptdWwgMH1pZmVsc2UgVFJ9aWYg UmVzb2x1dGlvbiBWUmVzb2x1dGlvbiB2c2l6ZSAtNzIgZGl2IDEgYWRkIG11bCBUUlsKbWF0cml4 IGN1cnJlbnRtYXRyaXh7QSBBIHJvdW5kIHN1YiBhYnMgMC4wMDAwMSBsdHtyb3VuZH1pZn1mb3Jh bGwgcm91bmQKZXhjaCByb3VuZCBleGNoXXNldG1hdHJpeH1OL0BsYW5kc2NhcGV7L2lzbHMgdHJ1 ZSBOfUIvQG1hbnVhbGZlZWR7CnN0YXR1c2RpY3QvbWFudWFsZmVlZCB0cnVlIHB1dH1CL0Bjb3Bp ZXN7LyNjb3BpZXMgWH1CL0ZNYXRbMSAwIDAgLTEgMCAwXQpOL0ZCQlswIDAgMCAwXU4vbm4gMCBO L0lFbiAwIE4vY3RyIDAgTi9kZi10YWlsey9ubiA4IGRpY3QgTiBubiBiZWdpbgovRm9udFR5cGUg MyBOL0ZvbnRNYXRyaXggZm50cnggTi9Gb250QkJveCBGQkIgTiBzdHJpbmcvYmFzZSBYIGFycmF5 Ci9CaXRNYXBzIFgvQnVpbGRDaGFye0NoYXJCdWlsZGVyfU4vRW5jb2RpbmcgSUVuIE4gZW5kIEF7 L2ZvbyBzZXRmb250fTIKYXJyYXkgY29weSBjdnggTiBsb2FkIDAgbm4gcHV0L2N0ciAwIE5bfUIv c2YgMCBOL2Rmey9zZiAxIE4vZm50cnggRk1hdCBOCmRmLXRhaWx9Qi9kZnN7ZGl2L3NmIFgvZm50 cnhbc2YgMCAwIHNmIG5lZyAwIDBdTiBkZi10YWlsfUIvRXtwb3Agbm4gQQpkZWZpbmVmb250IHNl dGZvbnR9Qi9Dd3tDZCBBIGxlbmd0aCA1IHN1YiBnZXR9Qi9DaHtDZCBBIGxlbmd0aCA0IHN1YiBn ZXQKfUIvQ3h7MTI4IENkIEEgbGVuZ3RoIDMgc3ViIGdldCBzdWJ9Qi9DeXtDZCBBIGxlbmd0aCAy IHN1YiBnZXQgMTI3IHN1Yn0KQi9DZHh7Q2QgQSBsZW5ndGggMSBzdWIgZ2V0fUIvQ2l7Q2QgQSB0 eXBlL3N0cmluZ3R5cGUgbmV7Y3RyIGdldC9jdHIgY3RyCjEgYWRkIE59aWZ9Qi9pZCAwIE4vcncg MCBOL3JjIDAgTi9ncCAwIE4vY3AgMCBOL0cgMCBOL0NoYXJCdWlsZGVye3NhdmUgMwoxIHJvbGwg UyBBL2Jhc2UgZ2V0IDIgaW5kZXggZ2V0IFMvQml0TWFwcyBnZXQgUyBnZXQvQ2QgWCBwb3AvY3Ry IDAgTiBDZHgKMCBDeCBDeSBDaCBzdWIgQ3ggQ3cgYWRkIEN5IHNldGNhY2hlZGV2aWNlIEN3IENo IHRydWVbMSAwIDAgLTEgLS4xIEN4CnN1YiBDeSAuMSBzdWJdL2lkIENpIE4vcncgQ3cgNyBhZGQg OCBpZGl2IHN0cmluZyBOL3JjIDAgTi9ncCAwIE4vY3AgMCBOewpyYyAwIG5le3JjIDEgc3ViL3Jj IFggcnd9e0d9aWZlbHNlfWltYWdlbWFzayByZXN0b3JlfUIvR3t7aWQgZ3AgZ2V0L2dwCmdwIDEg YWRkIE4gQSAxOCBtb2QgUyAxOCBpZGl2IHBsIFMgZ2V0IGV4ZWN9bG9vcH1CL2FkdntjcCBhZGQv Y3AgWH1CCi9jaGd7cncgY3AgaWQgZ3AgNCBpbmRleCBnZXRpbnRlcnZhbCBwdXRpbnRlcnZhbCBB IGdwIGFkZC9ncCBYIGFkdn1CL25kewovY3AgMCBOIHJ3IGV4aXR9Qi9sc2h7cncgY3AgMiBjb3B5 IGdldCBBIDAgZXF7cG9wIDF9e0EgMjU1IGVxe3BvcCAyNTR9ewpBIEEgYWRkIDI1NSBhbmQgUyAx IGFuZCBvcn1pZmVsc2V9aWZlbHNlIHB1dCAxIGFkdn1CL3JzaHtydyBjcCAyIGNvcHkKZ2V0IEEg MCBlcXtwb3AgMTI4fXtBIDI1NSBlcXtwb3AgMTI3fXtBIDIgaWRpdiBTIDEyOCBhbmQgb3J9aWZl bHNlfQppZmVsc2UgcHV0IDEgYWR2fUIvY2xye3J3IGNwIDIgaW5kZXggc3RyaW5nIHB1dGludGVy dmFsIGFkdn1CL3NldHtydyBjcApmaWxsc3RyIDAgNCBpbmRleCBnZXRpbnRlcnZhbCBwdXRpbnRl cnZhbCBhZHZ9Qi9maWxsc3RyIDE4IHN0cmluZyAwIDEgMTcKezIgY29weSAyNTUgcHV0IHBvcH1m b3IgTi9wbFt7YWR2IDEgY2hnfXthZHYgMSBjaGcgbmR9ezEgYWRkIGNoZ317MSBhZGQKY2hnIG5k fXthZHYgbHNofXthZHYgbHNoIG5kfXthZHYgcnNofXthZHYgcnNoIG5kfXsxIGFkZCBhZHZ9ey9y YyBYIG5kfXsKMSBhZGQgc2V0fXsxIGFkZCBjbHJ9e2FkdiAyIGNoZ317YWR2IDIgY2hnIG5kfXtw b3AgbmR9XUF7YmluZCBwb3B9CmZvcmFsbCBOL0R7L2NjIFggQSB0eXBlL3N0cmluZ3R5cGUgbmV7 XX1pZiBubi9iYXNlIGdldCBjYyBjdHIgcHV0IG5uCi9CaXRNYXBzIGdldCBTIGN0ciBTIHNmIDEg bmV7QSBBIGxlbmd0aCAxIHN1YiBBIDIgaW5kZXggUyBnZXQgc2YgZGl2IHB1dAp9aWYgcHV0L2N0 ciBjdHIgMSBhZGQgTn1CL0l7Y2MgMSBhZGQgRH1CL2JvcHt1c2VyZGljdC9ib3AtaG9vayBrbm93 bnsKYm9wLWhvb2t9aWYvU0kgc2F2ZSBOIEByaWdpbiAwIDAgbW92ZXRvL1YgbWF0cml4IGN1cnJl bnRtYXRyaXggQSAxIGdldCBBCm11bCBleGNoIDAgZ2V0IEEgbXVsIGFkZCAuOTkgbHR7L1FWfXsv UlZ9aWZlbHNlIGxvYWQgZGVmIHBvcCBwb3B9Ti9lb3B7ClNJIHJlc3RvcmUgdXNlcmRpY3QvZW9w LWhvb2sga25vd257ZW9wLWhvb2t9aWYgc2hvd3BhZ2V9Ti9Ac3RhcnR7CnVzZXJkaWN0L3N0YXJ0 LWhvb2sga25vd257c3RhcnQtaG9va31pZiBwb3AvVlJlc29sdXRpb24gWC9SZXNvbHV0aW9uIFgK MTAwMCBkaXYvRFZJbWFnIFgvSUVuIDI1NiBhcnJheSBOIDIgc3RyaW5nIDAgMSAyNTV7SUVuIFMg QSAzNjAgYWRkIDM2IDQKaW5kZXggY3ZycyBjdm4gcHV0fWZvciBwb3AgNjU3ODEuNzYgZGl2L3Zz aXplIFggNjU3ODEuNzYgZGl2L2hzaXplIFh9TgovZGlyIDAgZGVmL2R5eXsvZGlyIDAgZGVmfUIv ZHl0ey9kaXIgMSBkZWZ9Qi9kdHl7L2RpciAyIGRlZn1CL2R0dHsvZGlyIDMKZGVmfUIvcHtkaXIg MiBlcXstOTAgcm90YXRlIHNob3cgOTAgcm90YXRlfXtkaXIgMyBlcXstOTAgcm90YXRlIHNob3cg OTAKcm90YXRlfXtzaG93fWlmZWxzZX1pZmVsc2V9Ti9STWF0WzEgMCAwIC0xIDAgMF1OL0JEb3Qg MjYwIHN0cmluZyBOL1J4IDAKTi9SeSAwIE4vVnt9Qi9SVi92ey9SeSBYL1J4IFggVn1CIHN0YXR1 c2RpY3QgYmVnaW4vcHJvZHVjdCB3aGVyZXtwb3AKZmFsc2VbKERpc3BsYXkpKE5lWFQpKExhc2Vy V3JpdGVyIDE2LzYwMClde0EgbGVuZ3RoIHByb2R1Y3QgbGVuZ3RoIGxle0EKbGVuZ3RoIHByb2R1 Y3QgZXhjaCAwIGV4Y2ggZ2V0aW50ZXJ2YWwgZXF7cG9wIHRydWUgZXhpdH1pZn17cG9wfWlmZWxz ZX0KZm9yYWxsfXtmYWxzZX1pZmVsc2UgZW5ke3tnc2F2ZSBUUiAtLjEgLjEgVFIgMSAxIHNjYWxl IFJ4IFJ5IGZhbHNlIFJNYXR7CkJEb3R9aW1hZ2VtYXNrIGdyZXN0b3JlfX17e2dzYXZlIFRSIC0u MSAuMSBUUiBSeCBSeSBzY2FsZSAxIDEgZmFsc2UgUk1hdAp7QkRvdH1pbWFnZW1hc2sgZ3Jlc3Rv cmV9fWlmZWxzZSBCL1FWe2dzYXZlIG5ld3BhdGggdHJhbnNmb3JtIHJvdW5kIGV4Y2gKcm91bmQg ZXhjaCBpdHJhbnNmb3JtIG1vdmV0byBSeCAwIHJsaW5ldG8gMCBSeSBuZWcgcmxpbmV0byBSeCBu ZWcgMApybGluZXRvIGZpbGwgZ3Jlc3RvcmV9Qi9he21vdmV0b31CL2RlbHRhIDAgTi90YWlse0Ev ZGVsdGEgWCAwIHJtb3ZldG99QgovTXtTIHAgZGVsdGEgYWRkIHRhaWx9Qi9ie1MgcCB0YWlsfUIv Y3stNCBNfUIvZHstMyBNfUIvZXstMiBNfUIvZnstMSBNfQpCL2d7MCBNfUIvaHsxIE19Qi9pezIg TX1CL2p7MyBNfUIva3s0IE19Qi93ezAgcm1vdmV0b31CL2x7cCAtNCB3fUIvbXtwCi0zIHd9Qi9u e3AgLTIgd31CL297cCAtMSB3fUIvcXtwIDEgd31CL3J7cCAyIHd9Qi9ze3AgMyB3fUIvdHtwIDQg d31CL3h7CjAgUyBybW92ZXRvfUIveXszIDIgcm9sbCBwIGF9Qi9ib3N7L1NTIHNhdmUgTn1CL2Vv c3tTUyByZXN0b3JlfUIgZW5kCgolJUVuZFByb2NTZXQKJSVCZWdpblByb2NTZXQ6IHNwZWNpYWwu cHJvCiUhClRlWERpY3QgYmVnaW4vU0RpY3QgMjAwIGRpY3QgTiBTRGljdCBiZWdpbi9AU3BlY2lh bERlZmF1bHRzey9ocyA2MTIgTgovdnMgNzkyIE4vaG8gMCBOL3ZvIDAgTi9oc2MgMSBOL3ZzYyAx IE4vYW5nIDAgTi9DTElQIDAgTi9yd2lTZWVuIGZhbHNlIE4KL3JoaVNlZW4gZmFsc2UgTi9sZXR0 ZXJ7fU4vbm90ZXt9Ti9hNHt9Ti9sZWdhbHt9Tn1CL0BzY2FsZXVuaXQgMTAwIE4KL0Boc2NhbGV7 QHNjYWxldW5pdCBkaXYvaHNjIFh9Qi9AdnNjYWxle0BzY2FsZXVuaXQgZGl2L3ZzYyBYfUIvQGhz aXplewovaHMgWC9DTElQIDEgTn1CL0B2c2l6ZXsvdnMgWC9DTElQIDEgTn1CL0BjbGlwey9DTElQ IDIgTn1CL0Bob2Zmc2V0ey9obwpYfUIvQHZvZmZzZXR7L3ZvIFh9Qi9AYW5nbGV7L2FuZyBYfUIv QHJ3aXsxMCBkaXYvcndpIFgvcndpU2VlbiB0cnVlIE59QgovQHJoaXsxMCBkaXYvcmhpIFgvcmhp U2VlbiB0cnVlIE59Qi9AbGx4ey9sbHggWH1CL0BsbHl7L2xseSBYfUIvQHVyeHsKL3VyeCBYfUIv QHVyeXsvdXJ5IFh9Qi9tYWdzY2FsZSB0cnVlIGRlZiBlbmQvQE1hY1NldFVwe3VzZXJkaWN0L21k IGtub3duCnt1c2VyZGljdC9tZCBnZXQgdHlwZS9kaWN0dHlwZSBlcXt1c2VyZGljdCBiZWdpbiBt ZCBsZW5ndGggMTAgYWRkIG1kCm1heGxlbmd0aCBnZXsvbWQgbWQgZHVwIGxlbmd0aCAyMCBhZGQg ZGljdCBjb3B5IGRlZn1pZiBlbmQgbWQgYmVnaW4KL2xldHRlcnt9Ti9ub3Rle31OL2xlZ2Fse31O L29ke3R4cG9zZSAxIDAgbXR4IGRlZmF1bHRtYXRyaXggZHRyYW5zZm9ybSBTCmF0YW4vcGEgWCBu ZXdwYXRoIGNsaXBwYXRoIG1hcmt7dHJhbnNmb3Jte2l0cmFuc2Zvcm0gbW92ZXRvfX17dHJhbnNm b3JtewppdHJhbnNmb3JtIGxpbmV0b319ezYgLTIgcm9sbCB0cmFuc2Zvcm0gNiAtMiByb2xsIHRy YW5zZm9ybSA2IC0yIHJvbGwKdHJhbnNmb3Jte2l0cmFuc2Zvcm0gNiAyIHJvbGwgaXRyYW5zZm9y bSA2IDIgcm9sbCBpdHJhbnNmb3JtIDYgMiByb2xsCmN1cnZldG99fXt7Y2xvc2VwYXRofX1wYXRo Zm9yYWxsIG5ld3BhdGggY291bnR0b21hcmsgYXJyYXkgYXN0b3JlL2djIHhkZgpwb3AgY3QgMzkg MCBwdXQgMTAgZnogMCBmcyAyIEYvfF9fX19fX0NvdXJpZXIgZm50IGludmVydGZsYWd7UGFpbnRC bGFja30KaWZ9Ti90eHBvc2V7cHhzIHB5cyBzY2FsZSBwcHIgYWxvYWQgcG9wIHBvcntub2ZsaXBz e3BvcCBTIG5lZyBTIFRSIHBvcCAxCi0xIHNjYWxlfWlmIHhmbGlwIHlmbGlwIGFuZHtwb3AgUyBu ZWcgUyBUUiAxODAgcm90YXRlIDEgLTEgc2NhbGUgcHByIDMKZ2V0IHBwciAxIGdldCBuZWcgc3Vi IG5lZyBwcHIgMiBnZXQgcHByIDAgZ2V0IG5lZyBzdWIgbmVnIFRSfWlmIHhmbGlwCnlmbGlwIG5v dCBhbmR7cG9wIFMgbmVnIFMgVFIgcG9wIDE4MCByb3RhdGUgcHByIDMgZ2V0IHBwciAxIGdldCBu ZWcgc3ViCm5lZyAwIFRSfWlmIHlmbGlwIHhmbGlwIG5vdCBhbmR7cHByIDEgZ2V0IG5lZyBwcHIg MCBnZXQgbmVnIFRSfWlmfXsKbm9mbGlwc3tUUiBwb3AgcG9wIDI3MCByb3RhdGUgMSAtMSBzY2Fs ZX1pZiB4ZmxpcCB5ZmxpcCBhbmR7VFIgcG9wIHBvcAo5MCByb3RhdGUgMSAtMSBzY2FsZSBwcHIg MyBnZXQgcHByIDEgZ2V0IG5lZyBzdWIgbmVnIHBwciAyIGdldCBwcHIgMCBnZXQKbmVnIHN1YiBu ZWcgVFJ9aWYgeGZsaXAgeWZsaXAgbm90IGFuZHtUUiBwb3AgcG9wIDkwIHJvdGF0ZSBwcHIgMyBn ZXQgcHByCjEgZ2V0IG5lZyBzdWIgbmVnIDAgVFJ9aWYgeWZsaXAgeGZsaXAgbm90IGFuZHtUUiBw b3AgcG9wIDI3MCByb3RhdGUgcHByCjIgZ2V0IHBwciAwIGdldCBuZWcgc3ViIG5lZyAwIFMgVFJ9 aWZ9aWZlbHNlIHNjYWxlYnk5NntwcHIgYWxvYWQgcG9wIDQKLTEgcm9sbCBhZGQgMiBkaXYgMyAx IHJvbGwgYWRkIDIgZGl2IDIgY29weSBUUiAuOTYgZHVwIHNjYWxlIG5lZyBTIG5lZyBTClRSfWlm fU4vY3B7cG9wIHBvcCBzaG93cGFnZSBwbSByZXN0b3JlfU4gZW5kfWlmfWlmfU4vbm9ybWFsc2Nh bGV7ClJlc29sdXRpb24gNzIgZGl2IFZSZXNvbHV0aW9uIDcyIGRpdiBuZWcgc2NhbGUgbWFnc2Nh bGV7RFZJbWFnIGR1cCBzY2FsZQp9aWYgMCBzZXRncmF5fU4vcHNmdHN7UyA2NTc4MS43NiBkaXYg Tn1OL3N0YXJ0VGV4Rmlney9wc2YkU2F2ZWRTdGF0ZQpzYXZlIE4gdXNlcmRpY3QgbWF4bGVuZ3Ro IGRpY3QgYmVnaW4vbWFnc2NhbGUgdHJ1ZSBkZWYgbm9ybWFsc2NhbGUKY3VycmVudHBvaW50IFRS L3BzZiR1cnkgcHNmdHMvcHNmJHVyeCBwc2Z0cy9wc2YkbGx5IHBzZnRzL3BzZiRsbHggcHNmdHMK L3BzZiR5IHBzZnRzL3BzZiR4IHBzZnRzIGN1cnJlbnRwb2ludC9wc2YkY3kgWC9wc2YkY3ggWC9w c2Ykc3ggcHNmJHgKcHNmJHVyeCBwc2YkbGx4IHN1YiBkaXYgTi9wc2Ykc3kgcHNmJHkgcHNmJHVy eSBwc2YkbGx5IHN1YiBkaXYgTiBwc2Ykc3gKcHNmJHN5IHNjYWxlIHBzZiRjeCBwc2Ykc3ggZGl2 IHBzZiRsbHggc3ViIHBzZiRjeSBwc2Ykc3kgZGl2IHBzZiR1cnkgc3ViClRSL3Nob3dwYWdle31O L2VyYXNlcGFnZXt9Ti9zZXRwYWdlZGV2aWNle3BvcH1OL2NvcHlwYWdle31OL3AgMyBkZWYKQE1h Y1NldFVwfU4vZG9jbGlwe3BzZiRsbHggcHNmJGxseSBwc2YkdXJ4IHBzZiR1cnkgY3VycmVudHBv aW50IDYgMiByb2xsCm5ld3BhdGggNCBjb3B5IDQgMiByb2xsIG1vdmV0byA2IC0xIHJvbGwgUyBs aW5ldG8gUyBsaW5ldG8gUyBsaW5ldG8KY2xvc2VwYXRoIGNsaXAgbmV3cGF0aCBtb3ZldG99Ti9l bmRUZXhGaWd7ZW5kIHBzZiRTYXZlZFN0YXRlIHJlc3RvcmV9TgovQGJlZ2luc3BlY2lhbHtTRGlj dCBiZWdpbi9TcGVjaWFsU2F2ZSBzYXZlIE4gZ3NhdmUgbm9ybWFsc2NhbGUKY3VycmVudHBvaW50 IFRSIEBTcGVjaWFsRGVmYXVsdHMgY291bnQvb2NvdW50IFgvZGNvdW50IGNvdW50ZGljdHN0YWNr IE59Ck4vQHNldHNwZWNpYWx7Q0xJUCAxIGVxe25ld3BhdGggMCAwIG1vdmV0byBocyAwIHJsaW5l dG8gMCB2cyBybGluZXRvIGhzCm5lZyAwIHJsaW5ldG8gY2xvc2VwYXRoIGNsaXB9aWYgaG8gdm8g VFIgaHNjIHZzYyBzY2FsZSBhbmcgcm90YXRlCnJ3aVNlZW57cndpIHVyeCBsbHggc3ViIGRpdiBy aGlTZWVue3JoaSB1cnkgbGx5IHN1YiBkaXZ9e2R1cH1pZmVsc2UKc2NhbGUgbGx4IG5lZyBsbHkg bmVnIFRSfXtyaGlTZWVue3JoaSB1cnkgbGx5IHN1YiBkaXYgZHVwIHNjYWxlIGxseCBuZWcKbGx5 IG5lZyBUUn1pZn1pZmVsc2UgQ0xJUCAyIGVxe25ld3BhdGggbGx4IGxseSBtb3ZldG8gdXJ4IGxs eSBsaW5ldG8gdXJ4CnVyeSBsaW5ldG8gbGx4IHVyeSBsaW5ldG8gY2xvc2VwYXRoIGNsaXB9aWYv c2hvd3BhZ2V7fU4vZXJhc2VwYWdle31OCi9zZXRwYWdlZGV2aWNle3BvcH1OL2NvcHlwYWdle31O IG5ld3BhdGh9Ti9AZW5kc3BlY2lhbHtjb3VudCBvY291bnQgc3Viewpwb3B9cmVwZWF0IGNvdW50 ZGljdHN0YWNrIGRjb3VudCBzdWJ7ZW5kfXJlcGVhdCBncmVzdG9yZSBTcGVjaWFsU2F2ZQpyZXN0 b3JlIGVuZH1OL0BkZWZzcGVjaWFse1NEaWN0IGJlZ2lufU4vQGZlZHNwZWNpYWx7ZW5kfUIvbGl7 bGluZXRvfUIKL3Jse3JsaW5ldG99Qi9yY3tyY3VydmV0b31CL25wey9TYXZlWCBjdXJyZW50cG9p bnQvU2F2ZVkgWCBOIDEKc2V0bGluZWNhcCBuZXdwYXRofU4vc3R7c3Ryb2tlIFNhdmVYIFNhdmVZ IG1vdmV0b31OL2ZpbHtmaWxsIFNhdmVYIFNhdmVZCm1vdmV0b31OL2VsbGlwc2V7L2VuZGFuZ2xl IFgvc3RhcnRhbmdsZSBYL3lyYWQgWC94cmFkIFgvc2F2ZW1hdHJpeAptYXRyaXggY3VycmVudG1h dHJpeCBOIFRSIHhyYWQgeXJhZCBzY2FsZSAwIDAgMSBzdGFydGFuZ2xlIGVuZGFuZ2xlIGFyYwpz YXZlbWF0cml4IHNldG1hdHJpeH1OIGVuZAoKJSVFbmRQcm9jU2V0CiUlQmVnaW5Qcm9jU2V0OiBj b2xvci5wcm8KJSEKVGVYRGljdCBiZWdpbi9zZXRjbXlrY29sb3Igd2hlcmV7cG9wfXsvc2V0Y215 a2NvbG9ye2R1cCAxMCBlcXtwb3AKc2V0cmdiY29sb3J9ezEgc3ViIDQgMSByb2xsIDN7MyBpbmRl eCBhZGQgbmVnIGR1cCAwIGx0e3BvcCAwfWlmIDMgMSByb2xsCn1yZXBlYXQgc2V0cmdiY29sb3Ig cG9wfWlmZWxzZX1CfWlmZWxzZS9UZVhjb2xvcmNteWt7c2V0Y215a2NvbG9yfWRlZgovVGVYY29s b3JyZ2J7c2V0cmdiY29sb3J9ZGVmL1RlWGNvbG9yZ3JleXtzZXRncmF5fWRlZi9UZVhjb2xvcmdy YXl7CnNldGdyYXl9ZGVmL1RlWGNvbG9yaHNie3NldGhzYmNvbG9yfWRlZi9jdXJyZW50Y215a2Nv bG9yIHdoZXJle3BvcH17Ci9jdXJyZW50Y215a2NvbG9ye2N1cnJlbnRyZ2Jjb2xvciAxMH1CfWlm ZWxzZS9EQ3tleGNoIGR1cCB1c2VyZGljdCBleGNoCmtub3due3BvcCBwb3B9e1h9aWZlbHNlfUIv R3JlZW5ZZWxsb3d7MC4xNSAwIDAuNjkgMCBzZXRjbXlrY29sb3J9REMKL1llbGxvd3swIDAgMSAw IHNldGNteWtjb2xvcn1EQy9Hb2xkZW5yb2R7MCAwLjEwIDAuODQgMCBzZXRjbXlrY29sb3J9REMK L0RhbmRlbGlvbnswIDAuMjkgMC44NCAwIHNldGNteWtjb2xvcn1EQy9BcHJpY290ezAgMC4zMiAw LjUyIDAKc2V0Y215a2NvbG9yfURDL1BlYWNoezAgMC41MCAwLjcwIDAgc2V0Y215a2NvbG9yfURD L01lbG9uezAgMC40NiAwLjUwIDAKc2V0Y215a2NvbG9yfURDL1llbGxvd09yYW5nZXswIDAuNDIg MSAwIHNldGNteWtjb2xvcn1EQy9PcmFuZ2V7MCAwLjYxCjAuODcgMCBzZXRjbXlrY29sb3J9REMv QnVybnRPcmFuZ2V7MCAwLjUxIDEgMCBzZXRjbXlrY29sb3J9REMKL0JpdHRlcnN3ZWV0ezAgMC43 NSAxIDAuMjQgc2V0Y215a2NvbG9yfURDL1JlZE9yYW5nZXswIDAuNzcgMC44NyAwCnNldGNteWtj b2xvcn1EQy9NYWhvZ2FueXswIDAuODUgMC44NyAwLjM1IHNldGNteWtjb2xvcn1EQy9NYXJvb257 MCAwLjg3CjAuNjggMC4zMiBzZXRjbXlrY29sb3J9REMvQnJpY2tSZWR7MCAwLjg5IDAuOTQgMC4y OCBzZXRjbXlrY29sb3J9REMvUmVkewowIDEgMSAwIHNldGNteWtjb2xvcn1EQy9PcmFuZ2VSZWR7 MCAxIDAuNTAgMCBzZXRjbXlrY29sb3J9REMvUnViaW5lUmVkewowIDEgMC4xMyAwIHNldGNteWtj b2xvcn1EQy9XaWxkU3RyYXdiZXJyeXswIDAuOTYgMC4zOSAwIHNldGNteWtjb2xvcn1EQwovU2Fs bW9uezAgMC41MyAwLjM4IDAgc2V0Y215a2NvbG9yfURDL0Nhcm5hdGlvblBpbmt7MCAwLjYzIDAg MApzZXRjbXlrY29sb3J9REMvTWFnZW50YXswIDEgMCAwIHNldGNteWtjb2xvcn1EQy9WaW9sZXRS ZWR7MCAwLjgxIDAgMApzZXRjbXlrY29sb3J9REMvUmhvZGFtaW5lezAgMC44MiAwIDAgc2V0Y215 a2NvbG9yfURDL011bGJlcnJ5ezAuMzQgMC45MAowIDAuMDIgc2V0Y215a2NvbG9yfURDL1JlZFZp b2xldHswLjA3IDAuOTAgMCAwLjM0IHNldGNteWtjb2xvcn1EQwovRnVjaHNpYXswLjQ3IDAuOTEg MCAwLjA4IHNldGNteWtjb2xvcn1EQy9MYXZlbmRlcnswIDAuNDggMCAwCnNldGNteWtjb2xvcn1E Qy9UaGlzdGxlezAuMTIgMC41OSAwIDAgc2V0Y215a2NvbG9yfURDL09yY2hpZHswLjMyIDAuNjQg MAowIHNldGNteWtjb2xvcn1EQy9EYXJrT3JjaGlkezAuNDAgMC44MCAwLjIwIDAgc2V0Y215a2Nv bG9yfURDL1B1cnBsZXsKMC40NSAwLjg2IDAgMCBzZXRjbXlrY29sb3J9REMvUGx1bXswLjUwIDEg MCAwIHNldGNteWtjb2xvcn1EQy9WaW9sZXR7CjAuNzkgMC44OCAwIDAgc2V0Y215a2NvbG9yfURD L1JveWFsUHVycGxlezAuNzUgMC45MCAwIDAgc2V0Y215a2NvbG9yfURDCi9CbHVlVmlvbGV0ezAu ODYgMC45MSAwIDAuMDQgc2V0Y215a2NvbG9yfURDL1Blcml3aW5rbGV7MC41NyAwLjU1IDAgMApz ZXRjbXlrY29sb3J9REMvQ2FkZXRCbHVlezAuNjIgMC41NyAwLjIzIDAgc2V0Y215a2NvbG9yfURD Ci9Db3JuZmxvd2VyQmx1ZXswLjY1IDAuMTMgMCAwIHNldGNteWtjb2xvcn1EQy9NaWRuaWdodEJs dWV7MC45OCAwLjEzIDAKMC40MyBzZXRjbXlrY29sb3J9REMvTmF2eUJsdWV7MC45NCAwLjU0IDAg MCBzZXRjbXlrY29sb3J9REMvUm95YWxCbHVlezEKMC41MCAwIDAgc2V0Y215a2NvbG9yfURDL0Js dWV7MSAxIDAgMCBzZXRjbXlrY29sb3J9REMvQ2VydWxlYW57MC45NCAwLjExCjAgMCBzZXRjbXlr Y29sb3J9REMvQ3lhbnsxIDAgMCAwIHNldGNteWtjb2xvcn1EQy9Qcm9jZXNzQmx1ZXswLjk2IDAg MCAwCnNldGNteWtjb2xvcn1EQy9Ta3lCbHVlezAuNjIgMCAwLjEyIDAgc2V0Y215a2NvbG9yfURD L1R1cnF1b2lzZXswLjg1IDAKMC4yMCAwIHNldGNteWtjb2xvcn1EQy9UZWFsQmx1ZXswLjg2IDAg MC4zNCAwLjAyIHNldGNteWtjb2xvcn1EQwovQXF1YW1hcmluZXswLjgyIDAgMC4zMCAwIHNldGNt eWtjb2xvcn1EQy9CbHVlR3JlZW57MC44NSAwIDAuMzMgMApzZXRjbXlrY29sb3J9REMvRW1lcmFs ZHsxIDAgMC41MCAwIHNldGNteWtjb2xvcn1EQy9KdW5nbGVHcmVlbnswLjk5IDAKMC41MiAwIHNl dGNteWtjb2xvcn1EQy9TZWFHcmVlbnswLjY5IDAgMC41MCAwIHNldGNteWtjb2xvcn1EQy9HcmVl bnsxIDAKMSAwIHNldGNteWtjb2xvcn1EQy9Gb3Jlc3RHcmVlbnswLjkxIDAgMC44OCAwLjEyIHNl dGNteWtjb2xvcn1EQwovUGluZUdyZWVuezAuOTIgMCAwLjU5IDAuMjUgc2V0Y215a2NvbG9yfURD L0xpbWVHcmVlbnswLjUwIDAgMSAwCnNldGNteWtjb2xvcn1EQy9ZZWxsb3dHcmVlbnswLjQ0IDAg MC43NCAwIHNldGNteWtjb2xvcn1EQy9TcHJpbmdHcmVlbnsKMC4yNiAwIDAuNzYgMCBzZXRjbXlr Y29sb3J9REMvT2xpdmVHcmVlbnswLjY0IDAgMC45NSAwLjQwIHNldGNteWtjb2xvcn0KREMvUmF3 U2llbm5hezAgMC43MiAxIDAuNDUgc2V0Y215a2NvbG9yfURDL1NlcGlhezAgMC44MyAxIDAuNzAK c2V0Y215a2NvbG9yfURDL0Jyb3duezAgMC44MSAxIDAuNjAgc2V0Y215a2NvbG9yfURDL1Rhbnsw LjE0IDAuNDIgMC41NiAwCnNldGNteWtjb2xvcn1EQy9HcmF5ezAgMCAwIDAuNTAgc2V0Y215a2Nv bG9yfURDL0JsYWNrezAgMCAwIDEKc2V0Y215a2NvbG9yfURDL1doaXRlezAgMCAwIDAgc2V0Y215 a2NvbG9yfURDIGVuZAoKJSVFbmRQcm9jU2V0ClRlWERpY3QgYmVnaW4gMzkxNTgyODAgNTUzODA5 OTYgMTAwMCA2MDAgNjAwIChKVk9RTC5kdmkpCkBzdGFydAolRFZJUFNCaXRtYXBGb250OiBGYSBj bXN5MTAgMTIgMQovRmEgMSAxNiBkZjw0OUI0RkMwMTBGMTNFMDAxM0YxM0Y4OTBCNTEyRkU0ODgw NDgxNTgwNDgxNUMwNDgxNUUwNDgxNUYwQTIKNDgxNUY4QTI0ODE1RkNBMkI3MTJGRUFBNkMxNUZD QTI2QzE1RjhBMjZDMTVGMEEyNkMxNUUwNkMxNUMwNkMxNTgwNkMxNTAwCjZDNUMwMTNGMTNGODAx MEYxM0UwMDEwMTkwQzdGQzI3MjY3QkFCMzI+MTUgRCBFCiVFbmREVklQU0JpdG1hcEZvbnQKJURW SVBTQml0bWFwRm9udDogRmIgY21taTEwIDEwIDEKL0ZiIDEgNjcgZGY8MDEwM0I3N0U0OTE2RjAx OEZDOTAzQjAwMDdGODAwMDNGRTRCRUIwMEZGRjA3RjgwMDIwRkVEM0ZDMDE4CjFGNEIxNUUwQTIx NDFGQTI1REEyMTQzRjE5QzA0QjE0M0YxOTgwMDI3RjE1N0YxOTAwOTJDODEyRkU0RDVBNEE0QTVB RUYwRgpGMDRBRUMxRkMwMDVGRkM3RkM0OUI2MTJGQzVGMDJGQ0M3QjRGQ0VGM0ZDMDAxMDNFRDBG RTA3MTdFNUM3MTdFMTMwNzg0NEEKMTQwMUEyMTMwRjE3MDM1Q0EyMTMxRjRENUE1QzRENUExMzNG NEQ1QTRBNEE1QTRENUEwMTdGNEJDN0ZDNEM1QTkxQzdFQTA3CkZDNDlFQzNGRjBCODEyQzA5NEM4 RkMxNkY4M0IzOTdEQjgzRj42NiBEIEUKJUVuZERWSVBTQml0bWFwRm9udAolRFZJUFNCaXRtYXBG b250OiBGYyBjbWJ4MTIgMTIgMTIKL0ZjIDEyIDEyMCBkZjw5MDM4MDdGRkYwMDE3RjEzRkY0OEI2 MTJDMDNBMDNGQzAwN0ZGMDQ4NkNFQjFGRjg0ODZDRUIwRkZFCjZGN0VBMjZGN0ZBMjZGN0Y2QzVB NkM1QUVBMDBGMDkwQzdGQ0E0NEFCNUZDMTQ3RjAxMDdCNkZDMDEzRjEzQzE5MDM4RkZGOAowMTAw MDMxM0UwNDgxMzgwMzgxRkZFMDA0ODVBNUIxMjdGNUIxMkZGNUJBMzVEQTI2RDVCNkM2QzVCMDAz RjE0MUVEODFGRkUKNDkxM0Y4M0MwRkZGODBGODdGRkZDMDAwMDNFQkZGRjBDNkVDQzAxRjkwMzkw RkZFMDAwNzMyMkM3REFCMzY+OTcKRDxFQzNGRkYwMTAzQjUxMkYwMDEwRjE0RkM5MDM5M0ZGMDAx RkU5MDM5RkZDMDAzRkY0ODQ5NDgxMzgwNDgxMzAwNDg1QTQ4CjVBMTIxRjVCMDAzRjZFMTMwMDZG NUEwMDdGRUMwMDc4NDk5MUM3RkNBMzEyRkZBQTEyN0ZBMjdGQTIxMjNGRUUwM0MwNkM3RQoxNjA3 NkM2QzE1ODA2QzZDMTQwRjZDNkRFQjFGMDA2QzZEMTMzRTZDNkQxM0ZDOTAzOTNGRjgwN0Y4MDEw RkI1MTJFMDAxMDMKMTQ4MDkwMjYwMDNGRjhDN0ZDMkEyQzdDQUIzMj45OSBEPEVDM0ZGQzAxMDNC NTdFMDExRjE0RTA5MDM5M0ZGODFGRjg5MDM5CkZGQzAwN0ZDNDg0OTZDN0U0ODQ5NkM3RTQ4NDg2 RDEzODA0ODQ4MTQ3RjE3QzA0ODVBMDAzRkVEM0ZFMEEyMTI3RjQ5MTVGMApBMjE2MUYxMkZGQTI5 MEI3RkNBMzAxRjBDOUZDQTUxMjdGQTM2QzdFQTIxN0YwNkM3RTAwMEYxNTAxNkM2QzE1RTAxNjAz NkMKNkNFQzA3QzBDNjZERUIxRjgwRDk3RkUwRUI3RjAwOTAzOTNGRkMwM0ZFMDEwRkI1MTJGODAx MDExNEUwOTAyNjAwMUZGRUM3CkZDMkMyQzdEQUIzMz4xMDEgRDw0QUI0RkMwMjFGMTNFMDkxQjUx MkYwMDEwM0VCODNGODkwMzkwN0ZFMEZGQ0Q5MEZGQzEzCkZFOTAzODFGRjgxRjEzM0ZFQjdGRjBB MkVCRkZFMEVEMEZGQ0EyRUQwM0YwOTJDN0ZDQUJCNjEyRjhBNEM2MDFFMEM3RkNCMwpCMjAwN0ZF QkZGRTBBNDI3NDU3REM0MjI+STxFQjdGQzBCNUZDQTQxMjAzN0VCM0VEMDdGRTkyMzgzRkZGQzA5 MkI1MTJGMAo5MTM5QzNGMDNGRjg5MTM5QzdDMDFGRkM5MTM4Q0YwMDBGMDJERTgwMTRGQzRBNkQ3 RUEyNUM1Q0EzNUNCM0E4QjYwMDgzQjUKMTJGRUE0Mzc0NTdDQzQzRT4xMDQgRDxFQjdGQzBCNUZD QTQxMjAzN0VCM0IzQjNBNUI2MTI4MEE0MTk0NTdDQzQyMD4xMDgKRDw5MDI3N0Y4MDA3RkZFQzBG RkVCNTAxM0YwMUMwOTAzODdGRkY4MDkyQjVEOEYwMDFCNTEyRTA5MTNEODFGODFGRkMwM0YwCjNG Rjg5MTNEODdDMDBGRkUwRjgwMUZGQzAwMDM5MDI2OEYwMDA3OTAzODFFMDAwRjZDMDE5RTZFNDg4 MDAyQkM1RDAyQjg2RAo0OTZEN0UxNEY4NEE1REEyNEE1REEyNEE1REIzQThCNjAwODFCNjAwMDNC NTEyRkVBNDU3MkM3Q0FCNUU+STxFQzFGRkM0OQpCNTEyQzAwMTBGMTRGODkwMzkzRkY4MEZGRTkw Mzk3RkMwMDFGRjQ4NDhDN0VBN0ZDMDQ4NDg2RTdFNDg0ODZFN0UwMDBGODIKNDkxNDBGMDAxRjgy QTIwMDNGODI0OTE0MDcwMDdGODJBMzAwRkYxNzgwQUEwMDdGMTcwMEE0NkM2QzRBNUFBMjAwMUY1 RTZDCjZDNEE1QUEyNkM2QzRBNUE2QzZDNEE1QTZDNkQ0OTVBNkM2RDQ4NUI5MDI3M0ZGODBGRkVD N0ZDMDEwRkI1MTJGODAxMDExNApDMDkwMjYwMDFGRkNDOEZDMzEyQzdEQUIzOD4xMTEgRDw5MDM4 N0Y4MDdGQjUzODgxRkZFMDAyODMxM0YwOTEzODhGODdGOAo5MTM4OUYwRkZDMDAwMzkwMzg5RTFG RkU2QzEzQkMxNEI4MTRGODE0RjBBMjkxMzhFMDBGRkNFRDA3RjhFRDAxRTA5MkM3RkMKQTI1Q0Iz QTZCNjEyRTBBNDI3MkM3REFCMkU+MTE0IEQ8OTAzOTFGRkUwMzgwOTBCNTEyQ0YwMDAzMTRGRjM4 MEZGMDAzMzkKMUZDMDAwN0Y0OEM3MTIzRjQ4MTQxRjAwN0UxNDBGQTIwMEZFMTQwN0EyN0U3RjZE OTBDN0ZDMTNGMEVCRkY4MDZDMTNGQ0VDCkZGODA2QzE0RTAxNUY4NkMxNEZFNkM4MDEyMDNDNjE1 ODAwMTNGMTRDMDEzMDFEOTAwMEYxM0UwMTQwMDAwRjAxNDdGMTUzRgo2QzE0MUZBMjE1MEY3RTE2 QzA3RTZDMTQxRjE2ODAwMUMwMTMzRjZERUI3RjAwOTAzOEY4MDFGQzAwRkNCNTVBRDhGMDNGMTMK RTAyNkUwMDdGRUM3RkMyMzJDN0NBQjJDPkk8RUIwMUUwQTUxMzAzQTQxMzA3QTIxMzBGQTIxMzFG QTIxMzNGMTM3RjEzRkYKMTIwMzAwMEY5MEI1MTI4MEI3RkNBM0M2MDFFMEM3RkNCM0E0RUQwMUUw QTkxNTAzRDk3RkYwMTNDMEEyMDEzRkVCMDc4MEVDCkY4MEY5MDM5MUZGQzFGMDA5MDM4MDdGRkZF MDEwMTEzRjg5MDM4MDAzRkUwMjMzRjdFQkUyQz5JPEI1RDhGRTFGQjUzOTgwCjFGRkZGMEE0MDAw MzkwMjdDMDAwN0ZFMEM3RUFGRTAwNkMwMzNGMTU3QzcxMTQ3ODZFMTdGODZDNkY2QzVDNkUxNjAx MDE3Rgo2RTZDNUNBMjZFMDExRjE0MDMwMTNGNkY1QzZFMDEzRjE0MDcwMTFGNkY1Q0EyNkUwMTc5 MTQwRjAxMEYwNDgwOTBDN0ZDNkUKMDFGOTVDNkQwMkYwRUJDMDFFMTU4MDZEOTAyNjgxRTA3RjVC MThFMDAzQzMxNTdDNkQ5MTM5QzAzRkYwNzgxNUU3NkREQTgwCjFGNUIxOEY4MDNGRjE0Rjk2RTkw MzkwMDBGRkRFMDE4RkY2RTQ4NkQ1QkEzNkU0ODZENUJBMjZFNDg2RDkwQzhGQ0EyNEI3RgowMjA3 NURBMjZFNDgxNDdDNEIxNDNDNEMyQzdFQUI1MT4xMTkgRCBFCiVFbmREVklQU0JpdG1hcEZvbnQK JURWSVBTQml0bWFwRm9udDogRmQgY21zeTEwIDEwIDIKL0ZkIDIgMTYgZGY8OTIzODAzRkZDMDAz M0YxM0ZDNEFCNjdFMDIwNzE1RTA0QTQ4QzY2QzdFREEzRkUwRUIwN0ZDNEFDODdFCkQ5MDFGQ0VE M0Y4MDQ5NDg2RjdFRDkwN0UwRUQwN0UwNDk0ODZGN0U0OUNBN0UwMTNFMTc3QzQ5ODM0OTgzNDk4 MzAwMDExOQo4MDQ4NDhFRjA3QzA0OTE3MDMwMDA3MTlFMDQ4NDhFRjAxRjA5MENDRkM0ODE5Rjgw MDFFMTk3OEEyMDAzRTE5N0MwMDNDMTkKM0NBMjAwN0MxOTNFMDA3ODE5MUVBMzAwRjgxOTFGNDgx OTBGQUM2QzE5MUYwMDc4MTkxRUEzMDA3QzE5M0UwMDNDMTkzQ0EyCjAwM0UxOTdDMDAxRTE5NzhB MjAwMUYxOUY4NkMxOUYwNkQxNzAxNkM2Q0VGMDNFMDAwMDMxOUMwNkQxNzA3NkM2Q0VGMEY4MAow MDAwMTkwMDZENUYwMTdDMTczRTZENUY2RDVGRDkwRkMwRUQwM0YwNkQ2QzRCNUFEOTAzRjhFRDFG QzA2RDZDNEI1QUQ5MDAKN0YwM0ZFQzdGQ0RBM0ZFMEVCMDdGQ0RBMEZGRUVCN0ZGMDZFQjY1QTAy MDExNTgwREEwMDNGMDFGQ0M4RkMwMzAzMTNDMDQ4CjRFN0JCQjUzPjEzIEQ8RUIxRkYwRUI3RkZD NDhCNUZDNDgxNDgwNDgxNEMwNDgxNEUwNDgxNEYwNDgxNEY4QTI0ODE0RkNBMwpCNjEyRkVBODZD MTRGQ0EzNkMxNEY4QTI2QzE0RjA2QzE0RTA2QzE0QzA2QzE0ODA2QzE0MDAzODAwN0ZGQ0VCMUZG MDFGMjAKN0JBNDJBPjE1IEQgRQolRW5kRFZJUFNCaXRtYXBGb250CiVEVklQU0JpdG1hcEZvbnQ6 IEZlIGNtdHQxMCAxMCA2OQovRmUgNjkgMTI1IGRmPDEyMUMxMjdGRUFGRjgwQjFFQTdGMDBBRjEy M0VDN0ZDQTgxMjFDMTI3RkEyRUFGRjgwQTNFQTdGMDAKQTIxMjFDMDkzNDZGQjMyQz4zMyBEPEVC MEZDMEVCM0ZFMDQ5N0U0OTdFODBFQTAxRjhFQkYwN0MxNDdFMDAwMzEzM0UxM0UwCkE1MTQ3RTE0 N0M5MTM4RkMzRkY4OTAzOUYwRjg3RkZDRUEwMUYxRUJGM0YwMDFGN0VCM0ZGODkxMzhFMDFGMDA5 MDM4RkZDMAozRjZDRUI4MDNFQTJFQzAwN0U0OTEzN0M0ODVBNDg2QzEzRkMwMDA3NUNFQkZGMDFE ODBGREY1QjM4MUY5RjgxMzgzRjhGODMKOTAzODBGQzNFMDM4N0UwN0U3NUQzOEZDMDNGN0VCMDFG RjVENkQxNDEwRUQwMDdDODBBMjZDRUJGRjgwRDg3RTAxMTNDMEQ4CjdGMDNFQkUwRkMzQTNGODdG N0YxRjg5MDM4RkZFM0ZGNkMwMUMxMTNGMDZDMTM4MDZDOTAzODAwN0ZDMEQ4MDFGQ0VCMUY4MAoy NjM1N0VCMzJDPjM4IEQ8MTQzODE0RkMxMzAxMTMwM0VCMDdGOEVCMEZGMEVCMUZDMEVCM0Y4MEVC N0YwMDEzRkU0ODVBNDgKNUE1QjEyMDc1QjEyMEY1QjQ4NUFBMjEyM0Y5MEM3RkNBMjVBMTI3RUEz MTJGRTVBQUM3RTEyN0VBMzEyN0Y3RUEyN0YxMjFGCkEyNkM3RTdGMTIwNzdGMTIwMzdGNkM3RTZD N0UxMzdGRUIzRjgwRUIxRkMwRUIwRkYwRUIwN0Y4RUIwM0ZDMTMwMTEzMDAxNAozODE2NDI3MkI5 MkM+NDAgRDwxMjcwMTJGQzdFN0U2QzdFNkM3RUVBMEZFMDZDN0U2QzdFNkM3RTZDN0UxMzdGN0Yx NDgwMTMKMUYxNEMwMTMwRkVCMDdFMEEyMTRGMDEzMDNBMjE0RjgxMzAxQTMxNEZDMTMwMEFDMTMw MTE0RjhBMzEzMDMxNEYwQTIxMzA3CjE0RTBBMkVCMEZDMDEzMUYxNDgwMTMzRjE0MDA1QjEzRkU0 ODVBNDg1QTQ4NUE0ODVBRUEzRkMwNDg1QTQ4QzdGQzVBNUExMgo3MDE2NDI3OUI5MkM+STxFQjAz ODA0OTdFQTYwMDIwMTQwODAwRjgxNDNFMDBGRTE0RkUwMEZGMTNDMUVCQzdDN0VCRTdDRgowMDNG QjUxMkY4MDAwRjE0RTAwMDAzMTQ4MDZDMTQwMDM4MDA3RkZDQTI0OEI1RkM0ODE0ODAwMDBGMTRF MDAwM0YxNEY4MzkKRkZFN0NGRkVFQkM3QzdFQjA3QzEwMEZFMTNDMDAwRjgxNDNFMDAyMDE0MDgw MDAwMTQwMEE2NkQ1QTFGMjQ3QUFBMkM+STwKRUEwRjgwRUExRkUwRUEzRkYwRUE3RkY4QTIxM0ZD QTMxMjNGMTIxRjEyMEYxMjAwMTNGOEEyMTIwMUVBMDNGMDEyMDdFQTFGCkUwRUE3RkMwRUFGRjgw MTMwMDEyRkMxMjcwMEUxNzcxOEEyQz40NCBEPDAwN0ZCNkZDQjcxMjgwQTQ2QzE1MDAyMTA2N0I5 QgoyQz5JPDEyMUZFQTNGODBFQTdGQzBFQUZGRTBBNUVBN0ZDMEVBM0Y4MEVBMUYwMDBCMEI3MDhB MkM+STwxNTA3RUQwRjgwMTUKMUZBMjE1M0YxNjAwNUQxNTdFMTVGRTVEMTQwMTVEMTQwMzVEQTIx NDA3NUQxNDBGNUQxNDFGNUQxNDNGOTJDN0ZDNUMxNDdFCjE0RkU1Q0EyMTMwMTVDMTMwMzVDMTMw NzVDMTMwRjVDMTMxRjVDQTIxMzNGOTFDOEZDNUIxMzdFMTNGRTVCMTIwMTVCMTIwMwo1QjEyMDc1 QkEyMTIwRjVCMTIxRjVCMTIzRjkwQzlGQzVBMTI3RTEyRkU1QUEyNUExMjc4MjE0MTdCQjkyQz5J PEVCMDNGOApFQjBGRkU5MDM4M0ZGRjgwNDk3RjkwQjU3RTM5MDFGRTBGRjAzOTAzRjgwM0Y4NDg0 ODZDN0VFQkUwMDA0ODQ4MTM3RUEyNDgKNDg3RkEyNDhDN0VBMUY4MEEyMDAzRTE0MEYwMDdFMTVD MEEzMDA3QzE0MDcwMEZDMTVFMEFDNkMxNDBGMDA3RTE1QzBBNDZDCkVDMUY4MEEzNkM2Q0VCM0Yw MEEyNkM2QzEzN0U2RDEzRkUwMDA3NUNFQkYwMDE2QzZDNDg1QTM5MDFGRTBGRjA2Q0I1NUE2RAo1 QjZENUJEOTBGRkVDN0ZDRUIwM0Y4MjMzNTdDQjMyQz5JPDEzMDc0OTdFQTIxMzFGQTIxMzNGMTM3 RjEzRkY1QTEyMDcxMgo3RkI1RkMxM0RGMTM5RkVBN0MxRjEyMDBCM0FFMDA3RkI1MTJFMEI2MTJG MEEzNkMxNEUwMUMzNDc3QjMyQz5JPEVCMEZGOAo5MDM4N0ZGRjgwNDhCNTEyRTAwMDA3ODA0ODE0 RkMzOTFGRjgwRkZFMzkzRkUwMDFGRjkwMzg4MDAwN0Y0OEM3RUEzRjgwMDAKN0UxNDFGMDBGRTE1 QzAxNTBGNkMxNUUwMTUwN0EzMTI3RTEyM0NDOEZDQTIxNTBGMTZDMDE1MUYxNjgwMTUzRjE2MDA1 RDE1CkZFNEE1QTE0MDM0QTVBNEE1QTRBNUE0QTVBRUNGRjgwNDk0OEM3RkM0OTVBNDk1QTQ5NUFF QjNGRTBFQjdGODA0OUM4RkM0OAo1QTQ4NDhFQjAzQzA0ODQ4RUIwN0UwRUExRkUwNDg1QTQ4QjZG Q0I3RkNBMzZDMTVDMDIzMzQ3Q0IzMkM+STxFQjBGRkM5MAozODdGRkY4MDQ4QjUxMkUwMDAwNzE0 Rjg0ODgwMzkxRkY4MDdGRUVCQzAwMDQ4NDgxMzdGNkQ3RjE2ODAxNTFGQTI2QzVBNkMKQzdGQ0M4 RkMxNTNGMTYwMDVEMTVGRTE0MDE0QTVBRUMxRkY4OTAzODFGRkZGMDQ5NUJBMjE1Rjg2RDdGOTAz ODAwMDdGRUVDCjAwRkY4MUVEM0Y4MEVEMUZDMDE1MEZBMjE2RTAxNTA3QTIxMjNDMTI3RUI0RkMx NTBGMTZDMEEyNDgxNDFGMDA3RkVDM0Y4MAo2REVCN0YwMDZDNkM1QjM5MUZGODA3RkU2Q0I1NUE2 QzVDNkMxNEUwQzY2QzEzODBEOTBGRkNDN0ZDMjMzNTdDQjMyQz5JPAowMDBGQjUxMkZFNDg4MEEz NUQwMTgwQzhGQ0FERUI4M0ZFOTAzODlGRkY4MDkwQjUxMkUwMTVGODgxOTAzOEZFMDNGRTkwMzgK RjAwMEZGMDFDMDdGNDlFQjNGODA5MEM3MTIxRjZDMTVDMEM4MTIwRkEyRUQwN0UwQTQxMjNDMTI3 RUI0RkMxNTBGMTZDMEEyCjQ4MTQxRjAwN0VFQzNGODAwMDdGRUM3RjAwNkM2QzVCNkQ0ODVBMzkx RkY4MEZGQzZDQjU1QTZDNUMwMDAxMTRDMDZDNkM5MApDN0ZDRUIwRkY4MjMzNDdDQjIyQz41MyBE PEVDM0ZDMDkwMzgwMUZGRjgwMTA3N0YwMTFGN0Y0OTdGOTAzODdGRTA3RjkwMzkKRkYwMDNGODA0 ODQ4MTM3RkVBMDNGODQ4NUE1QjAwMEZFQzNGMDA0ODQ4MTMxRTQ5OTBDN0ZDMTIzRjkwQzlGQ0Ey NUExMjdFCkVCMDNGRTkwMzgxRkZGODBEOEZDN0YxM0UwMDBGREI1N0VCNjdFOTAzOEZFMDdGQzkw MzhGMDAxRkU5MDM4QzAwMDdGNDlFQgozRjgwOTBDNzEyMUYxNkMwNDgxNDBGMTZFMDE1MDdBMzEy N0VBNDdFMTUwRjZEMTRDMDAwMUYxNDFGNkQxNDgwMDAwRjE0M0YKNkRFQjdGMDAzOTA3RjgwMUZF MzkwM0ZFMDdGQzZDQjU1QTZDNUM2RDVCMDExRjEzODBEOTA3RkNDN0ZDMjMzNTdDQjMyQz4KSTwx MjFGRUEzRjgwRUE3RkMwRUFGRkUwQTVFQTdGQzBFQTNGODBFQTFGMDBDN0ZDQUUxMjFGRUEzRjgw RUE3RkMwRUFGRkUwCkE1RUE3RkMwRUEzRjgwRUExRjAwMEIyNDcwQTMyQz41OCBEPDE1MDdFRDFG ODAxNTNGMTVGRjE0MDM0QTEzMDBFQzFGRkM0QQo1QUVDRkZFMDQ5MTM4MDAxMDc5MEM3RkNFQjBG RkNFQjNGRjhFQjdGRTA0ODQ4NUE0ODkwQzhGQ0VBMEZGRUVBMUZGOEVBN0YKRjBFQUZGQzA1QkEy N0ZFQTdGRjBFQTFGRjhFQTBGRkVFQTAzRkY2QzEzQzA2QzZDN0VFQjNGRjhFQjBGRkM2REI0RkMw MTAxCjdGNkQxM0UwRUMzRkY4NkU3RUVDMDdGRjZFMTM4MDE0MDAxNTNGMTUxRkVEMDcwMDIxMkE3 QkFEMkM+NjAKRDwwMDdGQjYxMkYwQjcxMkY4QTQwMDNGMTVGMENBRkNBODAwM0ZCNjEyRjBCNzEy RjhBNDZDMTVGMDI1MTQ3REEyMkM+STwKMTI3MDEyRkM3RTZDN0UxM0UwNkM3RUVBMUZGQzZDN0Uz ODAzRkY4MEM2N0ZFQjdGRjBFQjFGRjhFQjBGRkVFQjAzRkY2RDEzCkMwNkQ2QzdFRUMzRkY4RUMw RkZDNkVCNEZDMDIwMTEzODA4MEEyNUMwMjA3MTMwMEVDMEZGQ0VDM0ZGOEVDN0ZFMDQ5NDg1QQo0 OTkwQzdGQ0VCMEZGRUVCMUZGOEVCN0ZGMEVCRkZDMDAwMDM1QkQ4MEZGRUM4RkM0ODVBRUE3RkYw NDg1QTEzODA0OEM5RkMKNUExMjcwMjEyQTdCQUQyQz5JPDE0RkU0OTdFQTQ0OTdGQTIxNEVGQTIx MzA3ODFBMjE0QzdBMjAxMEY3RkEzMTQ4MzAxMUYKN0ZBNTkwMzgzRjAxRjhBNDkwMzg3RTAwRkNB NTQ5MTM3RTkwQjUxMkZFQTM0ODgwQTI5MDM4RjgwMDNGQTM0ODQ4RUIxRjgwCkE0MDAwNzE1QzA0 OTEzMEZEODdGRkVFQkZGRkM2RDVBQjUxNEZFNkMxNUZDNDk3RTI3MzQ3RUIzMkM+NjUKRDwwMDdG QjUxMkUwMTVGOEI2MTJGRTZDODAxNkMwMzkwM0YwMDAzRkVEMEZFMEVEMDdGMDE1MDNBMkVEMDFG OEE2RUQwM0YwCkEyMTUwN0VEMEZFMEVEMUZDMEVERkY4MDkwQjYxMjAwNUQ1RDE1RkYxNkMwOTAz OUYwMDAxRkUwRUQwN0YwRUQwM0Y4MTUwMQpFRDAwRkNBMjE2RkUxNjdFQTYxNkZFMTZGQzE1MDFF RDAzRjgxNTBGRUQzRkYwMDA3RkI2MTJFMDE2QzBCNzEyODA2Q0VDRkUKMDAxNUYwMjczMzdGQjIy Qz5JPDAyRkYxMzcwMDEwN0VCRTBGODQ5MTNGOTAxM0YxM0ZENDkxM0ZGRUJGRjgxMzkwMUZFMDAK N0Y0ODQ4MTMxRkQ4MDdGMDEzMEYxNTA3NDg1QTQ5MTMwMzQ4NUExNTAxNDhDN0ZDQTI1QTAwN0VF QzAwRjAxNjAwQTIxMkZFCjVBQUI3RTEyN0VBMzAwN0YxNUYwNkNFQzAxRjhBMjZDN0VBMjZDNkMx MzAzNkQxNEYwNkM2QzEzMDcxNkUwRDgwM0ZDMTMxRgo2QzZDRUIzRkMwM0EwMEZGODFGRjgwNkRC NTEyMDA2RDVCMDEwRjVCNkQxM0YwMDEwMDEzODAyNTM1N0RCMzJDPkk8MDA3RgpCNUZDQjYxMkMw MTVGMDgxNkM4MDM5MDdFMDAzRkVFQzAwRkZFRDdGODAxNTNGRUQxRkMwRUQwRkUwQTIxNTA3MTZG MDE1MDMKMTZGODE1MDFBNEVEMDBGQ0FDRUQwMUY4QTMxNTAzMTZGMEEyMTUwNzE2RTAxNTBGRUQx RkMwMTUzRkVEN0Y4MEVERkYwMEVDCjAzRkUwMDdGQjU1QUI2NUE1RDE1QzA2QzkxQzdGQzI2MzM3 RUIyMkM+STwwMDdGQjYxMkYwQjcxMkY4QTM3RTM5MDNGMDAwCjAxQTdFRDAwRjAxNjAwQTRFQzAx RTA0QTdFQTQ5MEI1RkNBNUVCRjAwM0E0NkU1QTkxQzhGQ0E1MTYzQzE2N0VBODAwN0ZCNgoxMkZF QjdGQ0EzNkMxNUZDMjczMzdFQjIyQz5JPDAwN0ZCNjEyRjhCNzEyRkNBMzdFRDgwM0YwQzdGQ0E3 MTY3ODE2MDBBNQoxNUYwNEE3RUE0OTBCNUZDQTVFQkYwMDFBNDZFNUE5MkM3RkNBRDM4N0ZGRkUw QjVGQzgwNUM3RTI2MzM3RUIyMkM+STw5MAozOTAxRkMwMzgwOTAzOTBGRkY4N0MwNDkxM0VGMDE3 RjEzRkY5MEI2RkM0ODEzMDczODAzRkMwMTQ5N0U0ODQ4MTM3RjQ4NDgKMTMzRjQ5MTMxRjEyMUY1 QjAwM0YxNDBGOTBDN0ZDQTIxMjdFRUQwNzgwOTJDN0ZDQTIxMkZFNUFBODkxMzgwM0ZGRjg0QTEz CkZDQTI3RTAwN0U2RDEzRjg5MTM4MDAwRkMwQTM2QzE0MUZBMjdGMTIxRjZEMTMzRjEyMEY2RDEz N0Y2QzdFNkM2QzEzRkY2RAo1QTM4MDFGRjA3NkM5MEI1RkM2RDEzRUYwMTFGMTNDRjZERUIwNzgw RDkwMUZDQzdGQzI2MzU3REIzMkM+STxEODdGRkVFQgpGRkZDQjU0ODEzRkVBMzZDNDg2QzEzRkNE ODA3RTBFQjBGQzBCMTkwQjZGQ0E1OTAzOEUwMDAwRkIzRDg3RkZFRUJGRkZDQjUKNDgxM0ZFQTM2 QzQ4NkMxM0ZDMjczMzdFQjIyQz5JPDAwN0ZCNTEyRjhCNjEyRkNBMzZDMTRGODM5MDAwRkMwMDBC M0IzQTUKMDA3RkI1MTJGOEI2MTJGQ0EzNkMxNEY4MUUzMzc5QjIyQz5JPEQ4N0ZGQ0VCN0ZGODQ4 NkNFQkZGRkNBMzZDNDhFQjdGRjgKRDgwN0MwRUIxRjgwMTUzRkVEN0YwMDE1N0U1RDRBNUExNDAz NEE1QTVENEE1QTRBNUExNDNGNEFDN0ZDMTQ3RTVDRUJDMUY4CjEzQzNFQkM3RkNBMkVCQ0ZGRUVC REZCRUVCRkZCRjE0MUYwMUZFN0Y0OTZDN0UxM0Y4NkU3RUVCRjAwMzAxRTA3RkVCQzAwMQo4MTZF N0VBMjE1N0UxNTNFMTUzRjgxMTY4MEVEMEZDMEEyRUQwN0UwRDg3RkZDRUIxRkZDNDg2Q0VCM0ZG RUEzNkM0OEVCMUYKRkMyNzMzN0VCMjJDPjc1IEQ8Mzg3RkZGRTBCNTdFQTM2QzVCRDgwM0YwQzhG Q0IzQUUxNkYwRUQwMUY4QTgwMDdGQjZGQ0I3CkZDQTM2QzE1RjAyNTMzN0RCMjJDPkk8RDg3RkUw RUIwRkZDNDg2Q0VCMUZGRUEyNkQxMzNGMDA3RjE1RkMwMDBGMTVFMDAxCkJDMTM3QkE0MDE5RTEz RjNBM0VCOUYwMUEyMDE4RjEzRTNBMjE0ODNBMjAxODcxM0MzMTRDN0EyMDE4MzEzODNBMzE0RUYw MQo4MTEzMDNBMjE0RkZFQjgwRkVBMzE0N0MxNDM4MTQwMEFDRDg3RkYwRUIxRkZDNDg2Q0VCM0ZG RUEzNkM0OEVCMUZGQzI3MzMKN0VCMjJDPkk8RDg3RkYwRUI3RkZDNDg2Q0VCRkZGRUEyN0YwMDdG RUM3RkZDRDgwN0ZFRUIwN0MwMTNERUEyMTNERjEzQ0YKQTIxNDgwMTNDNzE0QzBBMjEzQzMxNEUw QTIxM0MxMTRGMEEyMTNDMDE0RjhBMjE0N0NBMzE0M0VBMjE0MUUxNDFGQTIxNDBGCjE1ODdBMjE0 MDcxNUM3QTIxNDAzMTVFNzE0MDFBMjE1RjcxNDAwQTIxNUZGRDg3RkZDMTM3RjQ4N0UxNTNGQTI2 QzQ4RUIxRgo4MDI3MzM3RUIyMkM+STxFQjdGRkYwMDAzQjUxMkUwMDAwRjE0Rjg0ODgwNDg4MEVC RTAwM0VCODAwMDQ4QzcxMjdGQTIwMAo3RTgwQTMwMEZFMTU4MDQ4MTQxRkIzQTg2QzE0M0ZBMjAw N0UxNTAwQTMwMDdGNUNBMjZDNkMxM0ZFRUJGMDA3OTBCNUZDNkMKNUM2QzVDMDAwMzE0RTBDNjZD OTBDN0ZDMjEzNTdCQjMyQz5JPDAwN0ZCNTEyQzBCNjEyRjg4MTE1RkY2QzE1ODAyNjAzRjAKMDAx M0MwMTUzRkVEMEZFMEVEMDdGMEEyMTUwMzE2RjgxNTAxQTYxNTAzMTZGMDE1MDdBMkVEMEZFMEVE M0ZDMDE1RkY5MEI2CjEyODAxNjAwMTVGQzVEMTVDMDAxRjBDOEZDQjAzODdGRkY4MEI1N0VBMzZD NUIyNTMzN0VCMjJDPkk8Mzg3RkZGRkNCNjdFCjE1RTAxNUY4NkM4MDM5MDdFMDA3RkUxNDAxRUMw MDdGNkY3RTE1MUZBMjZGN0VBNjRCNUFBMjE1M0Y0QkM3RkNFQzAxRkUxNAowNzkwQjU1QTVEMTVF MDgxODE5MDM4RTAwN0ZDRUMwMUZFMTQwMDE1N0Y4MUE4MTYwRkVFMUY4MEE1RDg3RkZFRUIxRkJG QjUKRUNGRjAwODE1RTZDNDg2RDVBQzhFQTAxRjAyOTM0N0VCMjJDPjgyIEQ8OTAzODFGRjgwNzkw QjVFQTBGODA0ODE0Q0YwMDA3CjE0RkY1QTM4MUZGMDFGMzgzRkMwMDM0OTdFNDhDN0ZDMDA3RTE0 N0YwMEZFMTQzRjVBMTUxRkE0NkNFQzBGMDAwMDdFOTFDNwpGQzEyN0Y3RkVBM0ZFMEVBMUZGQ0VC RkZDMDZDMTNGQzAwMDNFQkZGQzA2QzE0RjA2QzZDN0YwMTA3N0Y5MDM4MDA3RkZFRUMKMDdGRjAy MDAxMzgwMTUzRkVEMUZDMEEyRUQwRkUwQTIwMDc4MTQwNzEyRkNBNTZDRUMwRkMwQTI2Q0VDMUY4 MDZEMTMzRjAxCkUwRUI3RjAwOTAzOEZFMDFGRjkwQjU1QTVEMDBGOTE0RjBEOEY4M0YxM0MwRDg3 MDA3OTBDN0ZDMjMzNTdDQjMyQz5JPDAwCjdGQjYxMkZDQjcxMkZFQTQzQUZDMDA3RTAwN0VBNzAw NzgxNTNDQzcxNDAwQjNBRjkwMzgzRkZGRkNBMjQ5N0Y2RDVCQTIyNwozMzdFQjIyQz5JPDNCN0ZG RjgwM0ZGRkMwQjU2QzQ4MTNFMEEzNkM0OTZDMTNDMDNCMDNGMDAwMDFGODAwQjNBRjZEMTMwMwow MDAxNURBMjZEMTMwNzAwMDA1RDZEMTMwRjAxN0Y0OTVBNkQ2QzQ4NUFFQ0UwRkY2REI1QzdGQzZE NUIwMTAzMTNGODZENUIKOTAzODAwM0Y4MDJCMzQ4MEIyMkM+STxEODdGRkNFQjdGRkM0ODZDRUJG RkZFQTM2QzQ4RUI3RkZDRDgwRkMwRUIwN0UwNkQKMTMwRjAwMDcxNUMwQTM2RDEzMUYwMDAzMTU4 MEEzNkQxMzNGMDAwMTE1MDBBMzZENUIwMDAwMTQ3RUE0MDE3RTVCQTQ2RDQ4CjVBQTQ5MDM4MUY4 M0YwQTQwMTBGNUIxNEM3QTMwMTA3NUJBMjE0RUZBMjAxMDM1QkEyMTRGRkEyNkQ5MEM3RkNBNDZE NUEyNwozNDdFQjIyQz5JPEQ4N0ZGMEVCMDdGRjQ4NkM0OTEzODBBMzZDNDg2RDEzMDAwMDFGQzgx MjdDQTQ2QzZDNUNBNzZDNkM0OQo1QUE0MTQzRTE0N0ZBMzNBMDNFMEZGODNFMEEyMTRGN0EyMDFF MTEzQzNBMzAwMDEwMUUzNUJBMjAxRjExM0M3MDFGMzEzRTcKQTMxNEMxQTIwMDAwNURBMjAxRjcx M0Y3MTQ4MEEzMDFGRjEzRkYwMTdGOTFDN0ZDNEE3RUE0MDEzRTEzM0UyOTM0N0ZCMjJDCj5JPDNB M0ZGRjAzRkZFMDQ4NDkxM0YwMTQ4NzE0MDc2QzZEMTNFMDNBMDFGODAwRkUwMDdGMDAwMDQ5NUEx M0ZFMDE3RTVCCkVCN0YwMzAxM0Y1QjE0ODcwMTFGNUIxNENGMDEwRjVCMTRGRjZENUJBMjZEOTBD N0ZDQTI2RDVBQTI2RDVBQTI0OTdFQTI0OQo3RUEyNDk3RjgxRUIwRkNGODFFQjFGQzdFQzg3RjBF QjNGODNFQzAzRjhFQjdGMDEwMTdFN0ZFQkZFMDA0OTdGMDAwMTE0N0UKNDkxMzdGMDAwMzgwNDkx NDgwMTUxRkQ4N0ZGRUVCRkZGQzZENUFCNTE0RkU2QzE1RkM0OTdFMjczMzdFQjIyQz5JPEQ4N0YK RkNFQjdGRkM0ODZDRUJGRkZFQTM2QzQ4RUI3RkZDRDgwN0YwRUIwRkMwMTUxRjAwMDMxNTgwNkQx MzNGMTIwMTZERUI3RjAwCjEyMDA2RDEzN0UwMTdFMTNGRTAxN0Y1QkVCM0YwMUVDODFGODEzMUZF QzgzRjBFQjBGQzMxNEM3OTAzODA3RTdFMEEyMDEwMwo1QjE0RUY2REI0NUFBMjkyQzdGQzdGNUMx NDdFQjA5MDM4MDdGRkUwNDk3RkEzNkQ1QjI3MzM3RUIyMkM+STwzODdGRkZGQwpCNTEyRkVBMzE0 RkMwMEZDQzdGQ0IzQjNCM0I1MTJGQzE0RkVBMzZDMTNGQzE3NDE2RkI5MkM+OTEKRDwzODdGRkZG Q0I1MTJGRUEzN0VDNzEyN0VCM0IzQjMzODdGRkZGRUI1RkNBMzZDMTNGQzE3NDE3REI5MkM+OTMK RDwwMDdGQjZGQ0I3MTI4MEE0NkMxNTAwMjEwNjdCN0QyQz45NSBEPDM4MDFGRkYwMDAwNzEzRkUw MDFGNkQ3RTE1RTA0ODgwCjkwMzhDMDFGRjgxNDA3RUMwMUZDMzgxRjgwMDAwMDA2Qzc3RUM4MTI3 RUEzRUNGRkZFMTMxRjkwQjVGQzEyMDMxMjBGNDhFQgo4MDdFMzgzRkY4MDBFQTdGQzA5MEM3RkMx MkZFNUFBNDdFMDA3RjE0RkVFQjgwMDMzODNGRTAxRjZDQjYxMkZDNkMxNUZFNkMKMTRCRjAwMDFF QkZFMUYzQTAwM0ZGMDA3RkMyNzI0N0NBMzJDPjk3IEQ8RUE3RkYwNDg3RUEzMTI3RjEyMDFBQUVD MUZFMEVDCkZGRjgwMUZCMTNGRTkwQjZGQzE2ODA5MTM4RjA3RkMwOTEzODgwMUZFMDkxMzgwMDA3 RjA0OUVCMDNGODVCRUQwMUZDNDkxMwowMEEyMTZGRTE2N0VBODE2RkU2RDE0RkNBMkVEMDFGODZE MTMwMzZERUIwN0YwMTUwRjkxMzg4MDFGRTA5MTM4RTA3RkMwOTEKQjUxMjgwMTYwMDAxRkI1QjAx RjgxM0Y4MzkwMEYwM0ZDMDI3MzM3RkIyMkM+STw5MDM4MDNGRkUwMDExRjEzRjgwMTdGMTMKRkU0 OEI1RkM0ODgwNDg0OEM2RkNFQTBGRjA0ODVBNDkxMzdFNDg0ODEzMTg5MEM5RkM1QTEyN0VBMjVB QTgxMjdFQTIxMjdGCjZDMTQwRjZERUIxRjgwNkM3RTZEMTMzRjZDNkNFQjdGMDAzOTA3RkUwM0ZG NkNCNTVBNkM1QzZDNkM1QjAxMUYxM0UwMDEwMwo5MEM3RkMyMTI0N0FBMzJDPkk8RUMwRkZFNEE3 RUEzODBFQzAwM0ZBQUVCMDdGOEVCM0ZGRTkwQjUxMkJGNDgxNEZGNUEzOAowN0ZDMEYzODBGRjAw MzQ4NDg3RTQ5N0U0ODQ4N0Y5MEM3RkMwMDdFODBBMjEyRkU1QUE4N0UwMDdFNUNBMjAwN0Y1QzZD N0UKNUM2QzZDNUEzODBGRjAwNzM4MDdGQzFGNkNCNjEyRkM2Q0VDQkZGRTZDMTQzRkVCM0ZGQzkw MzkwRkYwMUZGQzI3MzM3REIyCjJDPkk8RUIwM0ZFOTAzODFGRkZDMDAxN0YxM0YwNDhCNTdFNDg4 MDM5MDdGRTAzRkUzOTBGRjgwMEZGRDgxRkUwRUIzRjgwCjVCNDg0OEVCMUZDMDkwQzcxMjBGNUEw MDdFMTVFMDE1MDc1QUI3RkNBNDE2QzAwMEZDQzlGQzdFMTI3RUEyMTI3RjZDRUMwMwpDMDZERUIw N0UwNkM3RUQ4MEZGMDEzMEY2QzZDRUIzRkMwMDFGRjEzRkYwMDAxOTBCNTEyODA2QzE1MDAwMTNG MTNGQzAxMEYKMTNGMDAxMDExMzgwMjMyNDdDQTMyQz5JPEVDMEZGOEVDM0ZGRTkxQjVGQzQ5MTQ4 MDVCOTAzODA3RkM3RjE0RjA5MDM5MEYKRTAzRjAwMTRDMDkyQzdGQ0E2MDA3RkI1MTJGRUI3RkNB MzZDNUMyNjAwMEZDMEM3RkNCM0E4MDAzRkI1MTJGMDQ4ODBBMzZDCjVDMjEzMzdEQjIyQz5JPEVE MDNGODkwMzkwN0Y4MEZGQzkwMzkxRkZFM0ZGRTAxN0ZCNkZDNDhCN0ZDNDhFQ0ZFN0Y5MDM4CkZD MEZGODI2MDdGMDAzMTMzRTNBMEZFMDAxRkMxQ0Q5QzAwMDEzMDAwMDFGODA0OTEzN0VBNjZEMTNG RTAwMEY1Q0VCRTAwMQo2QzZDNDg1QTM5MDNGQzBGRjA0OEI1RkM1RDQ4MTQ4MEQ5OUZGRUM3RkNF Qjg3RjgwMTgwQzhGQ0EzN0Y2QzdFOTBCNTEyRjAKNkMxNEZFNDhFQ0ZGODA0ODE1RTA0ODE1RjAz QTNGQzAwMDFGRjg0OEM3RUEwM0ZDMDA3RTE0MDAwMDdDMTU3QzAwRkMxNTdFCjQ4MTUzRUE0NkMx NTdFMDA3RTE1RkNEODdGODAxMzAzRDgzRkUwRUIwRkY4RDgxRkZDRUI3RkYwNkNCNjEyRTAwMDAz MTU4MAo2QzE1MDBEODAwM0YxM0Y4MDEwNzEzQzAyODM4N0VBNDJDPkk8RUE3RkYwNDg3RUEzMTI3 RjEyMDFBQUVDMUZFMEVDN0ZGQwo5MDM4RjlGRkZFMDFGQjdGOTBCNkZDOTEzOEYwM0Y4MEVDQzAx RjAyODA3RkVDMDAwRjVCNUJBMjVCQjMyNjdGRkZFMEI1RkMKQjUwMEYxMTQ4MEEzNkMwMUUwMTQw MDI5MzM3RkIyMkM+STwxMzA3RUIxRkMwQTI0OTdFQTM2RDVBQTIwMTA3QzdGQzkwQzgKRkNBNzM4 N0ZGRkMwODBCNUZDN0VBMkVBMDAwN0IzQTgwMDdGQjUxMkZDQjYxMkZFQTM2QzE0RkMxRjM0NzlC MzJDPkk8MTQKMEVFQzNGODBBMkVDN0ZDMEEzRUMzRjgwQTJFQzBFMDA5MUM3RkNBNzQ4QjUxMjgw NDgxNEMwQTM3RUM3MTIwRkIzQjNBMjE0CjFGMDAzQzE0ODAwMDdFMTMzRkI0MTQwMDVDRUIwMUZF RUJGRkZDNkM1QjVDMDAxRjVCMDAwNzkwQzdGQzFBNDY3Q0IzMkM+Ckk8Mzg3RkZGRTBCNTdFQTM3 RUVBMDAwM0IzQjNBNTAwN0ZCNjEyODBCNzEyQzBBMzZDMTU4MDIyMzM3QkIyMkM+MTA4CkQ8M0E3 RjgzRjAwN0UwOTAzOUNGRkMxRkY4M0FGRkRGRkUzRkZDRDg3RkZGMTNGRjkxQjU3RTNBMDdGRTFG RkMzRTAxRkNFQgpGODNGNDk2QzQ4N0UwMUYwMTNFMDAxRTAxM0MwQTMwMUMwMTM4MEIzM0I3RkZD M0ZGODdGRjAwMjdGMTNGRkQ4RkZGRTZEMTMKRjhEODdGRkM0OTEzRjAwMjNGMTM3RjJEMjQ4MUEz MkM+STwzOTdGRjAxRkUwMzlGRkY4N0ZGQzkwMzhGOUZGRkUwMUZCN0YKNkNCNkZDMDAwMTkwMzhG MDNGODBFQ0MwMUYwMjgwN0ZFQzAwMEY1QjVCQTI1QkIzMjY3RkZGRTBCNUZDQjUwMEYxMTQ4MEEz CjZDMDFFMDE0MDAyOTI0N0ZBMzJDPkk8RUIwN0ZDRUIxRkZGMDE3RjEzQzA0OEI1MTJGMDQ4ODAz OTA3RkMwN0ZDMzkwRkYwCjAxRkU0ODQ4NkM3RTAxODAxMzNGMDAzRjE1ODA5MEM3MTIxRjAwN0VF QzBGQzBBMzQ4RUMwN0UwQTc2QzE0MEYwMDdFMTVDMApBMjAwN0YxNDFGNkMxNTgwNkQxMzNGNkM2 Q0VCN0YwMDZENUI2QzZDNDg1QTM5MDdGQzA3RkM2Q0I1NUE2QzVDNkM2QzEzQzAKMDExRjkwQzdG Q0VCMDdGQzIzMjQ3Q0EzMkM+STxEODdGRkVFQjNGQzBCNTM4MDFGRkYwMDIwNzEzRjgwMjFGMTNG QzZDNUIKMzkwMDNGN0ZFMUVDRkYwMTkxMzhGQzAwRjg0QTEzNzA0QTEzMDA1Q0EyNUM1Q0EzOTFD OEZDQUYwMDdGQjUxMkUwQjY3RUEzCjZDNUMyNjI0N0VBMzJDPjExNCBEPDkwMzg3RkY4NzAwMDAz QjUxMkY4MTIwRjVBNUEzODdGQzAwRjM4N0UwMDAzNDgxMzAxCjVBQTM2Q0VCMDBGMDAwN0YxNDAw MTNGMDM4M0ZGRkMwNkMxM0ZFNkNFQkZGODAwMDAzMTRFMEM2NkMxM0Y4MDEwMTEzRkNFQgowMDA3 RUMwMEZFMDA3ODE0N0YwMEZDMTQzRjE1MUY3RUEyNkMxNDNGNkQxMzNFNkQxM0ZFOTAzOEYwMDdG QzkwQjVGQzE1RjgKMTVFMDAwRjgxNDgwMzk3MDFGRkMwMDIwMjQ3QUEzMkM+STwxMzFFMTMzRkE5 MDA3RkI2RkNCNzEyODBBMzZDMTUwMEQ4MDAKM0ZDOEZDQjFFRDAzQzBFRDA3RTBBNUVDODAwRjAx MUZFQjFGQzBFQ0UwN0Y2REI1MTI4MDE2MDAwMTAzNUI2RDEzRjg5MDM4CjAwM0ZFMDIzMkU3RUFE MkM+STwzQTdGRjAwM0ZGODA0ODZDNDg3RkEzMDA3RjdGMDAwMUVCMDAwRkIzQTMxNTFGQTIxNTNG CjZEMTM3RjM5MDBGRTAzRkY5MEI3RkM2RDE1ODA3RjZEMTNDRjkwMjYwM0ZFMDcxMzAwMjkyNDdG QTMyQz5JPDNBN0ZGRjAxCkZGRkNCNTE0RkUxNDgzMTQwMTZDMTVGQzNBMDNFMDAwMEY4MEEyNkQx MzFGMDAwMTE1MDBBMjZENUIwMDAwMTQzRUEyNkQxMwo3RTAxN0MxMzdDQTIwMTdFMTNGQzAxM0U1 QkEyRUIzRjAxMDExRjVCQTIxNDgzMDEwRjVCQTIxNEM3MDEwNzVCQTIxNEVGMDEKMDM1QkEyMTRG RjZEOTBDN0ZDQTI2RDVBMTQ3QzI3MjQ3RUEzMkM+STxEODdGRkZFQjdGRkY2RUI1RkNCNTE1ODA2 QzE2MDAKNEE3RUQ4MDdDMEVCMDFGMEE2NkM2QzQ5NUFBMzE0M0UxNDdGQTJEODAxRjA0OTVBRUNG Rjg3QTIxNEY3QTIwMUYxMTNDNzAwCjAwNUQ5MDM4RjlFM0NGQTIwMUZCMTNFRkEzRDk3QkMxOTBD N0ZDMDE3RjEzRkZBMjE0ODBBMjAxM0Y1QjkwMzgxRjAwN0MyOQoyNDdGQTMyQz5JPDNBM0ZGRjAz RkZGMDQ4MDE4NzEzRjhBMzZDMDEwMzEzRjAzQTAwRkMwMDdFMDA1RDkwMzg3RTAxRjgwMQozRjVC RUIxRjgzRUM4N0UwOTAzODBGQ0ZDMDkwMzgwN0VGODBFQjAzRkY2RDkwQzdGQzVDNkQ1QTE0N0Mx NEZFMTMwMTgwOTAKMzgwM0VGODA5MDM4MDdDRkMwRUIwRkM3RUM4M0UwOTAzODFGMDFGMDAxM0Y3 RkVCN0UwMDAxN0MxMzdDNDkxMzdFMDAwMTgwCjNBN0ZGRjAxRkZGQzE0ODNCNTE0RkU2QzE1RkMx NDAxMjcyNDdFQTMyQz5JPDNBN0ZGRjAxRkZGQ0I1MDA4MTEzRkUxNDgzCjE0ODE2QzAxMDExM0ZD M0EwM0UwMDAwRjgwNkM3RTE1MUY2RDE0MDAxMjAwNUQ2RDEzM0UxMzdDMDE3RTEzN0UwMTNFMTM3 QwpBMjAxM0YxM0ZDNkQ1QkEyRUIwRjgxNURBMkVCMDdDMUVDQzNFMEEyRUIwM0UzRUNFN0MwMTMw MTE0Rjc1REVCMDBGRkEyOTIKQzdGQzgwQTIxNDNFQTIxNDdFMTQ3Q0EyMTRGQzVDQTJFQTBDMDEw MDNGNUJFQTdGODNFQjg3RTBFQTdFMEY0OTVBMzg3RkZGCjgwNkM5MEM4RkM2QzVBNkM1QUVBMDdF MDI3MzY3RUEzMkM+STwwMDNGQjYxMkUwNDgxNUYwQTQwMDdFQzdFQTFGRTBFRDNGCkMwRUQ3Rjgw RURGRjAwNEE1QTAwM0M0OTVBQzc0ODVBNEE1QTRBNUE0QTVBNEE1QTRBQzdGQ0VCMDFGQzQ5NUFF QjBGRjA0OQo1QTQ5NUE0OTVBNDlDOEZDNDg0OEVCMDFFMDQ4NDhFQjAzRjA0ODVBNDg1QTQ4NUE0 ODVBNDg1QUI3RkNBNDZDMTVFMDI0MjQKN0RBMzJDPkk8MTI3ODEyRkNCM0IzQjNBOTEyNzgwNjQx NkRCOTJDPjEyNCBEIEUKJUVuZERWSVBTQml0bWFwRm9udAolRFZJUFNCaXRtYXBGb250OiBGZiBj bWJ4MTIgMTQuNCAyNQovRmYgMjUgMTIyIGRmPEVFRkZGQzAzMUZFQkZGODA0QUI2MTJFMDAyMDc4 MTAyMUY5MDM4QzAwRkY4OTEzQTdGRkUwMDAzRkMKREFGRkYwRUIwMEZFNDk0OUVCMDNGRjQ5MDE4 MDVCNDk5MEM3NDg3RjQ5NDg1Q0EyNDk1QTREN0YwMTNGNkY1QjVDQTM3MTkwCkM3RkM3MTVBRUYw MUY4OTRDOUZDQTkwNDAzQjUxMkMwQkFGQ0E1MjYwMDNGRkNDNzEyMDc4M0IzQjNBNjAwM0ZCNUQ4 RkMwMwpCNjEyQzBBNTQyNTQ3REQzNEI+MTIgRDwxNTc4MTVGQzE0MDMxNDA3MTQxRjE0RkYxMzBG MDAwN0I1RkNCNkZDQTIxNDdGMTMKRjBFQUY4MDBDN0ZDQjNCM0IzQTYwMDdGQjcxMkZFQTUyRjRF NzZDRDQzPjQ5IEQ8RUMzRkZFMDEwM0I1MTJFMDAxMEYxNEZDCjAxM0YxNEZGOTBCNzEyQzA0OEQ5 QzA3RjdGMjcwM0ZFMDAwRjEzRjhEODA3RjgwMTAzN0ZEODBGRTA2RDdGNDg0ODZEN0Y0OAo0ODgw MDFGMDE2ODA0ODZDNkUxM0MwN0Y0ODZDNkUxM0UwN0ZBMjcwMTNGMEE1NkM1QUEyNkM1QUVBMEZG MEVBMDNDMEM5MTQKRTA1RUEyMThDMDVFMTg4MEEyNEMxMzAwNUY0QzVBNEI1QjVGNEI1QjVGNEI1 QjRCOTBDN0ZDNEI1QTVFNEI1QUVEN0ZFMDRCCjVBNEE1QjRBNDhDOEZDNEE1QTVENEE0OEVCMDFG MDRBNUFFQzNGODA0QUM3RkMwMkZFRUMwM0UwNDk1QTQ5NUE0OTVBNDk1QQpEOTFGODAxNDA3NDlD OEZDMDEzRTE1MEYwMTdGQjdGQzkwQjgxMkMwNUE1QTVBNUE1QTVBNUFCOUZDMTg4MEE0MzQ0RTc5 Q0QKNDM+STxCQTdFMTlGQ0YxRkY4MDFBRjAxQUZDRDgwMDA3MDFGMEM3MDAwRjEzRkYwNjAwMTRD MDA3MUY3RjA3MDcxM0Y4MDcKMDE3RjczN0Y3NDdFNzQ3Rjc0N0Y4Njc0N0Y3NDdGODg4Njg4ODY4 OEEyNzU3RUEzMUQ4MDg3QTIxREMwQTUxREUwQTM4N0E5CjYzQTMxREMwQTUxRDgwQTI2MzFEMDBB MzUxNUFBMjY0NjI2NDUwNUI2MjY0NTA1QjUwNUI1MDkwQzdGQ0YyRkZGRTRGNUIwNwowNzVCMDcx RjVCOTZCNTEyQzAwNjBGOTFDOEZDQkI1QTFBRjAxQUMwMDdGQ0M5RkMxOTgwNUI1MjdDRDE2Nz42 OApEPDAyN0ZCNzEyODBBNTkxQzc2QzkwQzdGQ0IzQjNCM0VBMDdGMEVBMUZGQzQ4N0U0ODdFQTJC NTdFQTQ0QzVBQTI1RjZDOTAKQzdGQzQ5NDk1QjZDNDg0OTVCNkM0ODVEMDFFMDQ5NUJEODBGRkMw MTFGNUIyNzAzRkY4MDdGOTBDOEZDNkM5MEI1MTJGQzZDCjZDMTRGMDAxMUYxNEMwMDEwMTAxRjhD OUZDMzk1MzdERDE0NT43NCBEPEI4MTJGOEE1RDgwMDA3MDFGOENBRkNCM0IzQTkxQQo3Q0E0MUFG QzFBRjhBNTE5MDFBMzE5MDNBMjE5MDcxQUYwMTkwRkEyMTkxRjE5M0YxOTdGMTlGRjE4MDM2MDE4 M0Y0REI1RkMKQkIxMkUwQTU0NjUyN0NEMTUxPjc2IEQ8OTMzODBGRkZDMDAzMDNCNkZDMDMxRjE1 RTA5MkI3MTJGQzAyMDNEOUZDMDAxM0ZGCjAyMEYwMUMwMDEwRjEzQzAwMjNGOTBDNzAwMDMxM0Yw REE3RkZDMDIwMDdGNDk0ODQ4RUQ3RkZFNDkwMUUwRUQxRkZGNDk0OQo2RjdGNDk0OTZGN0Y0OTkw Qzk2QzdGNDk4NTQ5NDg3MDdGNDk0ODcwN0ZBMjQ4NDk3MTdFNDg4NjRBODM0ODFCODA0QTgzNDgK MUJDMEEyNDgxQkUwNEE4M0EyNDgxQkYwQTM0ODQ5NzExM0Y4QTVCNTFBRkNBRjZDMUJGODZFNUZB NDZDMUJGMEEyNkU1RjZDCjFCRTBBMzZDNkQ0RDEzQzBBMjZDNkQ0RDEzODBBMjZDMUIwMDZDNkQ0 RDVBNkU1RTZDNjI2RDZDNEM1QjZENkQ0QjVCNkQ2RAo0QjVCNkQ2RDRCNUI2RDZENEI1QjZENkQ0 QjkwQzdGQzZENkQ0QjVBNkQwMUZGMDIwMzVCMDIzRjAxRTAwMTFGMTNGMDAyMEYKMDFGQzkwQjUx MkMwMDIwMzkwQjdDOEZDMDIwMDE2RkMwMzFGMTVFMDAzMDM5MkM5RkNEQjAwMUYxM0UwNTY1NDc5 RDI2NT4KNzkgRDw5MzM4MEZGRkMwMDMwM0I2RkMwMzFGMTVFMDkyQjcxMkZDMDIwM0Q5RkMwMDEz RkYwMjBGMDFDMDAxMEYxM0MwMDIKM0Y5MEM3MDAwMzEzRjBEQTdGRkMwMjAwN0Y5MDI2MDFGRkYw RUQzRkZFNDk0OTZGN0U0OTQ5NkY3RjQ5NDk2RjdGNDk5MEM5CjZDN0Y0OTQ4NzA3RjQ5NDg3MDdG MDFGRjg1NEExNzdGNDg4NjQ4NDk3MTdFQTI0ODQ5NzExMzgwQTI0ODFCQzA0QTgzNDgxQgpFMEEy NEE4MzQ4MUJGMEEzNDgxQkY4QTI5MUNCN0VBM0I1MUFGQ0FGNkMxQkY4QTI2RTVGQTM2QzFCRjBB MzZDNkQ0RDEzRTAKQTM2QzFCQzA2RTVGNkMxQjgwNkU1RjZDREIwMUZFMTYwMDZDNkQ5MDI2MDdG RjgwNDk1QTRDMTNFMDZDNkQ0OTZENDk1QTAxCjdGOTEyNjNGMDNGODVDNkQ2QzkwMjc3QzAwRkMw MTVCNkQ2QzQ5RDkzRTAzNUI2RDZENDhEOTNGMDc1QjZEMDFDMDZFNDg1Qgo2RDAxRTAwMzlGOTBD N0ZDNkQwMUYwNkVCNDVBNkQwMUZDNUU5MTI2M0ZGRkY4NkQxM0YwMDIwRjZENDkxM0MwMDIwMzAx RkYKOTBCNUM4RkMwMjAwOTFCNTEyRkMwMzFGNEIxNDBDMDMwMzZGMTQxRURCMDAxRkVCRTNGRTkz QzdFQTAxRkYxQzNFNzQxMzdFCjA4RTAxM0ZFNzJFQkY4MDc5N0I1MTJGQ0EzODUxQ0Y4QTI4NTFD RjA4NTFDRTA3MzE0QzBBMjczMTQ4MDczMTQwMDczNUI5NgozODAwN0ZGOEYyMUZFMDU3NkE3OUQy NjU+ODEgRDw5MTI2MEZGRjgwMTMwNzkxQjUwMEY4NUIwMTA3MDJGRjVCMDExRkVEQzAKM0Y0OUVE RjA3RjkwMjZGRkZDMDA2RDVBNDgwMUUwRUIwRkZENDgwMTgwMDEwMUI1RkM0ODQ4Qzg3RTQ4NDg4 MTQ5MTUwRjAwCjFGODI0OTgxMTIzRjQ5ODEwMDdGODJBMjg0MTJGRjg0QTI3RkEyNkQ4MkEyN0Y3 RjZEOTNDN0ZDMTRDMDZDMTNGMDE0RkYxNQpGODZDRUNGRjgwMTZGQzZDRURGRkMwMTdGMDZDMTZG QzZDMTZGRjZDMTdDMDZDODM2QzgzNkQ4MjZEODIwMTBGODIxMzAzMDEKMDA4MjAyMUYxNjgwMTQw MDAzMEYxNUMwRUQwMDdGMDQwNzE0RTAxNjAwMTczRjA1MEYxM0YwODM4M0EyMDA3ODgyMDBGODgy CkEzMTg3RkEyN0VBMjE5RTA3RUEyNkNFRkZGQzBBMjdGNkQ0QjEzODA2RDE3MDA2RDVEMDFGQzRC NUEwMUZGNEI1QTAyQzA0QQo1QTAyRjhFQzdGRjA5MDNCMUZGRkMwMDNGRkUwNDg2QzkwQjY1QUQ4 RkMwMzkzQzdGQzQ4QzY2QzE0RkM0ODAxMEYxNEYwNDgKRDkwMDdGOTBDOEZDM0M1NDc5RDI0Qj44 MyBEPEI3MDBGRTAzMUZCNTEyRkVBNUQ4MDAxRjAxRjBDQTM4M0ZGRTAwRjMwN0YwCjZENjI2RjE3 MEY2RDYyODExQjFGNkQ2RDYwMUIzRjZEOTdDN0ZDNkY1RjZEMTk3RTgyMUJGRTZFNkQ1RTFBMDE2 RTZENUUxQQowMzZFNjA3MDE1MDdBMjZFNkQ1RTFBMEY2RTZENUUxQTFGNkU2MDcwMTUzRkEyNkU2 RDkzQzhGQzYyNkU2RTE0N0UxQUZFNkYKNUU3MTEzMDFBMjZGNkQ1QzE5MDM2RjZENUMxOTA3NkY1 RTcxMTMwRkEyNkY2RDVDMTkxRjZGNkQ1QzE5M0Y2RjkzQzlGQzcxCjVCQTI2RkVDODA3RTE5RkU3 MDZENUExOEMxNzA1QzE4RTM3MDVDMThGMzE4Rjc3MEVCRkZFMEEyNzA1Q0EyNzA1Q0EzNzA5MQpD QUZDQTI3MDVCQTI3MTVBQTM3MTVBQTI3MTVBQTI3MTVBNzE1QTVGNTM3REQxNjY+ODYgRDxFQzdG RkYwMTA3QjUxMkYwMDEKM0YxNEZFOTBCNzdFNDhEOUUwMEY3RjI3MDNGRTAwMDExM0YwNDg2QzZE N0Y2RUVCM0ZGQzQ4ODI2RTEzMUY4MzcwN0ZBMzZDCjQ5NkQ3RkEyNkM5MEM3RkM2QzVBQzlGQ0E2 MDM3RkI1RkMwMjBGQjZGQzkxQjdGQzAxMDcxNDg3MDEzRkVCRjAwNzQ5MTM4MAozOTAxRkZGQzAw NDgxM0YwNDg1QjQ4NUI0ODVCNDg5MEM3RkM1QTVCQTI0ODVBQTQ1RUEyNkQ1QzAwN0YxNTFEMTYz RDZDNkMKMDI3OTdGNkM2RDAxRjExM0Y4NkM5MDI2QzAwM0UwRUJGRkUwNkM5MDI3RjgxRkMwN0Yx M0YwNkM5MEI1NDg3RUM2NEI3RTAxCjFGMDFGQzAxMDcxM0UwMDEwMTAxRTA5MEM4RkMzQzM4N0NC NjQxPjk3IEQ8RUIzRkYwQjVGQ0E1MTIwM0M2RkNCM0E0OTIzOAowMUZGRTAwMzBGMTNGRTAzM0ZF QkZGQzA5MkI2MTJGMDAyRjMwMTAxN0Y5MTNBRjdGODAwM0ZGRURBRkZFMEVCMEZGRjAzODAKNkQ3 RjkyQzc2QzdGNEE2RTdGNEE4MjRBNkU3RkEyNzI3RUEyODVBMjg1ODRBMzFBODBBQzFBMDBBNDRF NUFBMzYxMThGRjYxCjZFNEE1QkEyNkU0QTVCNkU0QTVCNkY0OTVCREFDRkMwNDk5MEM3RkNEQTg3 RjBFQjdGRkM5MTNBMDNGRTAzRkZGODQ5QzZCNgoxMkUwNDk2RDE0ODA0OTAxMUYwMUZDQzhGQzkw QzcwMDAzMTNDMDQxNTQ3QkQyNEI+STw5MTM4MDFGRkY4MDIxRkVCRkY4MAo5MUI2MTJGMDAxMDMx NUZDMDEwRjkwMzhDMDBGRkU5MDNBMUZGRTAwMDFGRkQ5N0ZGQzQ5MTM4MEQ5RkZGMDVCNDgxN0Mw NDgKNDk1QjVDNUE0ODVCQTI0ODZGMTM4MDkxQzdGQzQ4NkYxMzAwNzA1QTQ4OTJDOEZDNUJBMzEy RkZBRDEyN0Y3RkEyN0VBMkVGCjAzRTA2QzdGMTcwNzZDNkQxNUMwN0U2RTE0MEY2Q0VFMUY4MDZD NkRFQzNGMDA2QzZEMTQ3RUQ5N0ZGRTVDNkQ2Q0VCMDNGOAowMTBGOTAzOEUwMUZGMDAxMDM5MEI1 NUEwMTAwMTU4MDAyM0Y0OUM3RkMwMjAxMTNFMDMzMzg3Q0I2M0M+STw5MTM4MDNGRgpDMDAyM0Yx M0ZDNDlCNkZDMDEwNzE1QzA0OTAxODE3RjkwM0EzRkZDMDA3RkYwNDk0OEVCMUZGOEQ5RkZFMDZE N0U0ODgyNDgKNDk2RDdFNDg4MTRBMTU4MDVBNDg5MEM3NkMxM0MwQTI0ODE3RTBBMjgyNDg1QTE4 RjBBMzEyRkZBMzkwQjhGQ0EzMThFMDQ5CkNBRkNBNTEyN0ZBNDZDN0VBMjZDMTdFMEVGMDFGMDZD N0YxNzAzNkMxN0UwNkM2RDE0MDc2QzZERUMwRkMwNkNFRTFGODA2RAo2Q0VDM0YwMEQ5M0ZGQzE0 RkU2RDZDRUIwM0ZDOTAzQTBGRkZDMDNGRjgwMTAzOTBCNTVBMDEwMDE1QzAwMjFGNDlDN0ZDMDIK MDExM0YwMzQzODdDQjYzRD4xMDEgRDxFRDNGRkMwMjAzQjVGQzAyMEYxNEMwMDIzRjE0RTA5MTM5 RkZGODFGRjA0OTkwMzgKQzAzRkY4NDlFQjgwN0Y0OTkwMzgwMEZGRkM0OTVBNDk1QUEyNDk1QUEy RUU3RkY4NDk1QUVFM0ZGMEVFMEZDMDkzQzdGQ0FFCkI3MTJFMEE1MjYwMDdGRjhDOEZDQjNCM0E3 MDA3RkI1MTJGRUE1MkU1NDdDRDMyOT5JPERBM0ZGRjE0RkYwMTAzQjVEOEYwCjA3MTNDMDAxMEZE QUZDMUYxM0UwMDEzRkVDRkY3RjkwMjY3RkZDMEY5MDM4RkY5RkYwOTAyNkZGRTAwMUVCRjgzRjQ4 NDk2QwoxM0UwNDg0OTkwMzg3RkYwMUY0ODkwQzdEODNGRjgxM0UwNDg5MzM4RkMwRkMwRjAwNzgw NDg0ODZFNkNDN0ZDQTIwMDNGODIKQTkwMDFGNUVBMjZDNkM0QTVBQTI2QzVFNkM2RDQ5NUE2QzZE NDk1QTZDNkQ0ODVCREFGQzBGNUI0ODkwQjZDOEZDRDgwM0VGCjE0RkMwMUMzMTRGMDI2MDdDMDNG OTBDOUZDOTFDQkZDQTIxMjBGQTM3RkEyMTNGODEzRkU5MEI3RkM2QzE2RjgxN0ZGMThDMAo2Qzgz NkM4MzZDODM2RDgyODQ0OEI5RkMxMjA3NDg0OEM3MDAwMzE0ODBEODFGRjhFQzAwM0Y0ODQ4MTUw NzQ4NDg2RjEzQzAKODM0ODVBODNBNTZENUQwMDdGMTg4MDZENUQwMDNGMTgwMDZDNkM0QjVBRDgw RkZFRUQxRkZDNkM2QzZDRUM3RkY4NkMwMUUwCjQ5NDg1QTZDMDFGRTAxMUY1QjZDNkNCNzEyODAw MTBGMDNGQ0M3RkMwMTAxMTVFMEQ5MDAwRjAxRkNDOEZDM0M0RjdDQjU0Mwo+STwxMzdGNDk3RTQ4 N0Y0ODdGNDg3RjQ4N0ZBNzZDNUI2QzVCNkM1QjZDNUI2REM3RkM5MEM4RkNBREVCM0ZGMEI1RkNB NQoxMjAxN0VCM0IzQTZCNjEyRTBBNTFCNTQ3QkQzMjU+MTA1IEQ8RDkzRkYwRUIxRkZDQjU5MUI1 MTJDMDAzMDMxNEYwMDMwRgo4MDkyMzkxRkUwN0ZGQzkyMzkzRjAwMUZGRTAwMDMwMjdDODBDNjAy RjA3RkRBRjFFMDgxRUNGM0MwREFGNzgwN0Y4NTAyRkYKQzdGQzVDQTI1Q0E0NUNCM0FDQjZEOEY4 MDdCNjEyQzBBNTQyMzY3QkI1NEI+MTEwIEQ8OTEzODAxRkZFMDAyMUYxM0ZFOTEKQjYxMkMwMDEw MzE1RjAwMTBGOTAzODgwN0ZGQzkwM0ExRkZDMDAwRkZFRDk3RkY4NkQ2QzdFNDk0ODZEN0Y0ODQ5 NkQ3RjQ4CjQ5NkQ3RjRBMTQ3RjQ4ODM0ODkwQzg2QzdFQTI0ODgzQTI0ODQ4NkY3RUEzMDA3RjE4 ODBBNDAwRkYxOEMwQUMwMDdGMTg4MApBMzAwM0YxODAwNkQ1REEyNkM1RkEyNkM1RjZFMTQ3RjZD NUY2QzZENEE1QTZDNkQ0OTVCNkM2RDQ5NUI2RDZDNDk1QkQ5M0YKRkUwMTFGOTBDN0ZDOTAzQTBG RkY4MDdGRkM2RDkwQjU1QTAxMDAxNUMwMDIzRjkxQzhGQzAyMDExM0UwM0EzODdDQjY0Mz4KSTw5 MDNBM0ZGMDAxRkZFMEI1MDEwRjEzRkUwMzNGRUJGRkMwOTJCNjEyRjAwMkYzMDEwMTdGOTEzQUY3 RjgwMDdGRkUwMDAzCkQ5RkZFMEVCMUZGRkM2MDI4MDZEN0Y5MkM3NkM3RjRBODI0QTZFN0Y0QTZF N0ZBMjcxN0ZBMjg1MTg3Rjg1QTQ3MjEzODBBQwoxQTAwNjBBMzYxMThGRkEyNjE1RjYxNkU0QTVC QTI2RTRBNUI2RTRBNUI2RjQ5NUI2RjQ5OTBDN0ZDMDNGMEVCRkZGQzkxMjYKRkJGRTA3NUIwMkY4 QjYxMkUwNkYxNDgwMDMxRjAxRkNDOEZDMDMwMzEzQzA5MkNCRkNCMUI2MTJGOEE1NDE0RDdCQjU0 Qj4KSTw5MDM5N0ZFMDAzRkVCNTkwMzgwRkZGODAwMzNGMTNFMDRCMTNGMDkyMzhGRTFGRjg5MTM5 RTFGODNGRkMwMDAzRDlFM0UwCjEzRkVDNkVDQzA3RkVDRTc4MDE0RUYxNTAwMTRFRTAyRkVFQjNG RkM1Q0VFMUZGOEVFMEZGMDRBOTBDN0ZDQTU1Q0IzQUFCNgoxMkZDQTUyRjM2N0NCNTM3PjExNCBE PDkwMzkwM0ZGRjAwRjAxM0ZFQkZFMUY5MEI3RkMxMjAzNDhFQjAwM0ZEODBGRjgxMwowN0Q4MUZF MDEzMDE0ODQ4N0Y0OTgwMTI3RjkwQzg3RUEyNDg4MUEyN0ZBMjdGMDFGMDkxQzdGQzEzRkNFQkZG QzA2QzEzRkYKMTVGODZDMTRGRjE2QzA2QzE1RjA2QzgxNkM4MTZDODFDNjgxMDEzRjE1ODAwMTBG MTVDMDEzMDAwMjA3MTRFMEVDMDAzRjAzCjA3MTNGMDE1MDEwMDc4RUMwMDdGMDBGODE1M0YxNjFG N0UxNjBGQTI3RTE3RTA3RTZEMTQxRjE3QzA3RjZERUMzRjgwMDFGOApFQzdGMDAwMUZFRUIwMUZF OTAzOUZGQzAwRkZDNkRCNTVBRDhGQzFGMTRFMEQ4RjgwNzE0ODA0OEM2MDFGOEM3RkMyQzM4N0MK QjYzNT5JPDE0M0VBNjE0N0VBNDE0RkVBMjEzMDFBMzEzMDMxMzA3QTIxMzBGMTMxRjEzM0YxM0ZG NUEwMDBGOTBCNkZDQjgKRkNBNDI2MDAzRkZFQzhGQ0IzQTlFRTA3QzBBQjAxMUZFQzBGODA4MEEy NkRFQzFGMDAxNTgwNkRFQkMwM0U2REVCRjBGQzZECkVCRkZGODZENkM1QjAyMUY1QjAyMDMxMzgw MkE0RDdFQ0IzND5JPEQ5M0ZGODkxMzgwMUZGQzBCNTAyMDdCNUZDQTUwMDAzCkVEMDAxRkM2MTYw N0IzQUU1RkEzNUZBMjAxN0Y1RDE3M0IxNzdCNkQ2QzE0RjNEQzAxRTMxM0YwNkQ2Q0Q5MDdDM0VC RkZDMAo5MDNBMEZGRkMwM0Y4MzZEOTBCNTEyMDMwMTAxMTRGRTZENkMxM0Y4MDIwNzAxRTA5MUM3 RkM0MjM3N0JCNTRCPkk8QjYwMApGMDAxMDdCNUZDQTVDNjAxRjhDOEVBN0ZDMDZFRUQzRjAwQTI2 RDZDMTUzRTE4N0UwMTNGMTY3QzZFMTVGQzZENUU2RjEzMDEKNkQ1RTZGMTMwMzZENUU4MTE3MDc2 RDZENUMxNzBGNkQ2RDVDMTcxRjZEOTNDN0ZDNkY1QjAyN0YxNDNFNkYxMzdFMDIzRjE0CjdDNkYx M0ZDQTI2RTZENUExNjgxNkVFQkMxRjAxNkMzNkU1QzE2RTc2RTVDMTZGRjZFNUNBMjZFOTFDOEZD QTM2RjVBQTI2Rgo1QUEyNkY1QUEyNkY1QUEyNkY1QUEzNUUxNTBGNUUxNTFGOTNDOUZDNUREODFG QzAxMzNFNDg2QzEzN0U0ODZDMTM3QzQ4NkMKMTNGQzVEMTQwMTVEMTQwMzRBNUE2QzQ4NDg1QTQ5 NDg1QTI2M0ZDMDdGQ0FGQ0VCODFGRTZDQjQ1QTZDMTNGMDAwMDM1QkM2CjkwQ0JGQzQwNEQ3REI0 NDc+MTIxIEQgRQolRW5kRFZJUFNCaXRtYXBGb250CiVEVklQU0JpdG1hcEZvbnQ6IEZnIGNtcjEw IDEwIDY1Ci9GZyA2NSAxMjMgZGY8REEwRkY4MTNGQzkxMzk3RkZGMDdGRjkwM0IwMUY4MDdERjgz QzA5MDNBMDdFMDAxRkYwRjkwM0IxRgo4MDA3RkUxRkUwOTAzOTNGMDAwRkZDMTM3RTE2Rjg1Qjkz MzhGMDA3ODA0ODQ4MDEwNzkwQzdGQzE1MDNBQ0I4MTJGOEEzMjgKMDFGODAwMDNGMEM3RkNCM0FC NDg2QzQ5N0UyNjdGRkZFMEI1MTJGMEEzMzMzQjdGQkEzMD4xMQpEPEVDMEZGOEVDN0ZGRTkwMzkw MUY4MDc4MDkwMzkwN0UwMDFDMDkwMzkxRjgwMDBFMDkwMzgzRjAwMDcwMTdFNDk3RUEyNUIKQTI0 ODVBNkY1QUVEMDE4MDkyQzhGQ0E5RUQwM0YwQjdGQ0EzMzkwMUY4MDAwRjE1MDNCM0FBNDg2QzQ5 N0UyNjdGRkZFMEI1CjEyQzBBMzJBM0I3RkJBMkU+STwwMDFDMTMxQzAwN0YxMzdGMzlGRjgwRkY4 MEEyNkQxM0MwQTMwMDdGMTM3RjAwMUMxMzFDCjAwMDAxMzAwQTQwMDAxMTMwMTAxODAxMzgwQTIw MDAzMTMwMzAxMDAxMzAwNDg1QjAwMDYxMzA2MDAwRTEzMEU0ODVCNDg1Qgo0ODVCMDA2MDEzNjAx QTE5N0RCOTJBPjM0IEQ8MTIxQzEyN0ZFQUZGODBBMjEzQzBBMzEyN0YxMjFDMTIwMEE0MTIwMTEz ODAKQTIxMjAzMTMwMDVBMTIwNjEyMEU1QTVBNUExMjYwMEExOTc5QjkxNz4zOSBEPDE0NjAxNEUw RUIwMUMwRUIwMzgwRUIwNzAwCjEzMEUxMzFFNUI1QkEyNUI0ODVBQTI0ODVBQTIxMjA3NUIxMjBG OTBDN0ZDQTI1QTEyMUVBMjEyM0VBMzVBQTY1QUIyMTI3QwpBNjdFQTMxMjFFQTIxMjFGN0VBMjdG MTIwNzdGMTIwM0EyNkM3RUEyNkM3RTEzNzhBMjdGN0YxMzBFN0ZFQjAzODBFQjAxQzAKRUIwMEUw MTQ2MDEzNTI3OEJEMjA+STwxMkMwN0UxMjcwN0U3RTdFMTIwRjZDN0U2QzdFQTI2QzdFNkM3RUEy MTM3OEEyMTMKN0MxMzNDMTMzRTEzMUVBMjEzMUY3RkEyMTQ4MEEzRUIwN0MwQTZFQjAzRTBCMkVC MDdDMEE2RUIwRjgwQTMxNDAwQTI1QjEzCjFFQTIxMzNFMTMzQzEzN0MxMzc4QTI1QkEyNDg1QTQ4 NUFBMjQ4NUE0OEM3RkMxMjBFNUE1QTVBNUE1QTEzNTI3Q0JEMjA+Ckk8MTIxQzEyN0ZFQUZGODBB MjEzQzBBMzEyN0YxMjFDMTIwMEE0MTIwMTEzODBBMjEyMDMxMzAwNUExMjA2MTIwRTVBNUE1QQox MjYwMEExOTc5ODgxNz40NCBEPEI1MTJGQ0E1MTYwNTdGOTQxQz5JPDEyMUMxMjdGRUFGRjgwQTVF QTdGMDAxMjFDMDkwOQo3OTg4MTc+STwxNTBDMTUxRUEyMTUzRTE1M0NBMjE1N0MxNTc4QTIxNUY4 MTVGMEEyMTQwMTE1RTBBMjE0MDMxNUMwQTIxNAowNzE1ODBBMjE0MEYxNTAwNUMxNDFFQTIxNDNF MTQzQ0EyMTQ3QzE0NzhBMjE0Rjg1Q0EyMTMwMTVDQTIxMzAzNUNBMjEzMDcKNUNBMjEzMEY5MUM3 RkNBMjVCMTMxRUEyMTMzRTEzM0NBMjEzN0MxMzc4QTIxM0Y4NUJBMjEyMDE1QjEyMDM1QkEyMTIw NzVCCkEyMTIwRjkwQzhGQ0EyNUExMjFFQTIxMjNFMTIzQ0EyMTI3QzEyNzhBMjEyRjg1QUEyMTI2 MDFGNTM3QkJEMkE+STxFQjAxCkMwMTMwMzEzMDcxMzFGMTNGRkI1RkNBMjEzMUYxMjAwQjNCM0E4 NDk3RTAwN0ZCNTEyRjBBMzFDMzg3OUI3MkE+NDkKRDxFQjBGRjBFQjdGRkU0OEI1N0UzOTAzRTAz RkUwMzkwRjAwMEZGMDAwMEU2RDdFNDg2RDdFNDg2RDdFMTIzMDAwNzA2RDdFCjEyNjAxMkZDQjRF QzdGODA3RkE1NkNDN0ZDMTIxQ0M4RkNFREZGMDBBMzRBNUE1RDE0MDM1RDRBNUE1RDE0MEY0QTVB NEE1QQo5MkM3RkMxNDdDNUM0OTVBNDk1QTQ5NUE0OTVBOTFDOEZDMDExRUVCMDE4MDVCNUI0OTEz MDM0ODQ4MTQwMDQ4NUE0ODVBMDAKMEVDNzVBMDAwRkI2RkM1QTVBNDg1Q0I2RkNBMzIxMzg3Q0I3 MkE+STxFQjA3RjhFQjNGRkY0OTEzQzAzOTAxRjgwRkYwMzkKMDNDMDA3Rjg0ODQ4NkM3RTM4MEUw MDAxMDAwRjgwMzgxRkUwMDA2RDdGQTU2QzVBNkM1QUM4NUExNDAxQTI1RDRBNUFBMjRBCjVBNURF QzBGODAwMjdFQzdGQ0VCMUZGQ0VDRkY4MDkwMzgwMDBGRTA2RTdFRUMwMUZDODE2RTdFRUQ3Rjgw QTIxNkMwQTIxNQozRjE2RTBBMjEyMUVFQTdGODA0ODdFQTQxNkMwNDkxMzdGMDA3RjE1ODAwMDdF QzdGQzAwNzBFQ0ZGMDA2QzQ5NUExMjFFMzkKMEY4MDAzRjgzOTA3RjAwRkYwMDAwMUI1MTJDMDZD NkM5MEM3RkNFQjBGRjgyMzNBN0RCNzJBPkk8MTUzOEEyMTU3ODE1RjgKQTIxNDAxMTQwMzE0MDdB MjE0MEYxNDFGMTQxQjE0MzMxNDczMTQ2MzE0QzMxMzAxMTQ4M0VCMDMwMzEzMDcxMzA2MTMwQzEz CjFDMTMxODEzMzAxMzcwMTM2MDEzQzAxMjAxRUEwMzgwMTMwMDVBMTIwRTEyMEM1QTEyMzgxMjMw NUExMkUwQjcxMkY4QTNDNwozODAzRjgwMEFCNEE3RTAxMDNCNTEyRjhBMzI1Mzk3RUI4MkE+STww MDA2MTQwQ0Q4MDc4MDEzM0M5MDM4RjAwM0Y4OTBCNQpGQzVENUQxNTgwOTJDN0ZDMTRGQzM4MDY3 RkUwOTBDOUZDQUJFQjA3RjhFQjNGRkU5MDM4NzgwRjgwMzkwN0UwMDdFMDkwMzgKODAwM0YwNDk2 QzdFMTIwNjZFN0VDODdFQTI4MTgxQTIxNjgwQTQxMjNFMTI3RjQ4N0VBNDkwQzcxMzAwNDg1QzEy RTAwMDYwCjVDMTI3MDAwMzA0OTVBMDAzODVDNkMxMzAzMDAxRTQ5NUE2QzZDNDg1QTM5MDdFMDNG ODAwMDAxQjVDN0ZDMzgwMDdGRkNFQgoxRkUwMjEzQTdDQjcyQT5JPEVDM0ZDMDkwMzgwMUZGRjAw MTA3MTNGQzkwMzgwRkUwM0U5MDM4M0Y4MDA3OTAzODdFMDAxRgo0OUVCM0Y4MDQ4NDgxMzdGNDg1 QUEyNDg1QTAwMEZFQzNGMDA0OTEzMUUwMDFGOTFDN0ZDQTI0ODVBQTMxMjdGOTBDOUZDRUIKMDFG QzkwMzgwN0ZGODAzOUZGMUUwN0UwOTAzODM4MDFGMDQ5NkM3RTAxNjA3RjAxRTAxMzdFNDk3RkEy NDkxNDgwMTZDMDE1CjFGQTI5MEM3MTNFMEE1N0VBNTZDN0UxNkMwQTIxMjFGRUQzRjgwN0YwMDBG MTUwMDZDNkM1QjE1RkU2QzZDNUI2QzZDNDg1QQozOTAwRkUwN0YwOTAzODNGRkZDMDZEOTBDN0ZD RUIwM0ZDMjMzQTdEQjcyQT5JPDEyMzAxMjM4MTIzRTAwM0ZCNjEyRTBBMwoxNkMwNUExNjgwMTYw MDAwNzBDNzEyMDYwMDYwMTQwRTVEMTUxODAwRTAxNDM4NDg1QzVENURDNzEyMDE0QTVBOTJDN0ZD NUMKMTQwRTE0MEMxNDFDNUNBMjVDQTIxNEYwNDk1QUEyMTMwM0EyNUMxMzA3QTIxMzBGQTM0OTVB QTMxMzNGQTUxMzdGQTk2REM4CkZDMTMxRTIzM0I3QkI4MkE+STwxMjFDMTI3RkVBRkY4MEE1RUE3 RjAwMTIxQ0M3RkNCMjEyMUMxMjdGNUExMzgwQTQxMjdGCjEyMUQxMjAxQTQxMjAzMTMwMEEyNUEx MjA2QTIxMjBFNUExMjE4MTIzODVBMTI2MDA5MzQ3OUEzMTc+NTkKRDwxNTM4QTMxNTdDQTMxNUZF QTM0QTdFQTM0QTZDN0VBMjAyMDc3RkVDMDYzRkEyMDIwRTdGRUMwQzFGQTIwMjFDN0ZFQzE4CjBG QTIwMjM4N0ZFQzMwMDdBMjAyNzA3RkVDNjAwM0EyMDJDMDdGMTUwMUEyRDkwMTgwN0Y4MUEyNDlD NzdGMTY3RkEyMDEwNgo4MTAxMDdCNkZDQTI0OTgxMDEwQ0M3MTIxRkEyNDk2RTdFQTM0OTZFN0VB MzQ5NkU3RUEyMTNFMDcwN0UxMjAxNDg2QzgxRDgKMEZGQzAyMDcxMzgwQjU2QzkwQjUxMkZFQTMz NzNDN0RCQjNFPjY1IEQ8QjcxMkUwMTZGQzE2RkYwMDAxOTAzOTgwMDA3RkMwCjZDOTBDN0VBMUZF MDcwN0U3MDdFNzA3RUEyNzA3RUEyODNBNzVGMTYwMzVGNEM1QTRDNUE0QzVBNEM1QUVFRkY4MDkx QjUwMApGQ0M3RkNBMjkxQzdFQTdGODBFRTFGRTBFRTA3RjA3MDdFNzA3RTgzNzA3RUEyMTg4MDE3 N0YxOEMwQTcxODgwMTdGRkEyNEMKMTMwMDVGMTYwMzRDNUFFRTFGRjg0ODZERUI3RkYwQjgxMkMw OTRDN0ZDMTZGODMyMzk3REI4M0I+STw5MTNBMDFGRjgwMDEKODAwMjBGRUJFMDAzMDI3RjEzRjg5 MDNBMDFGRjgwN0UwNzkwM0EwM0ZDMDAwRjBGRDkwRkYwRUIwMzlGNDk0OEVCMDFERkQ5CjNGODBF QjAwRkY0OUM4MTI3RjAxRkUxNTNGMTIwMTQ4NDgxNTFGNDg0ODE1MEZBMjQ4NDgxNTA3QTI0ODVB MTcwMzEyM0Y1QgowMDdGMTYwMUEzNUIwMEZGOTNDN0ZDQUQxMjdGNkRFRDAxODBBMzEyM0Y3RjAw MUYxNjAzMTgwMDZDN0U1RjZDN0UxNzA2NkMKNkMxNTBFNkM2QzVEMDAwMDE2MTgwMTdGMTUzODZE NkM1Q0Q5MUZFMDVDNkQ2Q0VCMDNDMEQ5MDNGQ0VCMEY4MDkwMjcwMUZGCjgwM0ZDN0ZDOTAzOTAw N0ZGRkZDMDIwRjEzRjAwMjAxMTM4MDMxM0Q3QkJBM0M+STxCNzEyQzAxNkY4MTZGRTAwMDE5MDM5 CjgwMDFGRjgwNkM5MEM3RUEzRkUwRUUwRkYwRUUwM0Y4NzA3RTcwN0UxNzdGQTJFRjNGODAxOEMw MTcxRjE4RTAxNzBGMThGMApBM0VGMDdGOEE0MThGQ0FDMThGOEE0RUYwRkYwQTIxOEUwQTIxNzFG MThDMEVGM0Y4MEEyRUY3RjAwMTdGRTRDNUE0QzVBRUUKMEZGMEVFM0ZFMDQ4NkRFQkZGODBCOEM3 RkMxNkY4MTZDMDM2Mzk3REI4M0Y+STxCODEyRkNBMzAwMDE5MDM4ODAwMDBGNkMKOTBDNzEyMDFF RTAwN0UxNzNFMTcxRTE3MEVBMzE3MDZBMzE3MDc4MzE2QzBBMzk0QzdGQ0EzMTUwMUEyMTUwMzE1 MEY5MUI1CkZDQTNFQzAwMEYxNTAzMTUwMUEyMTUwMEEyMTg2MEEzMThFMDkzQzcxMkMwQTQxNzAx QTNFRjAzODBBMjE3MDdBMjE3MEYxNwozRjE3N0Y0ODZEOTAzODA3RkYwMEI5RkNBMzMzMzk3REI4 Mzk+STxCODEyRjhBMzAwMDE5MDM4ODAwMDFGNkM5MEM3MTIwMQpFRTAwRkMxNzdDMTczQzE3MUNB MjE3MENBNDE3MEUxNzA2QTJFRDAxODBBMjE3MDBBNDE1MDNBMjE1MDcxNTFGOTFCNUZDQTMKRUMw MDFGMTUwNzE1MDNBMjE1MDFBNjkyQzhGQ0FENDgxM0MwQjYxMkMwQTMyRjM5N0RCODM2Pkk8QjY0 OEI1MTJGRUEzMDAKMDE5MDI2ODAwMDAzMTMwMDZDOTBDNzZDNUFCM0E0OTFCNkZDQTM5MUM3MTIw MUIzQTY0ODZENDk3RUI2NDhCNTEyRkVBMzM3CjM5N0RCODNFPjcyIEQ8QjYxMkMwQTNDNkVCQzAw MDZENUFCM0IzQUQ0OTdFQjYxMkMwQTMxQTM5N0VCODFFPkk8MDEzRkI1CjEyRTBBMzkwMzkwMDFG RkMwMEVDMDdGOEIzQjNBMzEyM0ZFQTdGODBFQUZGQzBBNDRBNUExMzgwRDg3RjAwNUIwMDcwMTMx Rgo2QzVDNkM0OTVBNkM0OUM3RkMzODA3ODFGQzM4MDFGRkYwMzgwMDdGODAyMzNCN0RCODJCPkk8 QjYxMkUwQTMwMDAxMDFDMApDOEZDNkM5MEM5RkNCM0FEMTcxOEE1MTczODE3MzBBMzE3NzBBMzE3 RjBBMjE2MDExNjAzMTYwRkVFMUZFMDQ4NkQxM0ZGQjgKRkNBMzJEMzk3REI4MzQ+NzYgRDxCNTkz MzgwN0ZGRjg2RTVEQTIwMDAxRjBGQzAwMjYwMERGQzBFRDFCRjhBMkQ5Q0ZFMDE1CjMzQTNEOUM3 RjAxNTYzQTNEOUMzRjgxNUMzQTJEOUMxRkNFQzAxODNBM0Q5QzBGRUVDMDMwM0EyMDI3RjE0MDZB MzZFNkMxMwowQ0EzNkU2QzEzMThBMjZFNkMxMzMwQTM2RTZDMTM2MEEyNkU2QzEzQzBBMzkxMzkw MUZDMDE4MEEzOTEzOTAwRkUwMzAwQTIKRUQ3RjA2QTNFRDNGOENBMkVEMUZEOEEzRUQwRkYwQTM0 ODZDNkQ1QTQ4N0VEODBGRkM2RDQ4NDk3RUI1MDBDMDAyMDNCNTEyCkY4QTJFRDAxODA0NTM5N0RC ODRDPkk8QjU5MTM4MDdGRkZFODA4MEM2OTIzODAwN0ZFMDZFRUMxRjgwRDlERkYwRUMwRjAwCjE3 MDZFQkNGRjhFQkM3RkNBMkVCQzNGRUVCQzFGRkEyMDFDMDdGNkU3RUEyNkU3RTZFN0U4MTE0MEY2 RTdFODExNDAzNkU3RQoxNjgwODBFRDdGQzAxNkUwMTUzRkVEMUZGMEVEMEZGOEEyRUQwN0ZDRUQw M0ZFQTJFRDAxRkY2RjEzODZBMkVFN0ZDNkVFM0YKRTZBMkVFMUZGNkVFMEZGRUEyMTYwNzE2MDNB MjE2MDExNjAwQTIxNzdFNDg2QzE1M0U0ODdFRDgwRkZDMTUxRUI1MDBDMDE0CjBFQTIxNzA2Mzcz OTdEQjgzRT5JPEVDMDNGRjAyMUYxM0UwOTEzOEZFMDFGQzkwMzkwMUY4MDA3RUQ5MDdFMEVCMUY4 MDQ5CjQ4NkQ3RUQ5M0Y4MEVCMDdGMDQ5Qzc2QzdFMDFGRTZFN0U0ODQ4NkU3RTQ5MTU3RTAwMDMx NjdGNDg0OEVEM0Y4MEEyNDg0OApFRDFGQzBBMjAwMUYxN0UwNDkxNTBGMDAzRjE3RjBBMzAwN0Yx N0Y4NDkxNTA3QTMwMEZGMTdGQ0FDMDA3RjE3Rjg2RDE1MEYKQTMwMDNGMTdGMEEyNkM2Q0VEMUZF MEEzNkM2Q0VEM0ZDMDAwMDcxNzgwNkQxNTdGMDAwMzE3MDA2QzZDMTVGRUEyNkM2QzRBCjVBMDE3 RjRBNUE2RDZDNDk1QTZENkM0OTVBRDkwN0UwRUIxRjgwRDkwM0Y4MDE3RkM3RkM5MDM5MDBGRTAx RkM5MTM4MUZGRgpFMDAyMDM5MEM4RkMzNjNEN0JCQTQxPkk8RUMwM0ZGMDIxRjEzRTA5MTM4RkUw MUZDOTAzOTAxRjgwMDdFRDkwN0UwRUIxRgo4MDQ5NDg2RDdFRDkzRjgwRUIwN0YwNDlDNzZDN0Uw MUZFNkU3RTQ4NDg2RTdFQTI0ODQ4MTU3RjAwMDcxNzgwNDkxNTNGMDAKMEYxN0MwNDkxNTFGMDAx RjE3RTBBMjQ4NDhFRDBGRjBBMzAwN0YxN0Y4QTI0OTE1MDdBMjAwRkYxN0ZDQUMwMDdGMTdGOEEy CjZEMTUwRkEyMDAzRjE3RjBBMjZDNkNFRDFGRTBBMzZDNkNFRDNGQzAwMDA3MDI3QzE0ODA0QUI0 RkMzQzAzRjgwMzgzODA3RgowMDNCMDFGQzA3MDFDMEZFRUMwRTAwMjYwMEZFMENFQkUxRkMwMTdG RUM2M0Y4RDkzRjhDRUI3N0YwRDkxRkNDRUIzRkUwRDkKMDdFRTE0ODA2REI0NDlDN0ZDMDEwMEQ5 ODFGQzEzMENFQzFGRkYwMjAzMTMxQzkxQzcwMDFFMTMxQzE2MUYxODNDRUY4MDdDCkVGQzBGOEVF MEZGRkEzMThGMDgyMThFMDcwMTNDMDcwMTM4MDkzMzgwMDdFMDAzNjRCN0JCQTQxPjgxCkQ8QjYx MkZFRURGRkUwMTZGODAwMDE5MDM4ODAwN0ZFNkM5MEM3NkM3RUVFM0ZDMDcwN0U3MDdFNzA3RUEy NzA3RUEyODNBNgo1RkEyNEM1QUEyNEM1QTRDNUFFRTNGODAwNEZGQzhGQ0VEMDdGQzkxQjUxMkUw NUU5MTM4MDAwRkYwRUQwM0Y4RUQwMEZFODIKNzA3RTcwN0VBMjE2MUY4M0E1ODNBNkYwMDE4MEEy MTdGODE2MEYxODAzNDg2RDAxMDcxNDAwQjY2RDZDNUEwNDAxMTMwNjkzCjM4MDBGRTBFQ0FFQTNG RkNFRjA3RjAzOTNCN0RCODNEPkk8RDkwRkY4MTNDMDkwMzgzRkZFMDE5MEI1MTI4MTM5MDNGODA3 CkUzMzkwN0UwMDBGNzQ4NDgxMzdGNDg0ODEzM0Y0OEM3MTIxRjAwM0UxNDBGMDA3RTE0MDdBMjAw N0MxNDAzMTJGQzE1MDFBMwo2QzE0MDBBMzdFNkQxNDAwNkM3RTdGMTNGODZDQjQ3RTZDMTNGOEVD RkY4MDZDMTRFMDZDMTRGODZDMTRGRUM2ODAwMTNGMTQKODAwMTA3MTRDMEVCMDA3RjAyMDcxM0Uw RUMwMDdGRUQzRkYwMTUxRjE1MEZFRDA3RjhBMjAwQzAxNDAzQTIxNTAxQTM3RUEyCjE2RjA3RTE1 MDM2QzE1RTA2QzE0MDc2QzE1QzA2QzE0MEY2REVCMUY4MEQ4RkJGMEVCM0YwMEQ4RjBGRTEzRkUz OUUwM0ZGRgpGODAxMEYxM0UwRDhDMDAxOTBDN0ZDMjUzRDdDQkEyRT5JPDAwM0ZCODEyRTBBM0Q5 QzAwM0VCMDAxRjI3M0UwMDAxRkUxMwowMzQ4RUUwMUYwMDA3ODE2MDAwMDcwMTc3MEEzMDA2MDE3 MzBBNDAwRTAxNzM4NDgxNzE4QTRDNzE2MDBCM0IwOTEzODA3RkYKODAwMTFGQjYxMkUwQTMzNTM5 N0RCODNDPkk8QjY5MDM4MDdGRkZFQTMwMDAxMDE4MDkwMzgwMDdGRTA2QzkwQzhFQTFGODAKRUYw RjAwMTcwNkIzQjIxNzBFNkQxNTBDODAxNzFDMTMzRjE3MTg2RDZDMTQzODVGNkQ2QzE0RjA2RDZD NUM2RDZDNDk1QTZECjZDRUIwNzgwNkQ2QzQ5QzdGQzkxMzg3RjgwN0U5MTM4MUZGRkY4MDIwNzEz RTA5MTM4MDA3RjgwMzczQjdEQjgzRT5JPEI1CjAwRkM5MTM4N0ZGRjgwQTMwMDAzMDE4MDkxMzgw RkZDMDA2QzkwQzhFQTA3RTA3MTVBNkM3MDVBNkUxNDAzMDE3RjkzQzdGQwpBMjgwMDEzRjE1MDZB MjZFMTQwRTAxMUYxNTBDODAwMTBGNURBMjgwMDEwNzVEQTI2RTE0NzAwMTAzMTU2MEEyNkQ2QzVD QTIKODA2RDRBNUFBMkVEODAwMzAyN0Y5MUM4RkNBMjkxMzgzRkMwMDZBMjE1RTAwMjFGNUJBMkVE RjAxQzAyMEYxMzE4QTI2RTZDCjVBQTIxNUZDMDIwMzVCQTJFREZFRTAwMjAxNUJBMjZFNkM1QUEz NkZDOUZDQTMxNTNFQTIxNTFDQTMzOTNCN0VCODNFPkk8CkI1RDhGQzA3QjVEOEYwMDFCNUZDQTMw MDA3OTAyNzgwMDAxRkZFQzdFQTFGRjg2QzQ4QzdEODBGRjhFQzA3RTAwMDAxMDMwNwpFRDAzQzAx QjgwN0Y2QzZGNkMxNTAwQTI2RTVGMDE3RjZFNkMxNDA2QTI4MDAxM0Y0QTZDNUNBMjgwMDExRjRB NkQ1QkVFMDYKN0ZBMjZENkMwMTBFNkQ1QkVFMEMzRkEyNkQ2QzAxMUM2RDVCRUUxODFGQTI2RDZD NkY1QkVFMzAwRkEyNkQ2QzZGNDg1QUVFCjYwMDdBMjZENkM0Q0M3RkM5MzM4QzAwM0ZDQTIwMzgw NUQ5MTNCN0Y4MTgwMDFGRTA2QTIwM0MxMTUwRURBM0ZDM0M3RUFGRgowQ0EyMDNFMzE1MUNEQTFG RTZFQzdGOThBMjE1RjZEQTBGRkNFQzNGRjBBMzAyMDc1RTRCMTQxRkEyMDIwMzVFNEIxNDBGQTIK MDIwMTVFNEIxNDA3QTIwMjAwOTNDOEZDNEI4MDUwM0I3RUI4NTU+STwzOTAxODAwMTgwMDAwMzEz MDMzOTA3MDAwNzAwMDAKMEUxMzBFNDg1QjAwMTgxMzE4MDAzODEzMzgwMDMwMTMzMDAwNzAxMzcw MDA2MDEzNjBBMjAwRTAxM0UwNDg1QkE0MDBDRTEzCkNFMzlGRjgwRkY4MDZEMTNDMEEzMDA3RjEz N0ZBMjM5M0Y4MDNGODAzOTBFMDAwRTAwMUExOTc0QjkyQT45MgpEPEVCMUZFMEVCRkZGQzM4MDNF MDNGMzkwNzAwMEY4MDM5MEY4MDA3RTA0ODZDNkM3RTEzRTA2RTdFQTI2RTdFNkM1QTZDNUEKQzhG Q0E0MTQ3RkVCMDdGRkVCM0ZFMEVCRkUwMEVBMDNGOEVBMEZGMEVBMUZDMDEyM0Y0ODVBOTBDN0ZD MTYwQzEyRkVBMzE0CjAxQTI2QzEzMDM2Q0VCMDc3QzkwMzk4MDA2M0UxODM4M0ZDMDFFM0EwRkUw NzgxRkYwM0EwM0ZGRjAwRkUwM0EwMDdGODAwNwpDMDI2Mjc3REE1MkE+OTcgRDxFQTAzRjAxMkZG QTMxMjBGMTIwM0IwRUMxRkUwRUM3RkY4OTAzOEYxRTAzRTkwMzlGMzgwMUYKODA5MDM5RjcwMDBG QzAwMUZFRUIwN0UwNDlFQjAzRjA0OUVCMDFGODVCRUQwMEZDQTIxNkZFQTIxNjdFMTY3RkFBMTY3 RTE2CkZFQTIxNkZDMTUwMTZEMTRGOEVEMDNGMDdGMDFFRUVCMDdFMDAxQzZFQjBGQzA5MDM5Qzc4 MDFGMDA5MDM4ODFFMDdFOTAzOAowMEZGRjhDN0VBMUZDMDI4M0I3RUI5MkU+STxFQjAzRkM5MDM4 MUZGRjgwOTAzODdFMDNFMDM5MDFGODAwNzA0ODQ4MTNGOAozOTA3RTAwMUZDMzgwRkMwMDNBMkVB MUY4MDEyM0Y5MDM4MDAwMUY4NDhFQjAwRjAxNTAwQTIxMjdFMTJGRUFBMTI3RTEyN0YKQTI2QzE0 MDY3RjAwMUYxNDBFNkQxMzBDMDAwRjE0MUM2QzZDMTMzODZDNkMxMzcwNkM2QzEzRTAzOTAwN0Mw N0MwOTAzODFGCkZGMDBFQjA3RjgxRjI3N0RBNTI1Pkk8RUQwRkMwRUMwM0ZGQTNFQzAwM0YxNTBG QjBFQjAzRjhFQjFGRkY5MDM4N0UwNzhGCjkwMzhGODAxRUYzOTAzRjAwMDdGNDg0ODEzM0Y0ODQ4 MTMxRkEyNDg0ODEzMEYxMjNGOTBDN0ZDNUFBMjEyN0UxMkZFQUExMgo3RTEyN0ZBMjdFQTI2QzZD MTMxRkEyNkM2QzEzM0Y2QzZDMTM3RjZDNkNFQkVGRjAzQTAxRjgwMUNGRkYzOTAwN0MwNzhGOTAK MzgxRkZFMEZEOTA3RjgxM0MwMjgzQjdEQjkyRT5JPEVCMDdGOEVCMUZGRjkwMzg3QzBGQzAzOTAx RjgwM0UwMzkwM0YwMDEKRjBEODA3RTAxM0Y4MzgwRkMwMDA0ODQ4MTM3Q0EyNDhDNzEyN0UxNTNF NUExNTNGMTI3RTEyRkVBM0I3RkNBMjQ4QzhGQ0E1CjEyN0VBMjEyN0ZBMjZDMTQwMzdGMDAxRjE0 MDc2QzZDMTMwNjAwMDcxNDBFNkQxMzFDRDgwMUYwMTMzODZDNkMxMzcwOTAzOAo3RTAzRTA5MDM4 MUZGRjgwOTAzODAzRkMwMDIwMjc3RUE1MjU+STwxNDdFOTAzODAzRkY4MDkwMzgwRkMxRTBFQjFG ODc5MAozODNGMEZGMDEzN0VBMjEzRkNBMjM5MDFGODAzQzA5MUM3RkNBREI1MTJGQ0EzRDgwMUY4 QzdGQ0IzQUI0ODdFMzg3RkZGRjgKQTMxQzNCN0ZCQTE5Pkk8RUQwM0YwOTAzOTBGRjAwRkY4OTAz OTNGRkMzQzNDOTAzOUY4MUY3MDdDMzkwMUYwMEZFMDM5MDMKRTAwN0MwM0EwN0MwMDNFMDEwMDAw RkVDRjAwMEEyNDg0ODZDN0VBODZDNkM0ODVBQTIwMDA3NUM2QzZDNDg1QTZENDg1QTZECjQ4QzdG QzM4MDczRkZDMzgwNjBGRjAwMDBFQzlGQ0E0MTIwRkEyMTNDMDZDQjUxMkMwMTVGODZDMTRGRTZD RUNGRjgwNDgxNQpDMDNBMEY4MDAwN0ZFMDQ4QzdFQTBGRjAwMDNFMTQwMzQ4MTQwMTE2Rjg0ODE0 MDBBNTZDMTQwMTAwN0MxNUYwNkNFQzAzRTAKMDAzRjE0MDdEODBGODBFQjBGODBEODA3RTBFQjNG MDAzOTAxRkMwMUZDMzkwMDdGRkZGMDAxMDc5MEM3RkMyNjM4N0VBNTJBCj5JPEVBMDNGMDEyRkZB MzEyMEYxMjAzQjBFQzBGRjBFQzNGRkNFQ0YwM0Y5MDM5RjFDMDFGODA5MDM5RjM4MDBGQzBFQkY3 CjAwMTNGRTQ5NkQ3RUEyNUJBMzVCQjNBMzQ4NkM0OTdFQjUwMEMxQjUxMjgwQTMyOTNBN0VCOTJF Pkk8RUEwMzgwRUEwRkUwCjQ4N0VBNTZDNUFFQTAzODBDOEZDQUFFQTAzRjAxMkZGQTMxMjA3MTIw M0IzQUE0ODdFQjUxMkMwQTMxMjM4N0VCNzE3Pkk8CkVCMDFDMEVCMDdGMEVCMEZGOEE1RUIwN0Yw RUIwMUMwOTBDN0ZDQUFFQjAxRjgxM0ZGQTMxMzA3MTMwMUIzQjNBMjEyM0MxMgo3RTAwRkYxM0Yw MTMwM0EyMTRFMDM4RkUwN0MwMTI3QzM4M0MwRjAwRUEwRkZFRUEwM0Y4MTU0OTg0QjcxOT5JPEVB MDNGMAoxMkZGQTMxMjBGMTIwM0IxOTEzODAxRkZGQ0EzOTEzODAwN0ZDMDE2MDAxNTdDMTU3MDVE NEE1QTRBNUE0QUM3RkMxNDFFMTQKMzgxNDc4MTRGQzEzRjFFQkYzRkVFQkY3M0YwMUZFN0ZFQkY4 MUY0OTZDN0U4MTE0MDc2RTdFNkU3RTgxMTQwMDE1N0UxNTdGCjgxMTY4MEVEMUZDMDQ4NkNFQjNG RjBCNTAwQzBCNUZDQTMyODNBN0VCOTJDPkk8RUEwM0YwMTJGRkEzMTIwRjEyMDNCM0IzCkFENDg3 RUI1MTJDMEEzMTIzQTdFQjkxNz5JPDI3MDNGMDBGRjBFQjFGRTAwMEZGRDkzRkZDRUI3RkY4OTEz QUYwM0YwMUUwCjdFOTAzQkYxQzAxRjgzODAzRjNEMEZGMzgwMEZDNzAwMUY4MDI2MDNGNzAwMTND RTAxRkUxNERDNDlEOTA3RjhFQjBGQzBBMgo0OTVDQTM0OTVDQjNBMzQ4NkM0OTZDRUIxRkUwQjUw MEMxQjUwMDgzQjVGQ0EzNDAyNTdFQTQ0NT5JPDM5MDNGMDBGRjAwMApGRkVCM0ZGQ0VDRjAzRjkw MzlGMUMwMUY4MDNBMEZGMzgwMEZDMDM4MDNGNzAwMTNGRTQ5NkQ3RUEyNUJBMzVCQjNBMzQ4NkMK NDk3RUI1MDBDMUI1MTI4MEEzMjkyNTdFQTQyRT5JPEVCMDNGRTkwMzgwRkZGODA5MDM4M0UwM0Uw OTAzOEY4MDBGODQ4NDgKMTM3QzQ4NDg3RjQ4NDg3RjQ4NDhFQjBGODAwMDFGMTVDMDkwQzcxMjA3 NDgxNUUwQTIwMDdFRUMwM0YwQTQwMEZFMTVGOEE5CjAwN0UxNUYwQTIwMDdGMTQwNzZDMTVFMEEy NkM2Q0VCMEZDMDAwMEYxNTgwNkQxMzFGNkM2Q0VCM0YwMDZDNkMxMzdFQzY2QwoxM0Y4OTAzODdF MDNGMDkwMzgxRkZGQzBEOTAzRkVDN0ZDMjUyNzdFQTUyQT5JPDM5MDNGMDFGRTAwMEZGRUI3RkY4 OTAzOApGMUUwN0U5MDM5RjM4MDFGODAzQTA3RjcwMDBGQzBEODAzRkVFQjA3RTA0OUVCMDNGMDQ5 MTRGODQ5MTMwMTE2RkMxNTAwMTYKRkVBMzE2N0ZBQTE2RkVBM0VEMDFGQ0EyNkRFQjAzRjgxNkYw NkQxMzA3NkRFQjBGRTAwMUY2MTRDMDkwMzlGNzgwM0YwMDkwCjM4RjFFMDdFOTAzOEYwRkZGOEVD MUZDMDkxQzhGQ0FCNDg3RUI1MTJDMEEzMjgzNTdFQTQyRT5JPEQ5MDNGODEzQzA5MDM4CjFGRkUw MTkwMzg3RTA3ODE5MDM4RkMwMUMzMzkwM0YwMDBFMzAwMDcxNDc3NDg0ODEzMzc0OTEzM0YwMDFG MTQxRjQ4NUExNQowRjQ4QzdGQ0EzMTJGRUFBMTI3RkEzN0U2RDEzMUYxMjFGNkQxMzNGMTIwRjZD NkMxMzdGNkM2QzEzRUYzOTAxRjgwMUNGMzkKMDA3RTA3OEY5MDM4MUZGRTBGRUIwN0Y4OTBDN0ZD QUJFRDFGRTAwMjAzQjVGQ0EzMjgzNTdEQTQyQz5JPDM4MDdFMDFGMDAKRkZFQjdGQzA5MDM4RTFF M0UwOTAzOEUzODdGMDM4MEZFNzA3RUEwM0U2MTNFRTkwMzhFQzAzRTA5MDM4RkMwMDgwNDkxMzAw CkE0NUJCM0EyNDg3RUI1MTJGMEEzMUMyNTdFQTQyMT5JPEVCRkYwMzAwMDMxM0U3MzgwRjgwRkYz ODFFMDAzRjQ4N0Y0ODdGCjAwNzA3RjEyRjBBMjgwN0VBMjdFQjQ5MEM3RkNFQTdGRTAxM0ZGNkMx M0UwNkMxM0Y4NkM3RjAwMDM3RkM2N0YwMTA3MTM4MApFQjAwN0YxNDFGMDBDMEVCMEZDMDE0MDdB MjZDMTMwM0EzN0UxNTgwNkMxMzA3N0VFQzBGMDBCNDEzMUUzOEYzQzA3QzM4RTEKRkZGMDM4QzAz RjgwMUEyNzdEQTUyMT5JPDEzMThBNTEzMzhBMzEzNzhBMzEzRjgxMjAxMTIwMzEyMDcwMDFGQjVG Q0I2RkMKQTJEODAxRjhDN0ZDQjIxNUMwQTkzODAwRkMwMTE1ODBFQjdDMDMwMTdFMTMwMDZENUFF QjBGRkVFQjAxRjgxQTM0N0ZCMjIwCj5JPEQ4MDNGMEVCMDdFMDAwRkZFQjAxRkZBMzAwMEZFQjAw MUYwMDAzMTQwN0IzQTQxNTBGQTMxNTFGMTIwMTZEMTMzRjAwCjAwRUM3N0Y4NkQ5MDM4RTdGRjgw OTAzODNGMDNDNzkwMzgxRkZGODc5MDNBMDNGQzA3RTAwMDI5MjY3RUE0MkU+STxCNTM4CjgwM0ZG RUEzM0EwRkY4MDAwRkYwNkM0OEVCMDdFMDAwMDNFQzAzQzA2RDE0ODAwMDAxMTUwMEEyNkM2QzEz MDZBMjZEMTMwRQowMTdFMTMwQ0EyNkQ1QkEyRUM4MDM4MDExRjEzMzBBMjZENkM1QUEyMTRFMDAx MDc1QkEyOTAzODAzRjE4MEEzRDkwMUZCQzcKRkNBMjE0RkY2RDVBQTIxNDdDQTMxNDM4QTIyNzI1 N0VBMzJDPkk8QjUzQTFGRkZFMDNGRkVBMzI2MEZGODAwOTAzODAwMEYKRjg2QzQ4MDE3RUVCMDNF MDE4QzAwMDAzMDIzRUVCMDE4MEEyNkM2QzAxM0ZFQjAzMDBBMzZDNkNFQzgwMDYxNTZGQTIwMTdF CjkwMzhFRkMwMEMxNUM3QTJEOTNGMDE2RDVBMTU4MzAyODFFQkYwMzhEOTFGODMxNDMwMTUwMTAy QzNFQkY4NzA5MDI2MEZDNgowMDEzNjBBMkQ5MDdFNjZENUEwMkVDMTM3Q0EyRDkwM0ZDRUI3Rjgw NEExMzNGQTIwMTAxOTJDN0ZDNEE3RkEyMDEwMDE0MUUKNEExMzBFMDI2MDEzMEMzNzI1N0VBMzND Pkk8QjUzODgwN0ZGRkEzM0EwM0ZFMDAzRkYwMDAwMUVDMUY4MDAwMDA5MkM3RkMKMDE3RTEzMUM2 RDEzMTg2RDZDNUFFQ0MwNzAwMTBGNUI2RDZDNUFFQ0YxODBFQjAzRkI2REI0QzhGQzZENUFBMjE0 N0Y4MDRBCjdFODExNENGOTAzODAxQzdFMDkwMzgwMzgzRjA5MDM4MDcwM0Y4RUIwNjAxNDk2QzdF MDExQzEzN0U0OTEzN0YwMTc4N0Y0OQo2RDdFNDg2QzgwMDAwRkVDM0ZGMEQ4RkZGRTkwQjUxMjgw QTMyOTI0N0ZBMzJDPkk8QjUzODgwM0ZGRUEzM0EwRkY4MDAwRgpGMDZDNDhFQjA3QzAwMDAzRUMw MzgwNkM3RTE2MDA3RjAwMDAxNDA2QTIwMTdFNUJBMjEzN0Y2RDVCQTI2RDZDNUFBMkVDQzAKNzAw MTBGMTM2MEEyNkQ2QzVBQTIxNEYxMDEwMzVCQTJEOTAxRkJDN0ZDQTIxNEZGNkQ1QUEyMTQ3Q0Ez MTQzOEEyMTQzMEEyCjE0NzAxNDYwQTI1Q0EyRUE3QzAxMDBGRTVCMTMwMzkxQzhGQzEzMDZFQUZD MEVFQTcwMUM2QzVBRUExRkYwRUEwRkMwMjczNQo3RUEzMkM+STwwMDNGQjUxMkZDQTJFQjgwMDNE ODNFMDAxM0Y4MDAzQ0VCMDdGMDAwMzhFQjBGRTAxMjMwMDA3MEVCMUZDMApFQzNGODAwMDYwMTM3 RjE1MDAxNEZFNDk1QUEyQzY0ODVBNDk1QUEyNDk1QTQ5NUE0OTVBQTI5MDM4N0YwMDA2MTNGRUEy NDgKNUE0ODVBMDAwNzE0MEU1QjQ4NDgxMzBDNDg0ODEzMUNBMjQ4NDgxMzNDNDhDNzEyN0M0OEVC MDNGQzkwQjVGQ0EyMUYyNDdFCkEzMjU+SSBFCiVFbmREVklQU0JpdG1hcEZvbnQKJURWSVBTQml0 bWFwRm9udDogRmggY21yMTIgMTIgMzUKL0ZoIDM1IDEyMiBkZjw0QUI0RkMwMjBGMTNFMDkxMzg3 RjgwRjg5MDM5MDFGQzAwMUM0OTQ4N0ZEOTA3RTAxMzBGNDk0ODEzCjdGMDExRkVDRkY4MDQ5NUE0 OUM3RkNBMjVCNDlFQzdGMDAxNjNFOTNDN0ZDQUNFRTNGODBCOEZDQTNDNjQ4QzdGQzE2N0YxNgoz RkIzQjA0ODZDRUM3RkMwMDA3RkQ5RkMxRkI1RkNBMzMwNDY3RUM1MzY+MTIgRDwxMjFFRUE3Rjgw MTJGRjEzQzBBMjEzRTAKQTMxMjdGRUExRTYwMTIwMEE0MTNFMDEzQzBBMzEyMDExMzgwMTIwMzEz MDA1QTEyMDYxMjBFNUE1QTVBMTI2MDBCMUQ3ODg5CjFCPjQ0IEQ8MTRGRjAxMDcxM0UwOTAzODFG ODFGODkwMzgzRTAwN0MwMUZDMTMzRjQ4NDhFQjFGODA0OTEzMEY0ODQ4RUIwNwpDMDQ4NDhFQjAz RTBBMjAwMEYxNUYwNDkxMzAxMDAxRjE1RjhBMjAwM0YxNUZDQTM5MEM4RkM0ODE1RkVBNTQ4MTVG RkIzQTQKNkMxNUZFQTU2RDEzMDEwMDNGMTVGQ0EzMDAxRjE1RjhBMjZDNkNFQjAzRjBBMzZDNkNF QjA3RTAwMDAzMTVDMDZEMTMwRjZDCjZDRUIxRjgwNkM2Q0VCM0YwMDAxM0UxMzdDOTAzODFGODFG ODkwMzgwN0ZGRTAwMTAwOTBDN0ZDMjg0NDdDQzEzMT40OApEPEVCMDNGRTkwMzgxRkZGQzAwMTdG MTNGMDM5MDFGODBGRkMzOTAzQzAwMUZFNDg0ODZDN0UwMDBFQzdFQTdGODA0OEVDM0YKQzBFRDFG RTA0ODE1RjAwMDMwMTQwRjAwNzAxNUY4MDA2MDE0MDcxMjZDQjQxNUZDN0Y3RjE1MDNBNDZDNDgx MzA3NkNDN0ZDCkM4RkMxNkY4QTIxNTBGMTZGMDE1MUYxNkUwQTJFRDNGQzBFRDdGODAxNjAwNUQ1 RDRBNUE0QTVBNEE1QTVENEE1QTRBNUE0QQpDN0ZDMTQ3QzVDNUM0OTVBNDk1QTQ5NUE0OUM3MTIw QzEzMUU1QjAxMzgxNDE4NUI1QjQ4NUE0ODQ4MTQzODQ4QzgxMjMwMDAKMEUxNTcwMDAxRkI2MTJG MEEyNUE1QUI3MTJFMEEzMjY0MjdCQzEzMT41MCBEPDQ5QjRGQzAxMEYxM0UwMDEzRjEzRkM5MDM4 CkZFMDFGRTNBMDFGMDAwN0Y4MEQ4MDNDMEVCM0ZDMDQ4QzdFQTFGRTAxMjBFRUQwRkYwRUEwRkUw NDg2QzE0RjhBMjE1MDc3Rgo1QkEyNkM0ODEzMEZFQTAzQzBDODEzRjBBM0VEMUZFMEEyRUQzRkMw MTY4MEVEN0YwMDE1RkU0QTVBRUMwM0YwRUMxRkMwRDkKMEZGRkM3RkMxNUYwOTAzODAwMDFGQ0VD MDA3RkVEM0Y4MEVEMUZDMEVEMEZFMDE2RjBFRDA3RjgxNkZDMTUwMzE2RkVBMjE1CjAxMTZGRkEz MTIxRUVBN0Y4MDQ4N0VBNDE2RkU0OTEzMDNBMjAwN0VDNzEzRkMwMDcwMTQwNzAwMzAxNUY4MDAz ODE0MEY2QwoxNUYwNkNFQzFGRTA2QzZDRUIzRkMwRDgwM0UwRUI3RjgwM0EwMUZFMDFGRTAwMzkw MDdGRkZGODAxMEYxM0UwMDEwMTkwQzcKRkMyODQ0N0NDMTMxPkk8MTRGRjAxMDcxM0UwMDExRjEz Rjg5MDM4N0YwMEZFMDFGQzEzM0ZEODAxRjBFQjFGODA0ODQ4RUIKMEZDMDQ5RUIwN0UwMDAwN0VD MDNGMDQ4NDgxMzAxQTI5MEM3MTNGODQ4MTQwMEE0N0ZBMjZEMTMwMTE2RjA3RjZDNkNFQjAzCkUw MTNGQzZDNkNFQjA3QzA5MDM5RkY4MDBGODA2QzkwMzhDMDFGMDA2Q0VCRjAzRUVDRjg3ODM5MDA3 RkZFRjA5MDM4M0ZGRgpDMDdGMDEwNzdGNkQxM0Y4NDk3RjkwMzgxRTdGRkZEOTdDMUYxMzgwNDk2 QzEzQzAyNjAxRTAwMzEzRTA0ODQ4NkMxM0YwMDAKMDc5MDM4MDA3RkY4NDg0OEVCM0ZGQzQ4Qzcx MjBGMDAzRUVDMDdGRTE1MDE0ODE0MDAxNkZGMTY3RjQ4MTUzRkEyMTYxRkE1CjZDMTUxRTAwN0Mx NTNFQTIwMDdFMTUzQzAwM0UxNTdDNkMxNUY4NkRFQjAxRjA2QzZDRUIwM0UwNkM2Q0VCMDdDMEQ4 MDNGOApFQjFGODBDNkI0RUJGRjAwOTAzODNGRkZGQzAxMEYxM0YwMDEwMTEzODAyODQ0N0NDMTMx PjU2CkQ8MTZDMDRCN0VBMzRCN0VBMzRCN0VBMzRCN0VBM0VEMTlGRUEzRUQzMEZGQTIwMzcwN0ZF RDYwN0ZBMjAzRTA3RkVEQzAzRgpBMjAyMDE4MEVEODAxRkEyREEwMzAwN0YxNjBGQTIwMjA2ODAx NjA3QTI0QTZEN0VBMzRBNkQ3RUEzNEE2RDdFQTIwMjcwODEKMDI2MDE0N0ZBMjAyRTA4MTkxQjdG Q0EyNDk4MjAyODBDNzEyMUZBMjQ5Qzg3RjE3MEZBMjAxMDY4MjE3MDdBMjQ5NkY3RUEzCjQ5NkY3 RUEzNDk2RjdFQTIwMTc4ODMxM0Y4NDg2QzgzRDgwRkZGMDMwMzdGQjUwMEUwMDI3RkVCRkZDMEEz NDI0NzdEQzY0OQo+NjUgRDxEQjBGRkUxNDYwOTJCNTAwQzAxM0UwMDIwMzE0RjA5MTNBMEZGQzAx RkMwMTkxMzkzRkMwMDAzRTAyRkZDN0VBMEYKODNEOTAzRkNFQzAzQzc0OTQ4RUMwMUU3NDk0OEVD MDBGRjQ5NDgxNTdGNDk0ODE1M0Y0OTQ4MTUxRjQ5QzkxMjBGNDg1QTQ5CjE2MDcxMjAzNDg0ODE2 MDNBMjQ4NDgxNjAxQTI0ODQ4MTYwMEEyMTIzRkEyNDkxNzYwMTI3RkEzMTkwMDQ4NUFBRTZDN0VB MgoxOTYwQTIxMjNGN0ZBMjAwMUYxOEUwN0YwMDBGMThDMEEyNkM2QzE2MDExOTgwNkM2QzE2MDMx MjAxNkRFRTA3MDA2QzZDMTYKMDY2RDZDMTUwRTZENkM1RDZENkM1RDZENkMxNTc4NkQ2QzVENkQ2 QzRBNUFEOTAwRkZFQzA3ODBEQTNGQzAwMTFGQzdGQ0RBCjBGRkMxM0ZDMDIwM0I1MTJGMDAyMDAx NEMwREIwRkZFQzhGQzNCNDg3QkM1NDY+NjcgRDxCOTEyRjBBMzAwMDEwMUMwQzcxMgo3RjZDNkM0 OEVDMEZGODE3MDMxNzAxMTcwMDE4NzgxODM4QTIxODFDQTMxODBDQTQxODBFMTgwNjE2MENBMjE4 MDBBNTE2MUMKQTIxNjNDMTY3Q0VEMDFGQzkxQjVGQ0EzRUM4MDAxRUQwMDdDMTYzQzE2MUNBMjE2 MENBNzkzQzhGQ0IwODA0ODQ4N0VCNjEyCkY4QTMzNzQ0N0NDMzQwPjcwIEQ8QjU2QzAyMEZCNUZD ODA4MEM2MDQwMDEzRjA2RDZDRUQxRjgwRDk2RkY4RUQwRjAwQTJEOQo2N0ZDMTUwNkVCNjNGRUEy RUI2MUZGMDE2MDdGQTI2RTdFNkU3RUEyNkU3RTZFN0VBMjZFN0U2RTdFQTI2RTdFNkU3RkEyNkYK N0U2RjdFQTI2RjdFNkY3RUEyNkY3RTZGN0VBMjZGN0U2RjEzODBBMkVFN0ZDMEVFM0ZFMEEyRUUx RkYwRUUwRkY4QTJFRTA3CkZDRUUwM0ZFQTJFRTAxRkY3MDEzODZBMkVGN0ZDNkVGM0ZFNkEyRUYx RkY2RUYwRkZFQTIxNzA3MTcwM0EyMTcwMTE3MDBBMgowMUYwMTY3RTE4M0U0ODdFRDgwRkZGMTYx RUI1MDBGMDE1MEVBMjE4MDY0MDQ0N0NDMzQ5Pjc4CkQ8RUQxRkZDNEFCNTEyQzA5MTM5MDdGMDA3 RjA5MTM5MUY4MDAwRkMwMjdFQzcxMjNGRDkwMUY4RUMwRkMwNDk0ODZFN0U0OQo0ODZFN0U0OTQ4 NkU3RTQ5NDg2RTdFNDlDOTEyN0UwMTdFODIwMUZFODM0ODQ4NzA3RTQ4NDg3MDdFQTI0ODQ4NzA3 RUEyMDAKMEY4NDQ5MTYwMzAwMUY4NEEyNDg0ODcwN0VBMzAwN0Y4NEEyNDk4MkEzMDBGRjE5ODBB RDZDNkM0QzEzMDBBNDAwM0Y2MDZECjE2MDNBMjAwMUY2MEEyNkM2QzRDNUFBMjZDNkM0QzVBQTIw MDAzNjA2RDE2MUY2QzZDNEM1QTAwMDA2MDAxN0Y0Q0M3RkM2RQo1RDAxM0Y1RTZENkM0QTVBRDkw N0UwRUMwM0YwNkQ2QzRBNUFEOTAxRkNFQzFGQzBEOTAwN0U0QUM4RkNEQTFGODAxM0ZDOTEKMzkw N0YwMDdGMDAyMDFCNTEyQzA5MTI2MDAxRkZDQzlGQzQxNDg3QkM1NEM+STwwMDNGQjkxMkY4QTM5 MDNCRjAwMDFGRjgKMDAxRjAxODA2RDQ4MTMwMzAwM0VDNzE1MDA0ODE4N0MwMDc4MTgzQ0EyMDA3 MDE4MUNBMzAwNjAxODBDQTU0ODE4MDZBNUM4CjE2MDBCM0IzQTU0QjdFRUQ3RkZFNDlCNzdFQTMz RjQ0N0RDMzQ2Pjg0IEQ8QjYwMTA3QjUwMEY4OTAzODBGRkZGRUEzMDAwMwowMUUwRDkwMDFGOTBD ODEzRjA2QzAxODBEQTBGRkNFRDNGQzA5MUM4NkM0OEVEMUYwMDZDODcxQzBFNkQ2QzZFN0UxQzBD QTIKNkQ2QzZGNURBMzZFREEwNkZGMTUzODAxMUYxQTMwQTI2RTAyMEU2RDE0NzAwMTBGREIwQzdG MTU2MEEyNkUwMjFDN0YwMTA3CkRCMTgzRjVEQTI4NTZENkNEQTMwMUY0QTVBQTM2RDZDNEE2QzZD NDlDN0ZDQTM2RDZDNEE2QzZDMTMwNkEzREI4MDAxNkUxMwowRTAyN0ZEQTgwMDMxNDBDQTJEQkMw MDM4MDAyM0ZEQTAwMDE1Q0EyMDNFMDgxMDIxRjAxMDY2RDVDQTM2RTZDNDg2RTZDNUEKQTM2RTZD NDg2RTZDNUFBMzZGNDhFQzFGRTEwMjAzNjBBMkRCRkU3MDE1RjMwMjAxMDE2MDAyMEY5MEM4RkNB MkRCRkZFMDE1CkZCNkU0OUVDMDdGRUEzNkY0ODZFNUFBMzZGQzg2QzVBQTMwMzFFNkY1QUE0MDMw QzE2NjA1RjQ2N0VDMzY0Pjg3CkQ8QjY2QzkxMzgwRkZGRkNBMzAwMDEwMUY4QzgwMDAzMTNDMDI2 MDA3RkUwOTIzODAwRkUwMDYxMDEzRjE3RjA2RDZDNUU4MAowMTBGNUY2RDZDNEI1QTE4MDM2RDZD OTNDN0ZDNkUxNTA2NkQxNjBFNkQ2RDE0MEMxODFDNkU2QzE0MTg2RTZDNUMxODcwNkUKNkMxNDYw MThFMDZFNkM1QzZFNkM0OTVBMTcwMzZFNkM5MUM4RkM1RjZFNkMxMzA2NkU2RDVBMTcxQzkyMzg3 RkMwMTg1RkVECjNGRTA2RjZDNUExN0UwNkY2QzVBRUVGOTgwRUQwN0ZGNkY5MEM5RkNBMjZGNUFC M0E2OTIzODA3RkY4MDAyMDNCNkZDQTM0Ngo0NDdGQzM0OT44OSBEPEVCMDdGQzkwMzgzRkZGODA5 MDM4RjgwRkUwMzkwM0MwMDNGMDQ4QzY2QzdFMDAwRTZEN0VEODBGQzAKMTM3RTQ4NkMxMzdGNkQ2 RDdFQTM2RjdFQTI2QzVBRUEwMzgwQzhGQ0E0RUMwRkZGNDlCNUZDOTAzODBGRkUxRkVCM0ZDMEVC CkZGMDBFQTAzRkM0ODVBNDg1QTQ4NUE0ODVBMTI3RjVCMTc2MDQ4QzdGQ0EzMTUzRkEzNkQxMzdG MDA3RjE0RUY2RDkwMzhDNwpFMEMwMDAzRjEzMDEzQTFGRTAwNzgzRjEzQjA3RjgxRTAzRkY4MDI3 MDFGRkZDMDExMzAwM0EwMDFGRTAwMDdDMkIyRTdDQUMKMzE+OTcgRDxFQTAxRkMxMkZGQTMxMjA3 MTIwMzEyMDFCM0VDMDNGQzkxMzgwRkZGODA5MTM4M0MwN0UwOTEzODcwMDFGODkwCjM5RkRFMDAw N0UwMjgwN0YwMUZGRUMxRjgwOTFDNzEzQzA0OUVDMEZFMDQ5MTQwNzE3RjBBMkVFMDNGOEEyMTdG Q0EyMTYwMQoxN0ZFQUIxN0ZDMTYwM0EyMTdGOEEyRUUwN0YwQTI2REVDMEZFMDE3QzA2RDE0MUYw MUZCRUMzRjgwRDlGMzgwRUI3RTAwRDkKRTFDMDVCOTAzOUUwRjAwMUY4OTAzOUMwM0MwN0UwOTAz OTgwMUZGRjgwQzdEODAzRkNDN0ZDMkY0NjdEQzQzNj5JPEVDN0YKODA5MDM4MDNGRkYwOTAzODBG QzA3QzkwMzgzRjAwMEYwMUZDRUIwMzgwNDg0OEVCMDFDMDAwMDMxNDBGNDg0OEVCMUZFMDQ5CjEz M0YxMjBGNDg1QUEyNDg1QUVEMUZDMDAwN0ZFQzA3MDA5MkM3RkNBMjkwQzlGQzVBQUI3RTdGQTIx MjNGMTYzMDdGMDAxRgoxNTcwNkM2QzE0NjAxNkUwNkM2QzE0QzA2QzZDMTMwMTAwMDFFQzAzODA2 QzZDRUIwNzAwMDEzRjEzMUU5MDM4MUZDMDc4OTAKMzgwN0ZGRjAwMTAwMTM4MDI0MkU3REFDMkI+ STwxNjdGRUQzRkZGQTMxNTAxODE4MkIzRUM3RjgwOTAzODAzRkZGMDkwMzgKMEZDMDdDOTAzODNG MDAwRTAxN0UxMzA3NDk2RDVBRDgwM0Y4N0Y0ODQ4N0Y1QjAwMEY4MTQ4NUFBMjQ4NUFBMjEyN0ZB MjkwCkM4RkM1QUFCN0U3RkEyMTIzRkEyNkM3RUEyMDAwRjVEN0Y2QzZDNUIwMDAzNUM2QzZDOTAz ODA3N0Y4MDZDNkMwMTBFMTNDMAowMTNGMDExQzEzRkU5MDM4MEZDMEY4OTAzODAzRkZFMDkwMjYw MDdGMDAxMzAwMkY0NjdEQzQzNj5JPEVCMDFGRTkwMzgwNwpGRkMwOTAzODFGMDNGMDkwMzg3RTAw RkM0OTEzN0U0ODQ4N0Y0ODVBNDg0OEVCMUY4MDAwMEYxNUMwNDkxMzBGMTIxRjQ4NDgKMTRFMDE1 MDdBMjAwN0YxNUYwOTBDN0ZDQTI1QUEzOTBCNkZDQTI5MEM5RkNBNjdFQTI3RkEyMTIzRjE2MzA2 QzdFMTY3MDAwCjBGMTU2MDZEMTRFMDZDNkMxNEMwMDAwMzE0MDE2QzZDRUIwMzgwNkM2Q0VCMDcw MDAxM0UxMzFFOTAzODFGODBGODkwMzgwMwpGRkUwMDEwMDkwQzdGQzI0MkU3REFDMkI+STxFQzBG RTBFQzdGRjg5MDM4MDFGODFFOTAzODAzRjAzRjkwMzkwRkUwN0Y4MAo5MDM4MUZDMEZGNUMxMzNG NDk1QUEyRUQ3RjAwMDFGRTEzMUM5MkM3RkNBRkI2N0VBM0M2NDhDOEZDQjNCMjQ4NkM3RTAwN0YK MTNGRkEzMjE0NjdFQzUxRT5JPEVFMEY4MEQ5MDFGQ0VCN0ZFMDkwM0EwRkZGODFGMEYwOTAzOTNG MDdFMzgxOTAzOUZDMDEKRkYwMzNBMDFGODAwRkUwMTQ4NDgwMTdFMTNFMDAwMDcwMjdGQzdGQzQ5 N0YwMDBGODE0OTEzMUYwMDFGODFBOTAwMEY1RDZECjEzM0YwMDA3OTJDN0ZDNkQ1QjAwMDMxNDdF NkM2QzVCNkQ0ODVBMzkwM0JGMDdFMDkwMzgwRkZGODAyNjA3MDFGQ0M4RkM5MApDQUZDQTI1QUEz N0Y2QzdFN0Y5MEI1MTJGODZDMTRGRjE2RTA2QzE1Rjg2QzZDODA0OEI2N0UzQTA3QzAwMDBGRkY0 ODQ4MTMKMDAwMDNGQzhFQTNGODAwMDNFMTUxRjQ4RUQwRkMwQTI0ODE1MDdBNTZDMTUwRjAwN0Mx NjgwMDA3RTE1MUYwMDNFMTYwMDZDCjE1M0U2QzZDNUNEODA3RTA0OTVBRDgwMUY4RUIwN0UwRDgw MDdGRUIzRjgwOTAyNjFGRkZGRUM3RkMwMTAxMTNFMDJDNDI3RApBQzMxPkk8RUEwMUZDMTJGRkEz MTIwNzEyMDMxMjAxQjNFQzAxRkU5MTM4MDdGRkMwOTEzODFFMDdGMDkxMzgzODAxRjgwMgo3MDdG RUNFMDAwRDlGREMwN0Y1QzAxRkYxNDdGOTFDN0ZDQTI1QkEzNUJCM0E4NDg2Q0VDRkY4MEI1RDhG ODNGMTNGRUEzMkYKNDU3REM0MzY+STxFQTAxRTBFQTA3RjhBMjQ4N0VBNDZDNUFBMkVBMDFFMEM4 RkNBREVBMDFGQzEyRkZBMzEyMDcxMjAzMTIKMDFCM0IwNDg3RUI1MTJGOEEzMTU0MzdEQzIxQz5J PEVBMDFGQzEyRkZBMzEyMDcxMjAzMTIwMUIzQTI5MjM4MUZGRkUwQTMKNkYxMzAwRUQwN0Y4MTZF MDVFNUUwMzBFQzdGQzVENUQ1RDVENEE1QTRBNUE0QUM4RkM1Q0VDM0Y4MDRBN0UxNEZGOTAzOEZE CkNGRTA5MDM4RkY4RkYwMTQwNzQ5NkM3RTAxRkM3RjE0MDE2RTdFODE4MTZGN0U4MjE1MUY2RjdF ODIxNTA3ODI2RjdFODI4Mgo0ODZDNDkxMzgwQjVEOEY4MUYxM0Y4QTMyRDQ1N0RDNDMzPjEwNyBE PEVBMDFGQzEyRkZBMzEyMDcxMjAzMTIwMUIzQjNCMwpBNTQ4N0VCNTEyRjhBMzE1NDU3REM0MUM+ STxEODAxRkMwMUZGRUMxRkUwMDBGRjAxMDcwMUUwRUJGRkZDOTEzQjBGMDNGOAowMUUwN0Y5MTND M0MwMUZDMDc4MDNGODAwMDA3OTAzQzcwMDBGRTBFMDAxRkMwMDAwMzQ5RDk3RTFDMTMwRjI2MDFG REMwRDkKN0YzODgwNEExNDMwMDFGRkRBM0ZGMDZEN0U5MUM3NUJBMjQ5NURBMzQ5NURCM0E4NDg2 QzRBNkM0OTdFQjVEOEY4MUZCNTAwCjAzQjUxMkUwQTM0QjJDN0RBQjUyPkk8MzkwMUZDMDFGRTAw RkY5MDM4MDdGRkMwOTEzODFFMDdGMDkxMzgzODAxRjgwMDA3CjAxNzA3RjAwMDNFQkUwMDAyNjAx RkRDMDdGNUMwMUZGMTQ3RjkxQzdGQ0EyNUJBMzVCQjNBODQ4NkNFQ0ZGODBCNUQ4RjgzRgoxM0ZF QTMyRjJDN0RBQjM2Pkk8RUM3RjgwOTAzODAzRkZGMDkwMzgwRkMwRkM5MDM4M0UwMDFGNDk2RDdF NDk2RDdFNDg0OAo2RDdFNDg0ODZEN0U0ODQ4NkQ3RTAwMEY4MUEyNDg0ODE0N0UwMDNGMTU3RkEy OTBDODdFNDgxNjgwQTQ0ODE2QzBBQTZDMTYKODBBMjZEMTQ3RjAwM0YxNjAwQTIwMDFGMTU3RTZE MTRGRTAwMEY1RDZEMTMwMTAwMDc1RDZDNkM0OTVBNkM2QzQ5NUE2QzZDCjQ5NUEwMTNFNDlDN0ZD OTAzODFGQzBGRTkwMzgwN0ZGRjg5MDM4MDA3RjgwMkEyRTdEQUMzMT5JPDM5MDFGQzAzRkMwMEZG CjkwMzgwRkZGODA5MTM4M0MwN0UwOTEzODcwMDFGODNBMDdGREUwMDBGRTAwMDEwMTgwMTM3RjAx RkZFQzNGODA5MUM3RUExRgpDMDQ5MTVFMDQ5MTQwRjE3RjAxNjA3MTdGODE2MDMxN0ZDQTNFRTAx RkVBQkVFMDNGQ0EzRUUwN0Y4QTIxN0YwMTYwRjZEMTUKRTBFRTFGQzA2RDE0M0YxNzgwNkVFQjdF MDBEOUZEQzA1QjkwMzlGQ0YwMDNGODkxMzgzQzBGRTA5MTM4MUZGRjgwREEwM0ZDCkM3RkM5MUM5 RkNBRTQ4N0VCNTEyRjhBMzJGM0Y3REFCMzY+STwzOTAzRjgwM0YwMDBGRkVCMUZGQ0VDM0MzRUVD NzA3RjAwCjA3RUJFMEZGMzgwM0Y5QzAwMDAxNUIxM0ZCRUMwMDdFMTUzQzAxRkYxMzAwNUJBNDVC QjNBNzQ4QjRGQ0I1MTJGRUEzMjAyQwo3REFCMjY+MTE0IEQ8OTAzODNGRTAxODM5MDFGRkZDMzgz OTA3RTAxRjc4MzkwRjAwMDNGODAwMUUxMzAxNDgxMzAwMDA3QwoxNDc4MTI3ODAwRjgxNDM4QTIx NTE4QTI3RUEyN0U2QzZDMTMwMDZDN0UxM0ZDMzgzRkZGRTA2QzEzRkM2QzEzRkY2QzE0QzAKNkMx NEUwQzYxNEYwMDExRjEzRjgxMzAwRUMwRkZDMTQwMzAwQzBFQjAxRkUxNDAwMTU3RTdFMTUzRUEy N0VBMzZDMTQzQzZDCjE0N0MxNTc4NkMxNEY4NkNFQjAxRjAzOUYzODAwM0UwMzlGMUYwMEY4MDM5 RTA3RkZFMDAzOEMwMEZGMDFGMkU3REFDMjY+Ckk8MTMwNkE1MTMwRUE0MTMxRUEzMTMzRTEzN0VB MjEzRkUxMjAxMTIwNzAwMUZCNTEyRjBCNkZDQTJDNjQ4QzdGQ0IzQTQxNQowQ0FBMDE3RTEzMUMw MTdGMTMxOEEyNkQxMzM4OTAzODFGODAzMEVDQzA3MDkwMzgwN0UwRTA5MDM4MDFGRkMwOTAzODAw N0YKMDAxRTNFN0VCQzI2Pkk8RDgwMUZDMTQ3RjAwRkZFQzNGRkZBMzAwMDcxNDAxMDAwMzgwMDAw MTgxQjNBODVFQTM1REEyMTIKMDA2RDVCMDE3RTkwMzgwNzdGODAwMTdGMDEwRTEzQzA2RDAxMUMx M0ZFOTAzODBGQzA3ODkwMzgwM0ZGRjA5MDI2MDA3RjgwCjEzMDAyRjJEN0RBQjM2Pkk8QjUzOUYw MDFGRkZDQTMwMDA3OTBDN0VBN0ZFMDZDNDhFQzFGODAwMDAxMTYwMDE2MEUxMjAwCjE2MEMwMTdG NUNBMjgwMDEzRjVDQTI2RTEzNzAwMTFGMTQ2MDgwMDEwRjVDQTJFQ0YwMDEwMTA3NUNBMjZENkM0 OEM3RkNBMgo2RTVBMDEwMTEzMDZBMjZENkM1QUEyMTRGRjZFNUFBMjE1QjhFQzNGQjAxNUYwNkU1 QUEzNkU1QUEyNkU1QUEzNkVDOEZDMkUKMkM3RUFBMzM+STxCNTM5RjAwMUZGRkNBMzAwMDc5MEM3 RUE3RkUwNkM0OEVDMUY4MDAwMDExNjAwMTYwRTAwMDAxNTBDNkQKMTQxQzZEMTQxOEEyNkUxMzM4 MDEzRjE0MzBBMjZENkM1QkEyNkUxM0UwMDEwRjVDQTI2RDZDNDg1QUEyRUNGODAzMDEwMzkxCkM3 RkNBMjkwMzgwMUZDMDZBMkVDRkUwRTAxMDAxMzBDQTJFQzdGMThBMjE1QjhFQzNGQjBBMkVDMUZF MEEzNkU1QUEyNkU1QQpBMzZFQzhGQ0EyMTQwNkEzNUNBMjVDQTIxMjNDMDA3RTVCQjRGQzVDQTI1 Q0VBRkUwMTM4N0MwMzgwRDg3MDA3QzlGQ0VBM0MKMUVFQTBGRkNFQTAzRjAyRTNGN0VBQTMzPjEy MSBEIEUKJUVuZERWSVBTQml0bWFwRm9udAolRFZJUFNCaXRtYXBGb250OiBGaSBjbXIxNyAxNy4y OCAxMgovRmkgMTIgMTIyIGRmPDAyMEZCNjEyRkNBNERBMDAwMUVCRkUwMDkyMzgwMDNGRkM1RjE2 MUZCM0IzQjNBRTEyMDdFQTNGRTAKNDg3RUEyNDg3RUEzNEM1QUEzNUI2QzQ4NEE1QTEzODAwMDc4 Qzg0ODVBNkM1RTVENkM5M0M3RkM2QzRBNUE2QzZDNDk1QUQ4CjAzRTA0OTVBRDgwMUY4RUIzRkUw RDgwMDdGRUJGRkMwNkRCNUM4RkMwMTA3MTNGODAxMDAxM0MwMzY2NDdBRTE0ND43NApEPEI3MTJF MEE0QzYwMjgwQ0FGQ0Q5M0ZGQ0NCRkMxMzFGNUNCM0IzQjIxQTFDQTYxQTNDMUEzOEE2MUE3OEE0 MUFGOEEyMUEKRjAxOTAxQTIxOTAzMTkwN0EyMTkwRjE5MUYxOTNGMTk3RkYwMDFGRjE4MDcwMTNG MDQzRjEzRTBEOUZGRkMwMjAzQjVGQ0JCCkZDQTQ0NjYyNzlFMTUzPjc2IEQ8OTMzODAxRkZFMDA0 M0YxM0ZGNEJCNjEyRTAwMzA3OTAzODAwM0ZGOERCMUZGMEVCMDNGRQpEQjdGQzA5MDM4MDBGRjgw NEE0OEM4RUEzRkUwREEwM0ZDRUQwRkYwREEwRkYwRUQwM0ZDNEE0ODZGN0U0QTQ4NkY3RTRBNDgK NzA3RTRBQ0E2QzdFNDk0ODcxN0U0OTQ4NzE3RTQ5NDg3MTdFNDk0ODcxN0U0OTQ4NzE3RTAxM0Y4 NTRBODMwMTdGODY0OTQ4CjcyN0VBMjQ4OTBDQzZDN0VBMjQ4NDg3MzdFQTI0ODQ4NzM3RUEyMDAw Rjg3NDkxOTA3MDAxRjg3QTM0ODQ4NzM3RUE0MDA3RgoxQzgwQTI0OTg1QTQwMEZGMUNDMEFGNkM2 QzRGMTM4MEE1MDAzRjFDMDA2RDYxQTMwMDFGNjNBMjZEMTkwRjAwMEY2M0EyNkMKNkM0RjVBQTM2 QzZDNEY1QUEyNkM2RDRFNUE2QzYzNkUxOEZGMDE3RjYyNkQ2QzREOTBDN0ZDNkU1RjAxMUY2MTZE NkM0RDVBCjZENkM0RDVBMDEwMzYxNkUxNzFGNkQ2QzRENUE2RDZENEM1QURBM0ZDMDRDQzhGQ0RB MUZGMEVEMDNGRTZFNkM0QjVBNkU2Qwo0QjVBREEwMUZGRUQzRkUwOTEyNjAwN0ZDMEVDRkY4MERC MUZGMEQ5MDNGRUM5RkNEQjA3RkZFQjNGRjgwMzAxOTBCNTEyRTAKREIwMDNGOTFDQUZDMDQwMTEz RTA1QTY2N0FFMzY3Pjc5IEQ8OTMzODAxRkZFMDA0M0YxM0ZGNEJCNjEyRTAwMzA3OTAzODAwCjNG RjhEQjFGRjBFQjAzRkVEQjdGQzA5MDM4MDBGRjgwNEE0OEM4RUEzRkUwREEwM0ZDRUQwRkYwREEw RkY4RUQwN0ZDREExRgpFMEVEMDFGRTRBNDg2RjdFNEE0ODcwN0U0QUNBNkM3RTQ5NDg3MTdFNDk0 ODcxN0U0OTQ4NzE3RTAxMEY4NTQ5NDg3MTdFNDkKNDg3MTdFQTI0OTQ4NzE3RjAxRkY4NjRBMTg3 RjQ4OTBDQzZDN0VBMjQ4ODc0OTE5MUYwMDA3ODc0OTE5MEYwMDBGODdBMjAwCjFGODc0OTE5MDdB MjAwM0Y4N0EyNDk4NUEyMDA3RjFDODBBNDQ5ODVBMjAwRkYxQ0MwQUYwMDdGMUM4MDZENjFBNDAw M0YxQwowMEEzNkQ2MTAwMUY2M0EzNkM2QzRGNUFBMjAwMDc2MzZEMTkxRkEyNkM2QzRGNUFBMjZD NjM2QzZEREEzRjgwNEE1QUVGRkYKRTA2RDZDMDEwMzAxRjg0QTVBNkQ2QzkwMjYwN0MwN0M0OTkw QzdGQzkzMzgwRjAwMUU2RDZDMDExRTZENDk1QTZENkM2RjQ5CjVBMDEwNzAyMUNEOTAzODA1QjZE NkMwMTNDNkQ2QzQ4NUE2RTAxMzgxNTFGNkQ2QzAzMDA0OTVBNkQwMTgwNkY0ODVBREEzRgpDMDRD QzhGQ0RBMUZFMEVENzFGRTkxMjYwRkY4M0NFQzc3RkM5MTI2MDdGQzFDRUM3RkY4OTEyNjAxRkYx RUVDM0ZFMDkxMjYKMDA3RkRFRUNGRjgwREIxRkZGRDkwM0ZFQzlGQzAzMDc5MDM4QzAzRkY4MDMw MTkwQjU2QzE1NjBEQjAwM0YxNDNDMDQwMUVCCkUwMUM5M0M4MTIxRUEyMURFMDE5MUZBMzczNkMx MzAxMURDMDc0MTMwM0EyNzQxMzA3NzQxMzBGNzM2Q0VCMUY4MDc0MTMzRgo5NzM4RkYwMUZGNzM5 MEI1MTIwMEEyNjQ4NTY0ODU3NDVCNzQ1Qjc0NUIwODA3MTM4MEUwMDFGRUM3RkM1QjgwN0FFMzY3 Pgo4MSBEPEI2MDBGQzA1N0ZCNUZDQTRDNjAyODAwNTBGMTNGMEQ5M0ZGRUNCMDAwMzEzODA0QTk1 MzgwMUZFMDAwMTFGNjI3NQo1QTEzMEY2RTYxMDEwNzYyODA2RDRGNUFBMjgxNkQ0RjVBQTI2RjE3 MDc2RDk3QzdGQzgxMDI3RjE4MEVBMjZGMTcxRTAyM0YKMTgxQzgxMUIzQzAyMUYxODM4ODEwMjBG NjBBMjZGMTdGMDAyMDc2MDgxMUEwMTZFNjA4MjZFNEQ1QUEyNzAxNTA3NkU5NUM4CkZDODIwMzdG MTYwRUEyODIwMzNGNUU4MjFBM0MwMzFGMTYzODgyMDMwRjVFQTI3MDE1RjAwMzA3NUU4MjE5MDE2 RjVFODM2Rgo0QjVBQTI3MTEzMDc2RjkzQzlGQzgzMDQ3RjE0MEVBMjgzMDQzRjVDQTI3MTEzM0Mw NDFGMTQzODgzMDQwRjVDQTI3MTEzRjAKMDQwNzVDODMxODAxNzA1QzE4ODE3MEVCODM4MEEyMThD NzcwOTFDQUZDMThFN0VGN0ZFRUEyMThGRTcxNUFBMzcxNUFBMjcxCjVBQTM3MTVBQTM3MTVBQTI2 MDY0N0ZFMTYzPjg2IEQ8RUMzRkYwOTAzODAzRkZGRTAxMEY2RDdFOTAzOTNGQzAzRkUwOTAzOQo3 RTAwMDdGODAxRjg2RDdFRDgwMUUwNkQ3RTQ4NDg2RDdFNDg0ODZFN0U0OEM4NkM3RTdGMDFGMDZF N0U0ODdFNkQ2RTdFQTMKNzA3RUEzNkM1QUVBMDNFMEM5RkNBNjE2N0ZFRDdGRkYwMjBGQjVGQzkx Mzg3RkY4MDc5MDM4MDFGRjgwOTAzODA3RkMwMEVCCjFGRjBFQjdGQzA0OTVBRDgwM0ZFQzdGQzQ4 NUExMjBGNUI0ODVBNDg1QUEyNDg0ODE3RTBBMzEyRkY1QkEyMTYwRkEzMTYxRgo2RDE0MUIwMDdG MTUzQjE2NzM2RDkxMzk3MUZDMDFDMDZDNkMxNEUxMDAxRkVDMDFDMUQ4MEZGQzkwM0EwNzgwRkUw MzgwNkMKNkM5MDNBMEYwMEZGMDcwMDI3MDFGRjgwN0U2REI0RkMyNzAwN0ZGRkY4NkQ1QTAxMUYw MUUwRUIxRkY4MDEwMTkwQzdFQTA3CkUwM0I0MTdBQkY0Mj45NyBEPEVDMDNGRTkxMzgxRkZGRTA5 MUI1MTJGODkwMzkwMUZFMDNGRTkwM0EwN0YwMDA3RjgwNDk0OAo2RDdFRDkzRkMwNkQ3RTQ5Qzc2 QzdFNDk2RTdFNDkxNDAzNDg0ODgxNDg0ODE0MDEwMDA3ODI0OTE0MDAwMDBGODI4MzQ4NUEKMTg4 MDEyM0Y0OTE1M0ZBMjAwN0YxN0MwQTM1QkEyMTJGRjkwQjhGQ0EzMDE4MENBRkNBOTEyN0Y3RkEz MTIzRkEyN0YxMjFGCkVGMDFDMDZDN0UxNzAzNkM2QzE2ODBBMjZDNkMxNTA3MDAwMUVFMEYwMDZE MTUwRTZDNkMxNTFFNkQ2QzVDNkQ2QzVDNkQ2Qwo1Q0Q5MDdGMEVCMDNFMEQ5MDNGQzQ5NUE5MDI3 MDBGRjgwM0ZDN0ZDOTEzODNGRkZGQzAyMEYxM0YwMDIwMTEzODAzMjQxN0MKQkYzQT4xMDEgRDxG MDNGODBEQTAzRkM5MDM4MDFGRkUwOTEyNzNGRkZDMDA3MTNGMDkxQjUzOUYwMUZDMUY4OTAzQjAz RkMKMDNGQzNFMDM5MDNBMDdGMDAwRkU3ODQ5NDhFQjdGRTA0OTQ4RUIzRkMwNDk0ODAxMUZFQjAx RjA0OUM3NkM2Q0M3RkMwMUZFCjZFN0VBMjQ4NDg2RTdFQTIwMDAzODJBMjQ5MTQwMTAwMDc4MkFB MDAwMzVFNkQxNDAzQTIwMDAxNUVBMjZDNkM0QTVBQTIwMQo3RjRBNUE2RDZDNDk1QTZENkM0OTVB NDk2QzQ5QzhGQ0Q5MzdGMDEzRkU5MDM5NzNGQzAzRkMwMTYwQjUxMkYwRDlFMDNGMTMKQzBEQTAz RkNDOUZDNDg0OENCRkNBNTdGQTI3RkEyN0Y2QzdFMTNGRjkxQjUxMkZFNkRFQ0ZGRjA2RDE1RkU2 RDZGN0U2RDE2CkUwODQwMTNGMTZGQzAxRkVDNzAwMDE3RkQ4MDNGOEVDMDAxRkQ4MDdFMEVEMDNG RjQ4NDgwMzAwMTM4MDQ4NDgxNjdGMDAzRgpFRjNGQzA5MENBMTIxRjEyN0VGMDBGRTAxMkZFNDgx NzA3QTY2QzE3MEYwMDdFMThDMEEyMDA3RjE3MUY2QzZDRUUzRjgwNkMKNkNFRTdGMDAwMDBGMTc3 RUQ4MDdGMDRCNUE2QzZDNEI1QTZDNkM0QjVBRDgwMDdGRUQxRkMwRDkzRkUwRUNGRjgwRDkwRkZF CkQ5MEZGRUM3RkMwMTAxQjYxMkYwRDkwMDNGMTQ4MDAyMDEwMUYwQzhGQzNENUU3REJGNDI+MTAz CkQ8RDkwM0MwRUI3RkUwRDgwN0ZGOTAzODAzRkZGQ0I1MDEwRjEzRkZEQjNGMDAxM0MwMDM3OEVC MUZFMDRCNkQ3RTAwMDFEOQpDMUMwNkQ3RTI3MDA3RkMzODA4MDAyQzdDNzEyMDNEOTNGQ0U4MTE3 MDExNERDMTREODAyRjg2RTdFNUNBMzVDQTM1Q0IzQjMKNDk2QzRBN0Y0OTZDNEE3RkI2RDhGMDAz QjYxMkMwQTQ0MjNGN0RCRTQ5PjExMCBEPDkwMzkwNzgwMDNGOEQ4MDdGRkVCMEYKRkZCNTAxM0Yx M0MwOTIzODdDMEZFMDkxMzg4MUYwMUY5MjM4RTAzRkYwMDAwMUVCODM4MDM5MDA3Rjg3MDAxNDhG RUIzRjhFCjAyOUNFQjFGRTBFRTBGQzAwMjk4RUIwMzAwMDJCODkwQzdGQ0EyMTRCMDE0RjBBMjVD QTU1Q0IzQjA0OTdFRUJGRkY4QjYxMgpGQ0E0MkMzRjdDQkUzMz4xMTQgRDxEOTAzQzAxNTBGRDgw N0ZGRUQxRkZGQjUwMjAzQjVGQ0E0MDAwMUVEMDAwN0Q4MDA3RgoxNTAxQTIwMTNGODFCM0IyNUZB MzVGQTM1RjAxMUYxNTA2NkUxNDBFNUYxMzBGNkU0QTdGMDEwNzVENkQ2QzQ5NDgxM0UwRDkKMDFG RTQ5NDhFQkZGQzA5MDNBMDBGRkMwMUY4MDkxMzkzRkZGRkUwMDAyMEYxM0Y4MDIwMDAxQzBFQzgw MDA0MjQwN0RCRTQ5Cj4xMTcgRDxCNjZDNDlCNTEyRTBBNDAwMDEwMUY4QzgzODdGRkUwMDI2MDA3 RkUwRUQxRkY4MTlFMDAxM0Y3MDVBNjExMzFGCjZFOTNDN0ZDMDEwRjE2MEVBMjZENkM1REEyNkUx NTNDMDEwMzE2MzhBMjZENkM1REEyNkUxNUYwNkQ1RUEyNkU2QzQ5NUFBMgo2RjEzMDMwMjNGNURB MjZGMTMwNzAyMUY5MkM4RkM2RjVCMDIwRjE0MEVBMjZGMTMxRTAyMDcxNDFDNkYxMzNDMDIwMzE0 MzgKQTI2RjEzNzgwMjAxMTQ3MDZGMTNGMDZFNUNBMjE2ODEwMzdGNUIxNkMzMDMzRjVCQTIxNkU3 MDMxRjkwQzlGQzE2RkY2RjVBCkEzNkY1QUEyNkY1QUEzNkY1QUEyNkY1QUEyMTUwMTVFMTUwMzVF QTIxNTA3OTNDQUZDNUQxNTBFQTIxNTFFMTUxQzE1M0NEOAoxRjgwMTMzODQ4N0U0ODZDNUJBMjVE MTQwMTVENDk0ODVBMzgzRjgwMDc0OTQ4Q0JGQzAwMUUxMzNFMzgwRkMwRkM2Q0I0NUEKMDAwMTEz RTA2QzZDQ0NGQzQzNUI3RkJENDY+MTIxIEQgRQolRW5kRFZJUFNCaXRtYXBGb250CmVuZAolJUVu ZFByb2xvZwolJUJlZ2luU2V0dXAKJSVGZWF0dXJlOiAqUmVzb2x1dGlvbiA2MDBkcGkKVGVYRGlj dCBiZWdpbgolJVBhcGVyU2l6ZTogYTQKIGVuZAolJUVuZFNldHVwCiUlUGFnZTogMSAxClRlWERp Y3QgYmVnaW4gMSAwIGJvcCBCbGFjayBCbGFjayBCbGFjayBCbGFjayAxMzE3IDg3MgphIEZpKEpW KWwoTyk0NCBiKFF1ZXJ5KWcoTGFuZ3VhZ2UpMTY1MSAxMTEyIHkgRmgoTmFva2kpMzIKYihZKS04 IGIoYXN1ZGEpMTU2MyAxMzA4IHkoRilnKGVicnVhcnkpMzMgYigyOCwpZigyMDAzKTYzOQoxNjE1 IHkgRmcoSlYpbihPKTI2IGIod2lsbCloKHBybyluKHZpZGUpZih0aGUpaChmdW5jdGlvbilnKHRv KWYKKHJldHJpZXYpbihlKWcoY2F0YWxvZylmKGRhdGEpaChhbmQpZyhpbWFnZSlnKGRhdGEpZyhm cm9tKTUxNQoxNzE1IHkobSluKHVsdGlwbGUpZChkYXRhKWUoc2VydiluKGVycylnKHZpYSlnKHNp bmdsZSloKHVzZXIpZyhpbiluCih0ZXJmYWNlLikzNCBiKEhlcmUpMjIgYih3KW4oZSlnKHdpbGwp aChkaXNjdXNzKWUodGhlKWkoZ3JhbW1hcik1MTUKMTgxNCB5KG9mKWsoSlYpbihPKWcoUXVlcnkp ZyhMYW5ndWFnZSlmKHdoaWMpbihoKWgoZGVzY3JpYilyKGVzKWcodGhlKWgKKHJlcXVlc3QpZihm b3IpZyhkYXRhKWcocmV0cmlldiktNSBiKGFsLik1MTUgMjA4OSB5IEZmKDEpMTM0CmIoRGF0YWJh c2UpNDcgYihjb25cMDE0Z3VyYXRpb24pNTE1IDIyNzEgeSBGZyhJbikzOCBiKEpWKW4oTywpZyh0 aGUpZwooZm9sbG8pbih3aW5nKWYoZGF0YWJhc2UpZyhjb25cMDE0Z3VyYXRpb24pZyhpcyloKGFz c3VtZWQuKTY4CmIoVGhlcmUpMzggYihhcmUpZihzZXYpbihlcmFsKTUxNSAyMzcwIHkocmVtb3Rl KTI5IGIoZGF0YSlnKHNlcnYpbihlcnMpCmYob2YpaShjYXRhbG9nKWYoYW5kL29yKWYoaW1hZ2Up aChkYXRhLCloKGFuZClnKEpWKW4oTylmKHdpbGwpaAoocmVxdWVzdClnKHRoZW0pNTE1IDI0NzAg eShmb3IpMTkgYihzZWFyYyluKGhpbmcpZihhbmQpaShyZXRyaWV2aW5nKWYKKGRhdGEuKTM0IGIo SlYpbihPKTE5IGIoc3lzdGVtKWgod2lsbClnKGhhKW4odiluKGUpZihpdHMpaChvKW4od24pZwoo ZGF0YWJhc2UpZShzeXN0ZW0pNTE1IDI1NzAgeSh3aGljKW4oaCkyMyBiKHdpbGwpZyhzdG9yZSln KHRoZSlnKGRhdGEpZwoocmV0cmlldiluKGVkKWYoZnJvbSloKHJlbW90ZSlmKGRhdGEpaChzZXJ2 KW4oZXJzLikzNApiKEluKTIzIGIobW9zdClnKGNhc2VzLClnKHJlYWwpNTE1IDI2NjkgeShtYXRl cmlhbGl6ZWQpZyhkYXRhKWgod2lsbClnCihiKXIoZSloKHN0b3JlZCllKGluKW4odG8paChKVilu KE8pZihvKW4od24paChkYXRhYmFzZSlmKHNpbmNlKWcodGhlc2UpCmkoZGF0YSllKHdpbGwpaShi KXIoZSk1MTUgMjc2OSB5KHNlcnYpbihlZCloKGZvciloKHRoZSloKGlucHV0KWgob2YpZQooZnVy dGhlciloKGFuYWx5c2VzKWUoZG9uZSloKGF0KWgoSlYpbihPKWUoc3lzdGVtLik2MzkKMjg2OCB5 KEluKTMzIGIodGhlKWYoZGF0YSlnKHJlZ2lzdHJ5KS03IGIoLCkzMiBiKGJhc2ljKWYoaW5mb3Jt YXRpb24paAooYWIpcihvdXQpZyhjYXRhbG9nKWUoZGF0YSlpKGFuZClnKGltYWdlKWcoZGF0YSk1 MTUgMjk2OAp5KHdoaWMpbihoKWgocmVtb3RlKWgoZGF0YSlmKHNlcnYpbihlcnMpZShob2xkKWoo YXJlKWYoc3RvcmVkOylqKGhvc3QpZAoobmFtZXMpaCh0bylmKGFjY2VzcywpaChtZXRobylyKGRz KWcodG8pNTE1IDMwNjggeShhY2Nlc3MsKTI0CmIobWV0YWRhdGEpZihvZilpKGRhdGEsKWYoYW5k KWcoc28pZyhvbi4pMzYgYihEYXRhKTI0CmIocmVnaXN0cnkpZih3aWxsKWgoYilyKGUpaChzb21l dGhpbmcpZihsaWspbihlKWcoVURESSk1MTUKMzE2NyB5KGluKWsoVyktNyBiKGViKTI4IGIoU2Vy dmljZXMuKTYzOSA0NjIxIHkgQGJlZ2luc3BlY2lhbAowIEBsbHggMCBAbGx5IDMzMSBAdXJ4IDE1 MCBAdXJ5IDMzMTAgQHJ3aSBAc2V0c3BlY2lhbAolJUJlZ2luRG9jdW1lbnQ6IGZpZzEucHN0ZXgK JSFQUy1BZG9iZS0yLjAgRVBTRi0yLjAKJSVUaXRsZTogL2Rldi9mcy9DL3dvcmsvSlZPL2ZpZzEu ZmlnCiUlQ3JlYXRvcjogZmlnMmRldiBWZXJzaW9uIDMuMiBQYXRjaGxldmVsIDQKJSVDcmVhdGlv bkRhdGU6IEZyaSBGZWIgMjggMTI6MTg6MDUgMjAwMwolJUZvcjogbnlhc3VkYUB0cC10MzAgKCkK JSVCb3VuZGluZ0JveDogMCAwIDMzMSAxNTAKJSVNYWduaWZpY2F0aW9uOiAwLjUwMDAKJSVFbmRD b21tZW50cwovJEYycHNEaWN0IDIwMCBkaWN0IGRlZgokRjJwc0RpY3QgYmVnaW4KJEYycHNEaWN0 IC9tdHJ4IG1hdHJpeCBwdXQKL2NvbC0xIHswIHNldGdyYXl9IGJpbmQgZGVmCi9jb2wwIHswLjAw MCAwLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMSB7MC4wMDAgMC4wMDAgMS4wMDAgc3Jn Yn0gYmluZCBkZWYKL2NvbDIgezAuMDAwIDEuMDAwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wz IHswLjAwMCAxLjAwMCAxLjAwMCBzcmdifSBiaW5kIGRlZgovY29sNCB7MS4wMDAgMC4wMDAgMC4w MDAgc3JnYn0gYmluZCBkZWYKL2NvbDUgezEuMDAwIDAuMDAwIDEuMDAwIHNyZ2J9IGJpbmQgZGVm Ci9jb2w2IHsxLjAwMCAxLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sNyB7MS4wMDAgMS4w MDAgMS4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDggezAuMDAwIDAuMDAwIDAuNTYwIHNyZ2J9IGJp bmQgZGVmCi9jb2w5IHswLjAwMCAwLjAwMCAwLjY5MCBzcmdifSBiaW5kIGRlZgovY29sMTAgezAu MDAwIDAuMDAwIDAuODIwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxMSB7MC41MzAgMC44MTAgMS4wMDAg c3JnYn0gYmluZCBkZWYKL2NvbDEyIHswLjAwMCAwLjU2MCAwLjAwMCBzcmdifSBiaW5kIGRlZgov Y29sMTMgezAuMDAwIDAuNjkwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxNCB7MC4wMDAgMC44 MjAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDE1IHswLjAwMCAwLjU2MCAwLjU2MCBzcmdifSBi aW5kIGRlZgovY29sMTYgezAuMDAwIDAuNjkwIDAuNjkwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxNyB7 MC4wMDAgMC44MjAgMC44MjAgc3JnYn0gYmluZCBkZWYKL2NvbDE4IHswLjU2MCAwLjAwMCAwLjAw MCBzcmdifSBiaW5kIGRlZgovY29sMTkgezAuNjkwIDAuMDAwIDAuMDAwIHNyZ2J9IGJpbmQgZGVm Ci9jb2wyMCB7MC44MjAgMC4wMDAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDIxIHswLjU2MCAw LjAwMCAwLjU2MCBzcmdifSBiaW5kIGRlZgovY29sMjIgezAuNjkwIDAuMDAwIDAuNjkwIHNyZ2J9 IGJpbmQgZGVmCi9jb2wyMyB7MC44MjAgMC4wMDAgMC44MjAgc3JnYn0gYmluZCBkZWYKL2NvbDI0 IHswLjUwMCAwLjE5MCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMjUgezAuNjMwIDAuMjUwIDAu MDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyNiB7MC43NTAgMC4zODAgMC4wMDAgc3JnYn0gYmluZCBk ZWYKL2NvbDI3IHsxLjAwMCAwLjUwMCAwLjUwMCBzcmdifSBiaW5kIGRlZgovY29sMjggezEuMDAw IDAuNjMwIDAuNjMwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyOSB7MS4wMDAgMC43NTAgMC43NTAgc3Jn Yn0gYmluZCBkZWYKL2NvbDMwIHsxLjAwMCAwLjg4MCAwLjg4MCBzcmdifSBiaW5kIGRlZgovY29s MzEgezEuMDAwIDAuODQwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCgplbmQKc2F2ZQpuZXdwYXRoIDAg MTUwIG1vdmV0byAwIDAgbGluZXRvIDMzMSAwIGxpbmV0byAzMzEgMTUwIGxpbmV0byBjbG9zZXBh dGggY2xpcCBuZXdwYXRoCi04LjMgMTczLjYgdHJhbnNsYXRlCjEgLTEgc2NhbGUKCi9jcCB7Y2xv c2VwYXRofSBiaW5kIGRlZgovZWYge2VvZmlsbH0gYmluZCBkZWYKL2dyIHtncmVzdG9yZX0gYmlu ZCBkZWYKL2dzIHtnc2F2ZX0gYmluZCBkZWYKL3NhIHtzYXZlfSBiaW5kIGRlZgovcnMge3Jlc3Rv cmV9IGJpbmQgZGVmCi9sIHtsaW5ldG99IGJpbmQgZGVmCi9tIHttb3ZldG99IGJpbmQgZGVmCi9y bSB7cm1vdmV0b30gYmluZCBkZWYKL24ge25ld3BhdGh9IGJpbmQgZGVmCi9zIHtzdHJva2V9IGJp bmQgZGVmCi9zaCB7c2hvd30gYmluZCBkZWYKL3NsYyB7c2V0bGluZWNhcH0gYmluZCBkZWYKL3Ns aiB7c2V0bGluZWpvaW59IGJpbmQgZGVmCi9zbHcge3NldGxpbmV3aWR0aH0gYmluZCBkZWYKL3Ny Z2Ige3NldHJnYmNvbG9yfSBiaW5kIGRlZgovcm90IHtyb3RhdGV9IGJpbmQgZGVmCi9zYyB7c2Nh bGV9IGJpbmQgZGVmCi9zZCB7c2V0ZGFzaH0gYmluZCBkZWYKL2ZmIHtmaW5kZm9udH0gYmluZCBk ZWYKL3NmIHtzZXRmb250fSBiaW5kIGRlZgovc2NmIHtzY2FsZWZvbnR9IGJpbmQgZGVmCi9zdyB7 c3RyaW5nd2lkdGh9IGJpbmQgZGVmCi90ciB7dHJhbnNsYXRlfSBiaW5kIGRlZgovdG50IHtkdXAg ZHVwIGN1cnJlbnRyZ2Jjb2xvcgogIDQgLTIgcm9sbCBkdXAgMSBleGNoIHN1YiAzIC0xIHJvbGwg bXVsIGFkZAogIDQgLTIgcm9sbCBkdXAgMSBleGNoIHN1YiAzIC0xIHJvbGwgbXVsIGFkZAogIDQg LTIgcm9sbCBkdXAgMSBleGNoIHN1YiAzIC0xIHJvbGwgbXVsIGFkZCBzcmdifQogIGJpbmQgZGVm Ci9zaGQge2R1cCBkdXAgY3VycmVudHJnYmNvbG9yIDQgLTIgcm9sbCBtdWwgNCAtMiByb2xsIG11 bAogIDQgLTIgcm9sbCBtdWwgc3JnYn0gYmluZCBkZWYKIC9EcmF3RWxsaXBzZSB7CgkvZW5kYW5n bGUgZXhjaCBkZWYKCS9zdGFydGFuZ2xlIGV4Y2ggZGVmCgkveXJhZCBleGNoIGRlZgoJL3hyYWQg ZXhjaCBkZWYKCS95IGV4Y2ggZGVmCgkveCBleGNoIGRlZgoJL3NhdmVtYXRyaXggbXRyeCBjdXJy ZW50bWF0cml4IGRlZgoJeCB5IHRyIHhyYWQgeXJhZCBzYyAwIDAgMSBzdGFydGFuZ2xlIGVuZGFu Z2xlIGFyYwoJY2xvc2VwYXRoCglzYXZlbWF0cml4IHNldG1hdHJpeAoJfSBkZWYKCi8kRjJwc0Jl Z2luIHskRjJwc0RpY3QgYmVnaW4gLyRGMnBzRW50ZXJlZFN0YXRlIHNhdmUgZGVmfSBkZWYKLyRG MnBzRW5kIHskRjJwc0VudGVyZWRTdGF0ZSByZXN0b3JlIGVuZH0gZGVmCgokRjJwc0JlZ2luCjEw IHNldG1pdGVybGltaXQKMCBzbGogMCBzbGMKIDAuMDMwMDAgMC4wMzAwMCBzYwolCiUgRmlnIG9i amVjdHMgZm9sbG93CiUKJSAKJSBoZXJlIHN0YXJ0cyBmaWd1cmUgd2l0aCBkZXB0aCA1MAovSGVs dmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKODg1MCAzMjU1IG0KZ3MgMSAtMSBzYyAoYW5kIGRhdGEg cmV0cmlldmFsKSBjb2wwIHNoIGdyCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgo4MzI1IDE3 MjUgbQpncyAxIC0xIHNjIChEYXRhKSBjb2wwIHNoIGdyCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNj ZiBzZgo4MTc1IDIwMjUgbQpncyAxIC0xIHNjIChSZWdpc3RyeSkgY29sMCBzaCBncgolIFBvbHls aW5lCjE1LjAwMCBzbHcKbiAzMDAgOTc1IG0gMTUwMCA5NzUgbCAxNTAwIDE1NzUgbCAzMDAgMTU3 NSBsCiBjcCBncyBjb2wwIHMgZ3IgCi9IZWx2ZXRpY2EgZmYgMzYwLjAwIHNjZiBzZgo0NTAgMTQy NSBtCmdzIDEgLTEgc2MgKFVzZXJzKSBjb2wwIHNoIGdyCiUgUG9seWxpbmUKbiAzNjc1IDIzMjUg bSA2Mzc1IDIzMjUgbCA2Mzc1IDI3NzUgbCAzNjc1IDI3NzUgbAogY3AgZ3MgY29sMCBzIGdyIAov SGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKNDA1MCAyNjI1IG0KZ3MgMSAtMSBzYyAoUXVlcnkg RXhlY3V0b3IpIGNvbDAgc2ggZ3IKJSBFbGxpcHNlCm4gMjEwMCAyNTUwIDEwNTAgNjAwIDAgMzYw IERyYXdFbGxpcHNlIGdzIGNvbDAgcyBncgoKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNmCjEz NTAgMjYyNSBtCmdzIDEgLTEgc2MgKFN5c3RlbSBEQikgY29sMCBzaCBncgolIFBvbHlsaW5lCm4g MzY3NSAxMTI1IG0gNjM3NSAxMTI1IGwgNjM3NSAxNTc1IGwgMzY3NSAxNTc1IGwKIGNwIGdzIGNv bDAgcyBnciAKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNmCjQyMDAgMTQyNSBtCmdzIDEgLTEg c2MgKFF1ZXJ5IFBhcnNlcikgY29sMCBzaCBncgolIEVsbGlwc2UKbiAzMzAwIDQ4NzUgMTUwMCA5 MDAgMCAzNjAgRHJhd0VsbGlwc2UgZ3MgY29sMCBzIGdyCgovSGVsdmV0aWNhIGZmIDM2MC4wMCBz Y2Ygc2YKMjMyNSA0OTUwIG0KZ3MgMSAtMSBzYyAoRGF0YSBTZXJ2ZXIpIGNvbDAgc2ggZ3IKJSBF bGxpcHNlCm4gNzM1MCA0ODc1IDE1MDAgOTAwIDAgMzYwIERyYXdFbGxpcHNlIGdzIGNvbDAgcyBn cgoKL0hlbHZldGljYSBmZiAzNjAuMDAgc2NmIHNmCjYzNzUgNDk1MCBtCmdzIDEgLTEgc2MgKERh dGEgU2VydmVyKSBjb2wwIHNoIGdyCiUgUG9seWxpbmUKIFs5MF0gMCBzZApuIDk3NSAxNzI1IG0g MzM3NSAxNzI1IGwgMzM3NSA4MjUgbCA2Njc1IDgyNSBsIDY2NzUgMzM3NSBsIDgyNSAzMzc1IGwK IDgyNSAxNzI1IGwKIDk3NSAxNzI1IGwgIGNwIGdzIGNvbDAgcyBnciAgW10gMCBzZAolIFBvbHls aW5lCmdzICBjbGlwcGF0aAozMzkwIDEyNjAgbSAzMzkwIDExNDAgbCAzMTAzIDExNDAgbCAzMzQz IDEyMDAgbCAzMTAzIDEyNjAgbCBjcAplb2NsaXAKbiAxNTAwIDEyMDAgbQogMzM3NSAxMjAwIGwg Z3MgY29sMCBzIGdyIGdyCgolIGFycm93aGVhZApuIDMxMDMgMTI2MCBtIDMzNDMgMTIwMCBsIDMx MDMgMTE0MCBsIDMxMDMgMTI2MCBsICBjcCBncyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNvbDAgcwol IFBvbHlsaW5lCmdzICBjbGlwcGF0aAoxNDg1IDEyOTAgbSAxNDg1IDE0MTAgbCAxNzcyIDE0MTAg bCAxNTMyIDEzNTAgbCAxNzcyIDEyOTAgbCBjcAplb2NsaXAKbiAzMzc1IDEzNTAgbQogMTUwMCAx MzUwIGwgZ3MgY29sMCBzIGdyIGdyCgolIGFycm93aGVhZApuIDE3NzIgMTI5MCBtIDE1MzIgMTM1 MCBsIDE3NzIgMTQxMCBsIDE3NzIgMTI5MCBsICBjcCBncyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNv bDAgcwolIFBvbHlsaW5lCmdzICBjbGlwcGF0aAozNjYxIDE0MTAgbSAzNzE1IDEzMDMgbCAzNDU3 IDExNzQgbCAzNjQ1IDEzMzUgbCAzNDAzIDEyODEgbCBjcAplb2NsaXAKbiAzMzc1IDEyMDAgbQog MzY3NSAxMzUwIGwgZ3MgY29sMCBzIGdyIGdyCgolIGFycm93aGVhZApuIDM0MDMgMTI4MSBtIDM2 NDUgMTMzNSBsIDM0NTcgMTE3NCBsICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKNDgx NSAyMzQwIG0gNDkzNSAyMzQwIGwgNDkzNSAyMDUzIGwgNDg3NSAyMjkzIGwgNDgxNSAyMDUzIGwg Y3AKZW9jbGlwCm4gNDg3NSAxNTc1IG0KIDQ4NzUgMjMyNSBsIGdzIGNvbDAgcyBnciBncgoKJSBh cnJvd2hlYWQKbiA0ODE1IDIwNTMgbSA0ODc1IDIyOTMgbCA0OTM1IDIwNTMgbCA0ODE1IDIwNTMg bCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBh dGgKNzQyNyAxNTYxIG0gNzQ1MiAxNDQ0IGwgNzE3MCAxMzg0IGwgNzM5MyAxNDkzIGwgNzE0NSAx NTAxIGwgY3AKZW9jbGlwCm4gNjM3NSAxMjc1IG0KIDc0MjUgMTUwMCBsIGdzIGNvbDAgcyBnciBn cgoKJSBhcnJvd2hlYWQKbiA3MTQ1IDE1MDEgbSA3MzkzIDE0OTMgbCA3MTcwIDEzODQgbCA3MTQ1 IDE1MDEgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQpncyAg Y2xpcHBhdGgKNjM3MyAxMzYzIG0gNjM0NiAxNDgwIGwgNjYyNyAxNTQ0IGwgNjQwNyAxNDMyIGwg NjY1NCAxNDI3IGwgY3AKZW9jbGlwCm4gNzM1MCAxNjUwIG0KIDYzNzUgMTQyNSBsIGdzIGNvbDAg cyBnciBncgoKJSBhcnJvd2hlYWQKbiA2NjU0IDE0MjcgbSA2NDA3IDE0MzIgbCA2NjI3IDE1NDQg bCA2NjU0IDE0MjcgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGlu ZQpncyAgY2xpcHBhdGgKMjk4NSAyNDkwIG0gMjk4NSAyNjEwIGwgMzI3MiAyNjEwIGwgMzAzMiAy NTUwIGwgMzI3MiAyNDkwIGwgY3AKZW9jbGlwCm4gMzY3NSAyNTUwIG0KIDMwMDAgMjU1MCBsIGdz IGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiAzMjcyIDI0OTAgbSAzMDMyIDI1NTAgbCAzMjcy IDI2MTAgbCAzMjcyIDI0OTAgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQ b2x5bGluZQpncyAgY2xpcHBhdGgKMzM5MSAzOTU1IG0gMzQ5MiA0MDE5IGwgMzY0NSAzNzc2IGwg MzQ2NyAzOTQ4IGwgMzU0MyAzNzEyIGwgY3AKZW9jbGlwCm4gNDIwMCAyNzc1IG0KIDM0NTAgMzk3 NSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiAzNTQzIDM3MTIgbSAzNDY3IDM5NDgg bCAzNjQ1IDM3NzYgbCAzNTQzIDM3MTIgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2ww IHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKNDQ4MyAyNzk0IG0gNDM4MiAyNzMwIGwgNDIyOSAy OTczIGwgNDQwOCAyODAyIGwgNDMzMSAzMDM3IGwgY3AKZW9jbGlwCm4gMzY3NSAzOTc1IG0KIDQ0 MjUgMjc3NSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiA0MzMxIDMwMzcgbSA0NDA4 IDI4MDIgbCA0MjI5IDI5NzMgbCA0MzMxIDMwMzcgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdy ICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKNTk3MSAyNzMzIG0gNTg2NCAyNzg5IGwg NTk5OSAzMDQ0IGwgNTk0MCAyODA0IGwgNjEwNSAyOTg4IGwgY3AKZW9jbGlwCm4gNjYwMCA0MDUw IG0KIDU5MjUgMjc3NSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiA2MTA1IDI5ODgg bSA1OTQwIDI4MDQgbCA1OTk5IDMwNDQgbCA2MTA1IDI5ODggbCAgY3AgZ3MgMC4wMCBzZXRncmF5 IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKNjQwNCA0MTY3IG0gNjUwOSA0 MTA4IGwgNjM2OSAzODU4IGwgNjQzNCA0MDk3IGwgNjI2NCAzOTE2IGwgY3AKZW9jbGlwCm4gNTcw MCAyNzc1IG0KIDY0NTAgNDEyNSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiA2MjY0 IDM5MTYgbSA2NDM0IDQwOTcgbCA2MzY5IDM4NTggbCA2MjY0IDM5MTYgbCAgY3AgZ3MgMC4wMCBz ZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQo3LjUwMCBzbHcKbiAzOTc1IDMzNzUgbQog ODcwMCAyODUwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gNjE1MCAzMzc1IG0KIDg3MDAg Mjg1MCBsIGdzIGNvbDAgcyBnciAKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNmCjE4NzUgMTA1 MCBtCmdzIDEgLTEgc2MgKEpWTyBRTCkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBz Y2Ygc2YKODg1MCAyOTI1IG0KZ3MgMSAtMSBzYyAoUmVxdWVzdCBmb3Igc2VhcmNoKSBjb2wwIHNo IGdyCiUgRWxsaXBzZQoxNS4wMDAgc2x3Cm4gODYyNSAxODAwIDEyNzUgNzUwIDAgMzYwIERyYXdF bGxpcHNlIGdzIGNvbDAgcyBncgoKJSBoZXJlIGVuZHMgZmlndXJlOwokRjJwc0VuZApycwpzaG93 cGFnZQoKJSVFbmREb2N1bWVudAogQGVuZHNwZWNpYWwgQmxhY2sgMTkyNiA1MjU1IGEoMSlwIEJs YWNrIGVvcCBlbmQKJSVQYWdlOiAyIDIKVGVYRGljdCBiZWdpbiAyIDEgYm9wIEJsYWNrIEJsYWNr IDUxNSA1MjMgYSBGZigyKTEzNApiKFNwKXQoZWNpXDAxNGNhdGlvbik0NSBiKG9mKWgoSlYpbChP KWYoUXVlcnkpZyhMYW5ndWFnZSk1MTUKNzA1IHkgRmcoVyktNyBiKGUpMzUgYihkZXNpZ25lZCln KEpWKW4oT1FMKWcoYXMpZihhbiloKGV4dGVuc2lvbilnKG9mKWgKKFNRTClmKHNpbmNlKWcoU1FM KWcoaGFzKWcoc2ltcGxlKWcoYW5kKWcodyluKGVsbCk1MTUKODA1IHkoZGVcMDE0bmVkKTI4IGIo Z3JhbW1hcilkKGFuZClqKG1hbiluKHkpZihwKXIoZW9wbGUpZyhhcmUpZwooYWNjdXN0b21lZCln KHdpdGgpaChTUUwuKTYzOSA5MDQgeShJbikzNCBiKHRoZSlmKGZvbGxvKW4od2luZywpaApGZShj YXRhbG9nKWQgRmcobWVhbnMpaChjYXRhbG9nKWcoZGF0YSloKGluKWcodGFidWxhcilnKGZvcm1h dClnKGFuZClnCkZlKGRhdGEpNTE1IDEwMDQgeSBGZyhtZWFucykyNyBiKGltYWdlKWcoZGF0YS4p NjM5IDExMDMKeShKViluKE8pMzYgYihzcClyKGVjaVwwMTRjKWcob3ApcihlcmFuZHMpZyh3aGlj KW4oaClnKGFyZSlnKGV4dGVuc2lvbikKZyh0bylnKFNRTClnKGFyZSlmKHdyaXR0ZW4paShpbiln KGNhcGl0YWwpNTE1IDEyMDMgeShsZXR0ZXJzLik2MzkKMTMwMyB5KFF1ZXJpZXMpMjcgYihpbilo KEpWKW4oTyllKGNhbilpKGIpcihlKWcoY2F0ZWdvcml6ZWQpZChpbiluKHRvKWoKKHRoZSlnKGZv bGxvKW4od2luZyllKDMpaShjYXRlZ29yeSktNyBiKC4pNjkxIDEzOTcgeShcKGFcKSkxMDIKYihR dWVyaWVzKTI3IGIod2hpYyluKGgpZyhkZWFsKWgod2l0aClnKG9ubHkpZihjYXRhbG9ncy4pNjg5 CjE0OTYgeShcKGJcKSkxMDAgYihRdWVyaWVzKTM4IGIod2hpYyluKGgpaChkZWFsKWcod2l0aClo KGNhdGFsb2dzKWQKKGFuZClpKGltYWdlcy4pNzAgYihCdXQpNDAgYihpbWFnZXMpZShhcmUpODk5 IDE1OTYgeShwKXIob2luKW4odGVkKTI4CmIoYiluKHkpZyh0aGUpZihjb2x1bW5zKWgoaW4pZyhj YXRhbG9ncy4pNjk0IDE2OTYgeShcKGNcKSkxMDQKYihRdWVyaWVzKTI3IGIod2hpYyluKGgpZyhk ZWFsKWgod2l0aClnKGltYWdlcyllKHdpdGhvdXQpaShjYXRhbG9nLik1MTUKMTg5NiB5IEZkKFww MTUpZiBGZyhJbiloKHRoZSlnKGNhc2UpZihvZilnKFwoYVwpKWgoYW5kKWcoXChiXCkpcApCbGFj ayBCbGFjayA1MTUgMjA3OCBhIEZlKGNyZWF0ZSk0MSBiKFttYXRlcmlhbGl6ZWRdKWQodmlldylr KG15dGFibGUpZQooYXMpNTE1IDIxNzggeShzZWxlY3QpaChjMS5jb2x1bW4xLCk4MjAgMjI3OCB5 KGMxLmNvbHVtbjIsKTgyMAoyMzc3IHkoYzIuY29sdW1uMSwpODIwIDI0NzcgeShjMi5jb2x1bW4y LCk4MjAgMjU3NyB5KC4uLiwpODIwCjI2NzYgeShkMS5CT1hcKFBPSU5UXChjMS4pbyhyYSlvKCwp ZChjMS5kZWNcKSwpaSh3aWR0aDEsKWgoaGVpZ2h0MVwpKWYKKGFzKWooQmx1ZUltYWdlLCk4MjAg Mjc3NiB5KC4uLiwpODIwIDI4NzUgeShjMS5jb2x1bW4zKWMoLylrCihjMi5jb2x1bW41KWQoYXMp aihmbHV4X3JhdGlvLCk4MjAgMjk3NSB5KGMzLiosKTgyMCAzMDc1CnkoLi4uKTUxNSAzMTc0IHko ZnJvbSkxMjkgYihjYXRhbG9nMSk0MCBiKGMxLCk4MjAgMzI3NAp5KGNhdGFsb2cyKWcoYzIsKTgy MCAzMzc0IHkoY2F0YWxvZzMpZyhjMywpODIwIDM0NzMgeSguLi4sKTgyMAozNTczIHkoZGF0YSlp KGQxLCk4MjAgMzY3MiB5KC4uLik1MTUgMzc3MiB5KHdoZXJlKTg1CmIoWE1BVENIXChjMSwpMzkg YihjMiwpayghYzMsKWYoLi4uXCkpZig8KWooMylmKGFyY3NlYyk4MjAKMzg3MiB5KGFuZCk4MjAg Mzk3MSB5KFwoYzEuY29sdW1uMSljKC0payhjMi5jb2x1bW4xXCkpYyg8KWsoNi4wKWcobWFnKQo4 MjAgNDA3MSB5KGFuZCk4MjAgNDE3MSB5KEJPWFwoUE9JTlRcKHJhMCwpMzggYihkZWMwXCksKWoo d2lkdGgwLClmCihoZWlnaHQwXCkpODIwIDQyNzAgeSguLi4pNTE1IDQ1NTIgeSBGYyhjcmVhdGUp MzIgYiBGaChjbGF1c2UpNjM5CjQ2NTIgeSBGZShteXRhYmxlKWYgRmcoc3ApcihlY2lcMDE0ZXMp aih0aGUpZyhuYW1lKWcob2YpZyhuZXcpZyh0YWJsZSlnCihjcmVhdGVkKWYoaW4paCh0aGUpZyhp biluKHRlcm5hbClmKGRhdGFiYXNlLik1MTUgNDc1Mgp5KENvbHVtbikyOCBiKG5hbWVzKWYoaW4p aCBGZShteXRhYmxlKWQgRmcod2lsbClqKGIpcihlKWcoZGV0ZXJtaW5lZClnCihhY2NvcmRpbmcp ZSh0bylpKHRoZSlnKHNwKXIoZWNpXDAxNGNhdGlvbilnKGluKTUxNSA0ODUxCnkgRmUoc2VsZWN0 KTIxIGIgRmcoY2xhdXNlLikzNSBiKE1ldGFkYXRhKTIzIGIoc3VjKW4oaClnKGFzKWcoZGF0YSln KHQpCm4oeXApcihlKWgod2lsbClnKGIpcihlKWcoaW5oZXJpdGVkKWcoZnJvbSlnKHRoZSlnKG1l dGFkYXRhKTUxNQo0OTUxIHkob2YpaihvcmlnaW5hbClmKGNhdGFsb2dzLilwIEJsYWNrIDE5MjYg NTI1NSBhKDIpcApCbGFjayBlb3AgZW5kCiUlUGFnZTogMyAzClRlWERpY3QgYmVnaW4gMyAyIGJv cCBCbGFjayBCbGFjayA2MzkgNTIzIGEgRmcoVyktNyBiKGUpMjQKYihhcmUpZihhc3N1bWluZyln KHRoYXQpaChhbGwpZihjYXRhbG9ncylmKGIpcihvdGgpaShvbilmKGV4dGVybmFsKWcKKGRhdGEp ZyhzZXJ2KW4oZXIpZihhbmQpaChvbiloKGluKW4odGVyLSk1MTUgNjIzIHkobmFsKTMxCmIoZGF0 YWJhc2UpZihhcmUpaChhY2NvbXBhbmllZClmKHdpdGgpaShtZXRhZGF0YSlmKHN1YyluKGgpZyhh cylnCihuYW1lcylnKG9mKWcoY29sdW1ucywpaShkYXRhKTUxNSA3MjIgeSh0KW4oeXApcihlcywp MzkKYihVQ0RzLCloKGFuZClkKHVuaXRzLik2NSBiKENhdGFsb2dzKTM1IGIoaW4paShKViluKE8p ZihjYW4paChiKXIoZSlnCihjb25zaWRlcmVkKWYoYXMpZyhtYXBwaW5nKWgob2YpNTE1IDgyMiB5 KFYpbihPVCktNyBiKGFibGUpMjcKYihpbiluKHRvKWcocmVsYXRpb25hbClmKGRhdGFiYXNlLik2 MzkgOTIyIHkoV2hlbikzNApiIEZlKG1hdGVyaWFsaXplZCkyOSBiIEZnKGlzKTM0IGIoc3Apcihl Y2lcMDE0ZWQsKWgocXVlcmllcyllKHRvKWcKKGRhdGEpaChzZXJ2KW4oZXJzKWQoYXJlKWkoYWN0 dWFsbHkpZyhleGUtKTUxNSAxMDIxIHkoY3V0ZWQpMjgKYihhbmQpZih0aGUpaChyZXN1bHRzKWYo d2lsbCloKGIpcihlKWcoc3RvcmVkKWYoaW4paCh0aGUpZyhpbiluKHRlcm5hbCkKZihkYXRhYmFz ZS4pNTE1IDEyMjAgeSBGYyhzZWxlY3QpayBGaChjbGF1c2UpcCBCbGFjawpCbGFjayA1MTUgMTQw MyBhIEZlKGNvbHVtbik0MSBiKDopaShbY2F0YWxvZy5dVUNEKTM4CmIoW2FzKTQzIGIobmFtZV0p ZSh8KTkwNyAxNTAzIHkoW2NhdGFsb2cuXWNvbHVtbilvKF9uYSlvKG1lKWMoW2FzKTQyCmIobmFt ZV0pNjM5IDE2ODUgeShjb2x1bW4pMjUgYiBGZyhzcClyKGVjaVwwMTRlcylqKHRoZSlnKGNvbHVt bilnKG9mKWYKKGNhdGFsb2dzKWYob24paChkYXRhKWcoc2VydiluKGVyLik2MzkgMTc4NSB5KElm KWsoYSllKHVzZXIpaChrbm8pbih3cykKZSh0aGUpaihjYXRhbG9nKWQoc3ApcihlY2lcMDE0Yylp KGNvbHVtbilnKG5hbWVzLClnKHVzZXIpZyhjYW4pZih1c2UpaAoodGhhdClnKG5hbWUpNTE1IDE4 ODUgeShcKClwIEZlKGNvbHVtbilwIDgxNiAxODg1IDI3CjQgdiAyOSB3KG5hbWUpcCBGZyhcKSlk KHRvKWgoaXNzdWUpZyhxdWVyaWVzLikzOCBiKElmKTI5CmIobm90LClmKHVzZXIpZyhjYW4pZyh1 c2UpZyhVQ0RzLikzOSBiKEYpLTcgYihvcikyOCBiKGV4YW1wbGUsKWcobWFnLSkKNTE1IDE5ODQg eShuaXR1ZGUpZyhpbilnIEZiKEIpayBGZyhiYW5kKTI3IGIoaXMpaCBGZShQSE9UKXAKMTQzNyAx OTg0IFYgMjkgdyhNQUcpcCAxNTk4IDE5ODQgViAzMSB3KEIpcCBGZyguKTYzOQoyMDg0IHkoV2hl bikzOSBiIEZlKGFzKWoobmFtZSkzNiBiIEZnKGlzKWkoc3ApcihlY2lcMDE0ZWQsKWoodGhhdClk Cihjb2x1bW4pZih3aWxsKWgoYilyKGUpaChzdG9yZWQpZChpbilqIEZlKG15dGFibGUpMzQKYiBG Zyh1c2luZyk1MTUgMjE4MyB5IEZlKG5hbWUpMjEgYiBGZyhhcylpKGEpZihjb2x1bW4paChuYW1l LikzNQpiKElmKTI0IGIobm90KWYoc3ApcihlY2lcMDE0ZWQsKWgoY29sdW1uKWYobmFtZSlnKHdp bGwpZyhiKXIoZSlnKHRoZSloCihvcmlnaW5hbClkKG5hbWUpNTE1IDIyODMgeShcKClwIEZlKGNh dGFsb2cxLmNvbHVtbjEpbwpGZyhcKSloKHN1YyluKGgpMjggYihhcylmIEZlKFRXT01BU1MucmEp cCBGZyguKXAgQmxhY2sKQmxhY2sgNTE1IDI0NjYgYSBGZShkYXRhKTQyIGIoOiloKFtkYXRhLl1B UkVBXCguLi5cKSkzNwpiKFthcyk0MiBiKG5hbWVdKTYzOSAyNjQ4IHkoZGF0YSkyOSBiIEZnKHNw KXIoZWNpXDAxNGVzKWgodGhlKWgoYXJlYSllCihmb3IpaCh0aGUpZyhpbWFnZSlnKGRhdGEpZyh3 aGljKW4oaClnKHdpbGwpaChiKXIoZSlmKGN1dCloKG91dClnKGZyb20pCmYoZGF0YSk1MTUgMjc0 OCB5KHNlcnYpbihlcnMuKTYyIGIoRWFjKW4oaCkzNiBiKGltYWdlKWcoZGF0YSlnKGNvcnJlc3Ap CnIob25kcylmKHRvKWgoZWFjKW4oaClnKHJlY29yZClnKGluKWgoYSlmKGNhdGFsb2cuKTYzCmIo RGV0YWlsZWQpNTE1IDI4NDggeShmb3JtYXQpMjMgYihvZiloIEZlKEFSRUEpZSBGZyh3aWxsKWko YilyKGUpZyhnaXYpCm4oZW4pZihsYXRlciwpaChidXQpaChpbilmKGdlbmVyYWwpZShjYXNlKWgo YXJlYSlmKHdpbGwpaShiKXIoZSloCihyZWN0YW5nbGUpZChhbmQpNTE1IDI5NDcgeShleHByZXNz ZWQpayhhcyk2MzkgMzA0NyB5CkZlKEJPWFwoUE9JTlRcKGMxLnJhLCkzNyBiKGMxLmRlY1wpLClr KHdpZHRoMSwpZihoZWlnaHQxXCkpcApGZyguKTUxNSAzMTQ3IHkoVGhpcykzMCBiKG1lYW5zKWco Y3V0dGluZyloKG91dClmKHJlY3Rhbmd1bGFyKWYoYXJlYSlnCihvZiloKHdpZHRoKWggRmUod2lk dGgxKWQgRmcoYW5kKWooaGVpZ2gpbih0KWYgRmUoaGVpZ2h0MSk1MTUKMzI0NiB5IEZnKHdob3Nl KWYoY2VuKW4odGVyKWcocClyKG9zaXRpb24paChpcylnKGRldGVybWluZWQpZyhmcm9tKWcKKHRo ZSlnKHYpLTUgYihhbHVlcykyOSBiKG9mKWgoY29sdW1uKWcgRmUocmEpZiBGZyhhbmQpaChjb2x1 bW4pNTE1CjMzNDYgeSBGZShkZWMpYyBGZyhvZilpKGNhdGFsb2cpZSBGZShjMSlwIEZnKC4pNjM5 IDM0NDUKeShPbikzMiBiKHJlYWwpZSh0YWJsZXMpaChvZiloKGRhdGFiYXNlKWUoc3lzdGVtLClq KHRoZSlmKHYpLTUKYihhbHVlcykzMSBiKG9mKWcoY29sdW1ucyloKGNvcnJlc3ApcihvbmRpbmcp ZCh0byk1MTUKMzU0NSB5KHRoZSlqKGltYWdlKWcoZGF0YSlmKHdpbGwpaShiKXIoZSlmKGEpZyhs aW5rKWcodG8pZyh0aGUpaChkYXRhLikKNTAgYihUaGlzKTMyIGIobGluaylnKGNhbilnKGIpcihl KWgoXDAxNGxlKWYobmFtZXMpZyhvbilnKHRoZSk1MTUKMzY0NSB5KGxvKXIoY2FsKWMoXDAxNGxl KWgoc3lzdGVtLClnKFVSTClnKHRvKWcodGhlKWcocmVtb3RlKWcoZGF0YSlmCihzZXJ2KW4oZXJz LClmKG9yKWgodGhlKWgoaW1hZ2UpZyhjdXRvdXQpZyhyZXF1ZXN0KTUxNQozNzQ0IHkodG8pZSh0 aGUpaChyZW1vdGUpZihkYXRhKWcoc2VydiluKGVycy4pNjM5IDM4NDQKeShBbGwpZyhjb2x1bW5z KWYoaW4paChhKWYoY2F0YWxvZylmKGNhbiloKGIpcihlKWgoc3ApcihlY2lcMDE0ZWQpZyhhcykK ZSBGZShjMy4qKXAgRmcoLikzNSBiKEluKTI3IGIodGhpcylnKGNhc2UsKWYoSlYpbihPKWYoc3lz dGVtKTUxNQozOTQ0IHkod2lsbClqKGdldClmKG1ldGFkYXRhKWcoZnJvbSlnKGRhdGEpZyhzZXJ2 KW4oZXIpZihhbmQpaChleHBhbmQpaAoodG8pZihlYWMpbihoKWcoY29sdW1uKWgobmFtZXMuKTYz OSA0MDQzIHkoQXJpdGhtZXRpY3MpZyhhbW9uZylmCihjb2x1bW5zKWcoY2FuKWcoYilyKGUpaChz cClyKGVjaVwwMTRlZC4pNTE1IDQyNDIgeSBGYyhmcm9tKWsKRmgoY2xhdXNlKXAgQmxhY2sgQmxh Y2sgNTE1IDQ0MjUgYSBGZShjYXRhbG9nKTQwIGIoOilrKEtFWVdPUkQxKWMoJilqCihLRVlXT1JE MilkKC4uLikxMjk5IDQ1MjUgeShbc2VsZWN0KWgoW2J5KWgoW01BWHxNSU5dXChQUk9QRVJUKW8o WVwpKTM3CmIofCk0MyBiKEFMTF1dKWYoW25hbWVdKWYofCk5NTEgNDYyNCB5KFtzZXJ2ZXIuXWNh dGFsbylvKGdfbilvKGFtKW8oZSkKMTI5OSA0NzI0IHkoW3NlbGVjdClnKFtieSloKFtNQVh8TUlO XVwoUFJPUEVSVClvKFlcKSkzNwpiKHwpNDMgYihBTExdXSlmKFtuYW1lXSk2MzkgNDkwNyB5KGNh dGFsb2cpMjAgYiBGZyhzcClyKGVjaVwwMTRlcylqCih0aGUpaChuYW1lKWYob2YpZihjYXRhbG9n cylnKHN0b3JlZClnKGluKWgodGhlKWcocmVtb3RlKWcoZGF0YSlmKHNlcnYpCm4oZXJzKWYoYW5k KTUxNSA1MDA2IHkoaW4pbih0ZXJuYWwpMzMgYihkYXRhYmFzZS4pNTQKYihTYW1lKTMzIGIoYXMp Zyhmb3IpZyBGZShjb2x1bW4pcCBGZygsKWcoaWYpaChpbmRpdmlkdWFsKWcobmFtZXMpZgooYXJl KWcoa25vKW4od24sKWgodGhvc2UpcCBCbGFjayAxOTI2IDUyNTUgYSgzKXAgQmxhY2sKZW9wIGVu ZAolJVBhZ2U6IDQgNApUZVhEaWN0IGJlZ2luIDQgMyBib3AgQmxhY2sgQmxhY2sgNTE1IDUyMyBh IEZnKGNhdGFsb2cpMjMKYihuYW1lcylpKFwoKXAgRmUoY2F0YWxvZylwIDEzOTUgNTIzIDI3IDQg diAyOSB3KG5hbWUpcApGZyhcKSlmKGNhbiloKGIpcihlKWcoc3ApcihlY2lcMDE0ZWQuKTM3IGIo SWYpMjUgYih0aGUpaChuYW1lKWYob2YpZwooZGF0YSlnKHNlcnYpbihlcnMpZShhcmUpNTE1IDYy MyB5KGtubyluKHduLClrKHRoYXQpaChjYW4pZihiKXIoZSloCihhZGRlZClmKHByaW9yKWcodG8p Zyh0aGUpaChjYXRhbG9nKWUobmFtZS4pNjM5IDcyMiB5KFdoZW4pNDAKYihpbmRpdmlkdWFsKWYo Y2F0YWxvZyllKG5hbWVzKWgoYXJlKWcobm90KWgoa25vKW4od24sKWkoayluKGV5dyluCihvcmRz KWMod2hpYyluKGgpaChkZXNjcmliKXIoZSk1MTUgODIyIHkodGhlKWcodGFyZ2V0KWcoY2F0YWxv ZylmKGNhbiloCihiKXIoZSlnKHNwKXIoZWNpXDAxNGVkLik3MCBiIEZlKEtFWVdPUkQpcCBGZyhz KTM1IGIoYXJlKWkodGhlKWkodyluCihvcmRzKWUodG8paChjKW4oaGFyYWN0ZXJpemUpNTE1IDky MiB5KHRoZSkzMyBiKGNhdGFsb2cpZShsaWspbihlKWkKKHRoZSlnKGNvbiluKHRlbiluKHQpZihv ZiloKGNhdGFsb2cpZihzdWMpbihoKWcoYXMpZyhcXGNvc21pYylnKHJhKW4KKHkiLClnKFxcU2lP KWgobWFzYXIiLClmKG9yKTUxNSAxMDIxIHkodGVsZXNjb3ApcihlL2luc3RydW1lbiluKHQpagoo bmFtZSloKHdoaWMpbihoKWcoZGF0YSlmKGFyZSlnKHRhayluKGVuLik2MSBiKE11bHRpcGxlKTM3 CmIgRmUoS0VZV09SRClwIEZnKHMpYyhjYW4paihiKXIoZSk1MTUgMTEyMSB5KGNvbSluKGJpbmVk KTI3CmIoZm9yKWcobW9yZSlnKHNwKXIoZWNpXDAxNGMpaChzZWxlY3Rpb24pZihvZilnKGNhdGFs b2cuKTYzOQoxMjIwIHkoV2hlbiloIEZlKEtFWVdPUkQpcCBGZyhzKWMoYXJlKWkoc3ApcihlY2lc MDE0ZWQsKWkoSlYpbihPKWUKKHN5c3RlbSloKHdpbGwpZyhsbylyKG9rKWcodXApZyhjb3JyZXNw KXIob25kaW5nKWUoY2F0YS0pNTE1CjEzMjAgeShsb2dzKTIwIGIoZnJvbSloKGRhdGEpZyhyZWdp c3RyeSktNyBiKC4pMzMgYihXaGVuKTIyCmIobSluKHVsdGlwbGUpZyhjYXRhbG9ncylkKGFyZSlo KGZvdW5kLClqKG9wKXIoZXJhbmRzKWUobGlrKW4oZSlmCkZlKHNlbGVjdCk1MTUgMTQyMCB5KGJ5 KTQyIGIoUFJPUEVSVFkpMjAgYiBGZyhhbmQpaiBGZShBTEwpZgpGZyh3aWxsKWgoc2VsZWN0KWco YW1vbmcpZih0aGVtLikzNiBiIEZlKFBST1BFUlRZKTIwCmIgRmcoaXMpaih0aGUpaChpbmRleClm KHdoaWMpbihoKWcod2lsbCk1MTUgMTUxOSB5KHJhbmspZihjYXRhbG9ncywpaAooc3VjKW4oaCln KGFzKWcoXFxkZXRlY3Rpb24paChsaW1pdCIsKWcoXFxtZWFzdXJlbWVuKW4odClmKGFjY3VyYWN5 IiwpZgooYW5kKWgodGhleSloKGFyZSk1MTUgMTYxOSB5KGFsc28pMzMgYihzdG9yZWQpaChpbilo KHRoZSlnKGRhdGEpZwoocmVnaXN0cnkpLTcgYiguKTU2IGIgRmUoQUxMKTM0IGIgRmcobWVhbnMp ZyhhbGwpaChzZWxlY3RlZClmKGNhdGFsb2dzKQpmKGFyZSloKHVzZWQpaChmb3IpNTE1IDE3MTkg eShzZWFyYyluKGguKTYzOSAxODE4IHkoV2hlbilmCkZlKEFMTCllIEZnKGlzKWgoc3ApcihlY2lc MDE0ZWQsKWkodGhlKWYocmVzdWx0cyllKG9mKWgocXVlcnkpZyhmcm9tKWcKKGVhYyluKGgpZihj YXRhbG9nKWcod2lsbCloKGIpcihlKWgoY29uLSk1MTUgMTkxOCB5KGNhdGVuYXRlZCkyNwpiKGlu KW4odG8pZyhvbmUpaCh0YWJsZSlmKGluKWgodGhlKWcoZGlyZWN0aW9uKWYob2YpaChpbnNlcnRp bmcpZgoocmVjb3Jkcy4pNjM5IDIwMTcgeSBGZShuYW1lKWYgRmcod2lsbClpKHNwKXIoZWNpZnkp Zyh0aGUpZyhhbHRlcm5hdGUpZgoobmFtZSlnKG9mKWgodGhlKWcoY2F0YWxvZyllKGluKWkodGhp cylmKHF1ZXJ5KS03IGIoLilwCkJsYWNrIEJsYWNrIDUxNSAyMTg3IGEgRmUoZGF0YSk0MiBiKDop aChLRVlXT1JEMSlkKCYpaihLRVlXT1JEMillKC4uLikKMTE2OSAyMjg3IHkoW3NlbGVjdClmKFti eSlqKFtNQVh8TUlOXVwoUFJPUEUpbyhSVFkpbyhcKSkzNwpiKHwpNDMgYihBTExdXSlmKFtuYW1l XSlmKHwpODIwIDIzODcgeShbc2VydmVyLl1jYXRhbG9nKW8oX24pbyhhbWUpMTE2OQoyNDg2IHko W3NlbGVjdClmKFtieSlqKFtNQVh8TUlOXVwoUFJPUEUpbyhSVFkpbyhcKSkzNwpiKHwpNDMgYihB TExdXSlmKFtuYW1lXSk2MzkgMjY1NiB5KGRhdGEpMjggYiBGZyh3aWxsKWkoc3ApcihlY2lmeSln Cih0aGUpZyhuYW1lKWYob2YpaChpbWFnZSlmKGRhdGEpZyhzdG9yZWQpZyhpbiloKHRoZSlnKHJl bW90ZSlmKGRhdGEpZwooc2VydiluKGVyLik1MTUgMjc1NiB5KFRoZSkzNSBiKHcpbihhKW4oeSll KGZvcilpKHNwKXIoZWNpXDAxNGNhdGlvbilmCihpcyloKHNhbWUpZihhcyloIEZlKGNhdGFsb2cp cCBGZyguKTU2IGIoTm90ZSkzNSBiKHRoYXQpZwpGZShBTEwpZiBGZyhpcylnKHNwKXIoZWNpXDAx NGVkKWkoZm9yKTUxNSAyODU1IHkoaW1hZ2UpZChkYXRhLCloKGFsbClnCihpbWFnZSlmKGRhdGEp Zyh3aWxsKWgoYilyKGUpZyhzZWFyYyluKGhlZCllKGZvciloKGVhYyluKGgpZyhyZWNvcmQpZgoo b2YpaShjYXRhbG9nLClmKHdoaWMpbihoKTUxNSAyOTU1IHkod2lsbCkyOCBiKGIpcihlKWcoYWRk ZWQpZihpbiluKHRvKQpnKHRhYmxlKWgoYXMpZihuZXcpaChjb2x1bW5zLik2MzkgNDU0OCB5IEBi ZWdpbnNwZWNpYWwKMCBAbGx4IDAgQGxseSAzMjYgQHVyeCAxNjkgQHVyeSAzMjYwIEByd2kgQHNl dHNwZWNpYWwKJSVCZWdpbkRvY3VtZW50OiBmaWcyLnBzdGV4CiUhUFMtQWRvYmUtMi4wIEVQU0Yt Mi4wCiUlVGl0bGU6IC9kZXYvZnMvQy93b3JrL0pWTy9maWcyLmZpZwolJUNyZWF0b3I6IGZpZzJk ZXYgVmVyc2lvbiAzLjIgUGF0Y2hsZXZlbCA0CiUlQ3JlYXRpb25EYXRlOiBUaHUgRmViIDEzIDE4 OjU2OjU0IDIwMDMKJSVGb3I6IG55YXN1ZGFAdHAtdDMwICgpCiUlQm91bmRpbmdCb3g6IDAgMCAz MjYgMTY5CiUlTWFnbmlmaWNhdGlvbjogMC41MDAwCiUlRW5kQ29tbWVudHMKLyRGMnBzRGljdCAy MDAgZGljdCBkZWYKJEYycHNEaWN0IGJlZ2luCiRGMnBzRGljdCAvbXRyeCBtYXRyaXggcHV0Ci9j b2wtMSB7MCBzZXRncmF5fSBiaW5kIGRlZgovY29sMCB7MC4wMDAgMC4wMDAgMC4wMDAgc3JnYn0g YmluZCBkZWYKL2NvbDEgezAuMDAwIDAuMDAwIDEuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyIHsw LjAwMCAxLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMyB7MC4wMDAgMS4wMDAgMS4wMDAg c3JnYn0gYmluZCBkZWYKL2NvbDQgezEuMDAwIDAuMDAwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9j b2w1IHsxLjAwMCAwLjAwMCAxLjAwMCBzcmdifSBiaW5kIGRlZgovY29sNiB7MS4wMDAgMS4wMDAg MC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDcgezEuMDAwIDEuMDAwIDEuMDAwIHNyZ2J9IGJpbmQg ZGVmCi9jb2w4IHswLjAwMCAwLjAwMCAwLjU2MCBzcmdifSBiaW5kIGRlZgovY29sOSB7MC4wMDAg MC4wMDAgMC42OTAgc3JnYn0gYmluZCBkZWYKL2NvbDEwIHswLjAwMCAwLjAwMCAwLjgyMCBzcmdi fSBiaW5kIGRlZgovY29sMTEgezAuNTMwIDAuODEwIDEuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wx MiB7MC4wMDAgMC41NjAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDEzIHswLjAwMCAwLjY5MCAw LjAwMCBzcmdifSBiaW5kIGRlZgovY29sMTQgezAuMDAwIDAuODIwIDAuMDAwIHNyZ2J9IGJpbmQg ZGVmCi9jb2wxNSB7MC4wMDAgMC41NjAgMC41NjAgc3JnYn0gYmluZCBkZWYKL2NvbDE2IHswLjAw MCAwLjY5MCAwLjY5MCBzcmdifSBiaW5kIGRlZgovY29sMTcgezAuMDAwIDAuODIwIDAuODIwIHNy Z2J9IGJpbmQgZGVmCi9jb2wxOCB7MC41NjAgMC4wMDAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2Nv bDE5IHswLjY5MCAwLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMjAgezAuODIwIDAuMDAw IDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyMSB7MC41NjAgMC4wMDAgMC41NjAgc3JnYn0gYmlu ZCBkZWYKL2NvbDIyIHswLjY5MCAwLjAwMCAwLjY5MCBzcmdifSBiaW5kIGRlZgovY29sMjMgezAu ODIwIDAuMDAwIDAuODIwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyNCB7MC41MDAgMC4xOTAgMC4wMDAg c3JnYn0gYmluZCBkZWYKL2NvbDI1IHswLjYzMCAwLjI1MCAwLjAwMCBzcmdifSBiaW5kIGRlZgov Y29sMjYgezAuNzUwIDAuMzgwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyNyB7MS4wMDAgMC41 MDAgMC41MDAgc3JnYn0gYmluZCBkZWYKL2NvbDI4IHsxLjAwMCAwLjYzMCAwLjYzMCBzcmdifSBi aW5kIGRlZgovY29sMjkgezEuMDAwIDAuNzUwIDAuNzUwIHNyZ2J9IGJpbmQgZGVmCi9jb2wzMCB7 MS4wMDAgMC44ODAgMC44ODAgc3JnYn0gYmluZCBkZWYKL2NvbDMxIHsxLjAwMCAwLjg0MCAwLjAw MCBzcmdifSBiaW5kIGRlZgoKZW5kCnNhdmUKbmV3cGF0aCAwIDE2OSBtb3ZldG8gMCAwIGxpbmV0 byAzMjYgMCBsaW5ldG8gMzI2IDE2OSBsaW5ldG8gY2xvc2VwYXRoIGNsaXAgbmV3cGF0aAotMTcu MyAxNzUuNyB0cmFuc2xhdGUKMSAtMSBzY2FsZQoKL2NwIHtjbG9zZXBhdGh9IGJpbmQgZGVmCi9l ZiB7ZW9maWxsfSBiaW5kIGRlZgovZ3Ige2dyZXN0b3JlfSBiaW5kIGRlZgovZ3Mge2dzYXZlfSBi aW5kIGRlZgovc2Ege3NhdmV9IGJpbmQgZGVmCi9ycyB7cmVzdG9yZX0gYmluZCBkZWYKL2wge2xp bmV0b30gYmluZCBkZWYKL20ge21vdmV0b30gYmluZCBkZWYKL3JtIHtybW92ZXRvfSBiaW5kIGRl ZgovbiB7bmV3cGF0aH0gYmluZCBkZWYKL3Mge3N0cm9rZX0gYmluZCBkZWYKL3NoIHtzaG93fSBi aW5kIGRlZgovc2xjIHtzZXRsaW5lY2FwfSBiaW5kIGRlZgovc2xqIHtzZXRsaW5lam9pbn0gYmlu ZCBkZWYKL3NsdyB7c2V0bGluZXdpZHRofSBiaW5kIGRlZgovc3JnYiB7c2V0cmdiY29sb3J9IGJp bmQgZGVmCi9yb3Qge3JvdGF0ZX0gYmluZCBkZWYKL3NjIHtzY2FsZX0gYmluZCBkZWYKL3NkIHtz ZXRkYXNofSBiaW5kIGRlZgovZmYge2ZpbmRmb250fSBiaW5kIGRlZgovc2Yge3NldGZvbnR9IGJp bmQgZGVmCi9zY2Yge3NjYWxlZm9udH0gYmluZCBkZWYKL3N3IHtzdHJpbmd3aWR0aH0gYmluZCBk ZWYKL3RyIHt0cmFuc2xhdGV9IGJpbmQgZGVmCi90bnQge2R1cCBkdXAgY3VycmVudHJnYmNvbG9y CiAgNCAtMiByb2xsIGR1cCAxIGV4Y2ggc3ViIDMgLTEgcm9sbCBtdWwgYWRkCiAgNCAtMiByb2xs IGR1cCAxIGV4Y2ggc3ViIDMgLTEgcm9sbCBtdWwgYWRkCiAgNCAtMiByb2xsIGR1cCAxIGV4Y2gg c3ViIDMgLTEgcm9sbCBtdWwgYWRkIHNyZ2J9CiAgYmluZCBkZWYKL3NoZCB7ZHVwIGR1cCBjdXJy ZW50cmdiY29sb3IgNCAtMiByb2xsIG11bCA0IC0yIHJvbGwgbXVsCiAgNCAtMiByb2xsIG11bCBz cmdifSBiaW5kIGRlZgogL0RyYXdFbGxpcHNlIHsKCS9lbmRhbmdsZSBleGNoIGRlZgoJL3N0YXJ0 YW5nbGUgZXhjaCBkZWYKCS95cmFkIGV4Y2ggZGVmCgkveHJhZCBleGNoIGRlZgoJL3kgZXhjaCBk ZWYKCS94IGV4Y2ggZGVmCgkvc2F2ZW1hdHJpeCBtdHJ4IGN1cnJlbnRtYXRyaXggZGVmCgl4IHkg dHIgeHJhZCB5cmFkIHNjIDAgMCAxIHN0YXJ0YW5nbGUgZW5kYW5nbGUgYXJjCgljbG9zZXBhdGgK CXNhdmVtYXRyaXggc2V0bWF0cml4Cgl9IGRlZgoKLyRGMnBzQmVnaW4geyRGMnBzRGljdCBiZWdp biAvJEYycHNFbnRlcmVkU3RhdGUgc2F2ZSBkZWZ9IGRlZgovJEYycHNFbmQgeyRGMnBzRW50ZXJl ZFN0YXRlIHJlc3RvcmUgZW5kfSBkZWYKCiRGMnBzQmVnaW4KMTAgc2V0bWl0ZXJsaW1pdAowIHNs aiAwIHNsYwogMC4wMzAwMCAwLjAzMDAwIHNjCiUKJSBGaWcgb2JqZWN0cyBmb2xsb3cKJQolIAol IGhlcmUgc3RhcnRzIGZpZ3VyZSB3aXRoIGRlcHRoIDUwCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNj ZiBzZgo2NzUgMjc3NSBtCmdzIDEgLTEgc2MgKFhNQVRDSFwoYzEsIGMyLCAuLi5cKSkgY29sMCBz aCBncgolIFBvbHlsaW5lCjE1LjAwMCBzbHcKbiAyNDAwIDEyMDAgbQogNzgwMCAxMjAwIGwgZ3Mg Y29sMCBzIGdyIAolIFBvbHlsaW5lCm4gMjQwMCAxNTAwIG0KIDc4MDAgMTUwMCBsIGdzIGNvbDAg cyBnciAKJSBQb2x5bGluZQpuIDI0MDAgMTgwMCBtCiA3ODAwIDE4MDAgbCBncyBjb2wwIHMgZ3Ig CiUgUG9seWxpbmUKbiAzMDAwIDYwMCBtCiAzMDAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9s eWxpbmUKbiAzNjAwIDYwMCBtCiAzNjAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUK biA0MjAwIDYwMCBtCiA0MjAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA0ODAw IDYwMCBtCiA0ODAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA1NDAwIDYwMCBt CiA1NDAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2MDAwIDYwMCBtCiA2MDAw IDIxMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2NjAwIDYwMCBtCiA2NjAwIDIxMDAg bCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA3MjAwIDYwMCBtCiA3MjAwIDIxMDAgbCBncyBj b2wwIHMgZ3IgCiUgUG9seWxpbmUKbiAyNDAwIDYwMCBtIDc4MDAgNjAwIGwgNzgwMCAyMTAwIGwg MjQwMCAyMTAwIGwKIGNwIGdzIGNvbDAgcyBnciAKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNm CjI1NTAgODI1IG0KZ3MgMSAtMSBzYyAocmEpIGNvbDAgc2ggZ3IKL0hlbHZldGljYSBmZiAzMDAu MDAgc2NmIHNmCjMwNzUgODI1IG0KZ3MgMSAtMSBzYyAoZGVjKSBjb2wwIHNoIGdyCi9IZWx2ZXRp Y2EgZmYgMzAwLjAwIHNjZiBzZgo0Mjc1IDgyNSBtCmdzIDEgLTEgc2MgKG0xKSBjb2wwIHNoIGdy Ci9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgo0ODc1IDgyNSBtCmdzIDEgLTEgc2MgKG0yKSBj b2wwIHNoIGdyCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgo2NzUwIDgyNSBtCmdzIDEgLTEg c2MgKGQxKSBjb2wwIHNoIGdyCiUgRWxsaXBzZQpuIDY5MDAgMTA1MCA3NSA3NSAwIDM2MCBEcmF3 RWxsaXBzZSBncyAwLjAwIHNldGdyYXkgZWYgZ3IgZ3MgY29sMCBzIGdyCgolIEVsbGlwc2UKbiA2 OTAwIDEzNTAgNzUgNzUgMCAzNjAgRHJhd0VsbGlwc2UgZ3MgMC4wMCBzZXRncmF5IGVmIGdyIGdz IGNvbDAgcyBncgoKJSBFbGxpcHNlCm4gNjkwMCAxNjUwIDc1IDc1IDAgMzYwIERyYXdFbGxpcHNl IGdzIDAuMDAgc2V0Z3JheSBlZiBnciBncyBjb2wwIHMgZ3IKCiUgUG9seWxpbmUKbiA2MDAgMzkw MCBtIDM2MDAgMzkwMCBsIDM2MDAgNTQwMCBsIDYwMCA1NDAwIGwKIGNwIGdzIGNvbDAgcyBnciAK JSBQb2x5bGluZQpuIDE4MDAgMzkwMCBtCiAxODAwIDU0MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9s eWxpbmUKbiAyNDAwIDM5MDAgbQogMjQwMCA1NDAwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5l Cm4gMzAwMCAzOTAwIG0KIDMwMDAgNTQwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDEy MDAgMzkwMCBtCiAxMjAwIDU0MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2MDAgNDIw MCBtCiAzNjAwIDQyMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2MDAgNDUwMCBtCiAz NjAwIDQ1MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2MDAgNDgwMCBtCiAzNjAwIDQ4 MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2MDAgNTEwMCBtCiAzNjAwIDUxMDAgbCBn cyBjb2wwIHMgZ3IgCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgo3NTAgNDEyNSBtCmdzIDEg LTEgc2MgKHJhKSBjb2wwIHNoIGdyCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgoxMjc1IDQx MjUgbQpncyAxIC0xIHNjIChkZWMpIGNvbDAgc2ggZ3IKL0hlbHZldGljYSBmZiAzMDAuMDAgc2Nm IHNmCjI0NzUgNDEyNSBtCmdzIDEgLTEgc2MgKG0xKSBjb2wwIHNoIGdyCiUgUG9seWxpbmUKbiA0 NTAwIDM5MDAgbSA3NTAwIDM5MDAgbCA3NTAwIDU0MDAgbCA0NTAwIDU0MDAgbAogY3AgZ3MgY29s MCBzIGdyIAolIFBvbHlsaW5lCm4gNTcwMCAzOTAwIG0KIDU3MDAgNTQwMCBsIGdzIGNvbDAgcyBn ciAKJSBQb2x5bGluZQpuIDYzMDAgMzkwMCBtCiA2MzAwIDU0MDAgbCBncyBjb2wwIHMgZ3IgCiUg UG9seWxpbmUKbiA2OTAwIDM5MDAgbQogNjkwMCA1NDAwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHls aW5lCm4gNTEwMCAzOTAwIG0KIDUxMDAgNTQwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpu IDQ1MDAgNDIwMCBtCiA3NTAwIDQyMDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA0NTAw IDQ1MDAgbQogNzUwMCA0NTAwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gNDUwMCA0ODAw IG0KIDc1MDAgNDgwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDQ1MDAgNTEwMCBtCiA3 NTAwIDUxMDAgbCBncyBjb2wwIHMgZ3IgCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgo0NjUw IDQxMjUgbQpncyAxIC0xIHNjIChyYSkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBz Y2Ygc2YKNTE3NSA0MTI1IG0KZ3MgMSAtMSBzYyAoZGVjKSBjb2wwIHNoIGdyCi9IZWx2ZXRpY2Eg ZmYgMzAwLjAwIHNjZiBzZgo2Mzc1IDQxMjUgbQpncyAxIC0xIHNjIChtMikgY29sMCBzaCBncgol IEVsbGlwc2UKbiA5OTAwIDQ2NTAgMTUwMCA3NTAgMCAzNjAgRHJhd0VsbGlwc2UgZ3MgY29sMCBz IGdyCgolIEVsbGlwc2UKbiA5OTAwIDQ2NTAgMTA1MCA3NTAgMCAzNjAgRHJhd0VsbGlwc2UgZ3Mg Y29sMCBzIGdyCgolIEVsbGlwc2UKbiA5OTAwIDQ2NTAgNDUwIDc1MCAwIDM2MCBEcmF3RWxsaXBz ZSBncyBjb2wwIHMgZ3IKCiUgUG9seWxpbmUKbiA5OTAwIDM5MDAgbQogOTkwMCA1NDAwIGwgZ3Mg Y29sMCBzIGdyIAolIFBvbHlsaW5lCm4gODQwMCA0NjUwIG0KIDExNDAwIDQ2NTAgbCBncyBjb2ww IHMgZ3IgCiUgUG9seWxpbmUKbiA5MTAxIDQyODEgbSA5MDI2IDQ1MDQgbCA5MjEyIDQzNTYgbCA4 OTg5IDQzNTYgbCA5MTc1IDQ1MDQgbAogOTEwMSA0MjgxIGwgIGNwIGdzIGNvbDAgcyBnciAKJSBQ b2x5bGluZQpuIDg4NTAgNDIwMCBtIDkzMDAgNDIwMCBsIDkzMDAgNDY1MCBsIDg4NTAgNDY1MCBs CiBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiAxMDc1MSA0MzU2IG0gMTA2NzYgNDU3OSBs IDEwODYyIDQ0MzEgbCAxMDYzOSA0NDMxIGwgMTA4MjUgNDU3OSBsCiAxMDc1MSA0MzU2IGwgIGNw IGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDEwNTAwIDQyNzUgbSAxMDk1MCA0Mjc1IGwgMTA5 NTAgNDcyNSBsIDEwNTAwIDQ3MjUgbAogY3AgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gOTg1 MSA0ODA2IG0gOTc3NiA1MDI5IGwgOTk2MiA0ODgxIGwgOTczOSA0ODgxIGwgOTkyNSA1MDI5IGwK IDk4NTEgNDgwNiBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA5NjAwIDQ3MjUgbSAx MDA1MCA0NzI1IGwgMTAwNTAgNTE3NSBsIDk2MDAgNTE3NSBsCiBjcCBncyBjb2wwIHMgZ3IgCiUg UG9seWxpbmUKbiA5MDAgMzYwMCBtCiA5MDAgMzkwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGlu ZQpuIDE1MDAgMzYwMCBtCiAxNTAwIDM5MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA0 ODAwIDM2MDAgbQogNDgwMCAzOTAwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gNTQwMCAz NjAwIG0KIDU0MDAgMzkwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDkwMCAzNjAwIG0K IDE1MDAgMzYwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDQ4MDAgMzYwMCBtCiA1NDAw IDM2MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKZ3MgIGNsaXBwYXRoCjQ1NTMgMjEzMSBt IDQ0NjggMjA0NiBsIDQyNjQgMjI1MCBsIDQ0NzcgMjEyMyBsIDQzNDkgMjMzNSBsIGNwCmVvY2xp cApuIDI3MDAgMzkwMCBtCiA0NTAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgZ3IKCiUgYXJyb3doZWFk Cm4gNDM0OSAyMzM1IG0gNDQ3NyAyMTIzIGwgNDI2NCAyMjUwIGwgNDM0OSAyMzM1IGwgIGNwIGdz IDAuMDAgc2V0Z3JheSBlZiBnciAgY29sMCBzCiUgUG9seWxpbmUKZ3MgIGNsaXBwYXRoCjUxMzYg MjA1MCBtIDUwNDQgMjEyNiBsIDUyMjggMjM0NyBsIDUxMjEgMjEyNSBsIDUzMjAgMjI3MCBsIGNw CmVvY2xpcApuIDY2MDAgMzkwMCBtCiA1MTAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgZ3IKCiUgYXJy b3doZWFkCm4gNTMyMCAyMjcwIG0gNTEyMSAyMTI1IGwgNTIyOCAyMzQ3IGwgNTMyMCAyMjcwIGwg IGNwIGdzIDAuMDAgc2V0Z3JheSBlZiBnciAgY29sMCBzCiUgUG9seWxpbmUKZ3MgIGNsaXBwYXRo CjY5MzMgMjA0OCBtIDY4NDUgMjEyOSBsIDcwNDEgMjM0MCBsIDY5MjIgMjEyNCBsIDcxMjkgMjI1 OSBsIGNwCmVvY2xpcApuIDg3NzUgNDEyNSBtCiA2OTAwIDIxMDAgbCBncyBjb2wwIHMgZ3IgZ3IK CiUgYXJyb3doZWFkCm4gNzEyOSAyMjU5IG0gNjkyMiAyMTI0IGwgNzA0MSAyMzQwIGwgNzEyOSAy MjU5IGwgIGNwIGdzIDAuMDAgc2V0Z3JheSBlZiBnciAgY29sMCBzCiUgUG9seWxpbmUKZ3MgIGNs aXBwYXRoCjg5NDAgNDIxNSBtIDkwNjAgNDIxNSBsIDkwNjAgMzkyOCBsIDkwMDAgNDE2OCBsIDg5 NDAgMzkyOCBsIGNwCmVvY2xpcApuIDkwMDAgMjcwMCBtCiA5MDAwIDQyMDAgbCBncyBjb2wwIHMg Z3IgZ3IKCiUgYXJyb3doZWFkCm4gODk0MCAzOTI4IG0gOTAwMCA0MTY4IGwgOTA2MCAzOTI4IGwg ODk0MCAzOTI4IGwgIGNwIGdzIDAuMDAgc2V0Z3JheSBlZiBnciAgY29sMCBzCiUgUG9seWxpbmUK Z3MgIGNsaXBwYXRoCjk2OTAgNDc0MCBtIDk4MTAgNDc0MCBsIDk4MTAgNDQ1MyBsIDk3NTAgNDY5 MyBsIDk2OTAgNDQ1MyBsIGNwCmVvY2xpcApuIDk3NTAgMjcwMCBtCiA5NzUwIDQ3MjUgbCBncyBj b2wwIHMgZ3IgZ3IKCiUgYXJyb3doZWFkCm4gOTY5MCA0NDUzIG0gOTc1MCA0NjkzIGwgOTgxMCA0 NDUzIGwgOTY5MCA0NDUzIGwgIGNwIGdzIDAuMDAgc2V0Z3JheSBlZiBnciAgY29sMCBzCiUgUG9s eWxpbmUKZ3MgIGNsaXBwYXRoCjEwNTkwIDQyOTAgbSAxMDcxMCA0MjkwIGwgMTA3MTAgNDAwMyBs IDEwNjUwIDQyNDMgbCAxMDU5MCA0MDAzIGwgY3AKZW9jbGlwCm4gMTA2NTAgMjcwMCBtCiAxMDY1 MCA0Mjc1IGwgZ3MgY29sMCBzIGdyIGdyCgolIGFycm93aGVhZApuIDEwNTkwIDQwMDMgbSAxMDY1 MCA0MjQzIGwgMTA3MTAgNDAwMyBsIDEwNTkwIDQwMDMgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVm IGdyICBjb2wwIHMKJSBQb2x5bGluZQpuIDY5MDAgMTY1MCBtIDkwMDAgMTY1MCBsCiA5MDAwIDI0 MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2OTAwIDEwNTAgbSAxMDY1MCAxMDUwIGwK IDEwNjUwIDI0MDAgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA2OTAwIDEzNTAgbSA5NzUw IDEzNTAgbAogOTc1MCAyNDAwIGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gMTIwMCAzNjAw IG0gMTIwMCAzMzAwIGwgNTEwMCAzMzAwIGwKIDUxMDAgMzYwMCBsIGdzIGNvbDAgcyBnciAKJSBQ b2x5bGluZQpncyAgY2xpcHBhdGgKMzA2MSAyMTAwIG0gMjk0NSAyMDcwIGwgMjg3NSAyMzQ5IGwg Mjk5MiAyMTMxIGwgMjk5MiAyMzc4IGwgY3AKZW9jbGlwCm4gMjcwMCAzMzAwIG0KIDMwMDAgMjEw MCBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiAyOTkyIDIzNzggbSAyOTkyIDIxMzEg bCAyODc1IDIzNDkgbCAyOTkyIDIzNzggbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2ww IHMKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNmCjI0MDAgNDUwIG0KZ3MgMSAtMSBzYyAobXl0 YWJsZSkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKNjAwIDU3NzUgbQpn cyAxIC0xIHNjIChjYXRhbG9nMSkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Yg c2YKNDUwMCA1Nzc1IG0KZ3MgMSAtMSBzYyAoY2F0YWxvZzIpIGNvbDAgc2ggZ3IKL0hlbHZldGlj YSBmZiAzMDAuMDAgc2NmIHNmCjg5MjUgMjYyNSBtCmdzIDEgLTEgc2MgKGN1dG91dCByZXF1ZXN0 KSBjb2wwIHNoIGdyCiUgUG9seWxpbmUKbiAyNDAwIDkwMCBtCiA3ODAwIDkwMCBsIGdzIGNvbDAg cyBnciAKJSBoZXJlIGVuZHMgZmlndXJlOwokRjJwc0VuZApycwpzaG93cGFnZQoKJSVFbmREb2N1 bWVudAogQGVuZHNwZWNpYWwgNTE1IDQ3MzcgYSBGYyh3aGVyZSkzMyBiIEZoKGNsYXVzZSk2Mzkg NDgzNgp5IEZlKFhNQVRDSCkyNSBiIEZnKG9wKXIoZXJhbmQpaShtZWFucylnKGNyb3NzKWYobWF0 YyluKGhpbmcpaShtKW4KKHVsdGlwbGUpZyhjYXRhbG9ncy4pcCBCbGFjayBCbGFjayA1MTUgNTAw NiBhIEZlKFhNQVRDSFwoYzEsKTM5CmIoYzIsKWsoIWMzLCllKC4uLlwpKWgoPClpKDMpZihhcmNz ZWMpZShbTkVBUkVTVClmKHwpaihCUklHSFRFU1QpZCh8KWoKKEFMTF0pcCBCbGFjayAxOTI2IDUy NTUgYSBGZyg0KXAgQmxhY2sgZW9wIGVuZAolJVBhZ2U6IDUgNQpUZVhEaWN0IGJlZ2luIDUgNCBi b3AgQmxhY2sgQmxhY2sgNTE1IDUyMyBhIEZnKG1lYW5zKTIyCmIodGhhdClnKGNyb3NzKWYobWF0 YyluKGhpbmcpaCh1c2luZylnKHApcihvc2l0aW9uYWwpZyhpbmZvcm1hdGlvbilnKGIpCnIoZXQp bih3KW4oZWVuKWcgRmUoYzEpZyBGZyhhbmQpZyBGZShjMilnIEZnKHdpdGgpNTE1CjYyMyB5KGFu KTI3IGIoZXJyb3IpZihvZiloKDMpZyhhcmNzZWMpZyhhbmQpZyhzZWxlY3QpZyhvYik1CmIoamVj dHMpMjggYih3aGljKW4oaClmKGFyZSlnKG5vdClnKGluY2x1ZGVkKWgoaW4pZyBGZShjMylwCkZn KC4pNjM5IDcyMiB5KFdoZW4paihtKW4odWx0aXBsZSlmKG9iKTUgYihqZWN0cykyOSBiKGFyZSln KG1hdGMpbihoZWQpCmcoZm9yKWcob25lKWgob2IpNSBiKGplY3QpMjkgYih3aXRoaW4paShhKWUo c3ApcihlY2lcMDE0ZWQpaChlcnJvciwpNTE1CjgyMiB5IEZlKE5FQVJFU1QpcCBGZygsKWYgRmUo QlJJR0hURVNUKXAgRmcoLClnKGFuZClrCkZlKEFMTCllIEZnKHdpbGwpaShzcClyKGVjaWZ5KWYo aG8pbih3KWcodG8paChzZWxlY3QpZihvYik1CmIoamVjdHMpMzIgYihhbW9uZylmKHRoZW0uKTUx NSA5MjIgeShJZilkIEZlKEFMTCllIEZnKGlzKWkoc3ApcgooZWNpXDAxNGVkLClnKGFsbClmKHRo ZSloKGNvbSluKGJpbmF0aW9uKWYod2lsbClnKGIpcihlKWgobGlzdGVkKWcodXAuKQo2MzkgMTAy MSB5KFRob3VnaCkyMSBiIEZlKFwoYzEuY29sdW1uMSkzOSBiKC0payhjMi5jb2x1bW4xXCkpYyg8 KWsoNi4wKQpnKG1hZykyMCBiIEZnKGxvKXIob2tzKWcobGlrKW4oZSloKHRoZSloKGNvbmRpdGlv bmFsKTUxNQoxMTIxIHkoc3RhdGVtZW4pbih0KWsoaW4paCh0aGUpZyhub3JtYWwpZihTUUwpZyhs YW5ndWFnZSwpZyh1bml0KWgoY29uKQpuKHYpbihlcnNpb24pZChhbW9uZylpKGNhdGFsb2dzKWYo d2lsbClpKGIpcihlKTUxNSAxMjIwCnkoZG9uZSlnKHVzaW5nKWcodGhlKWgoaW5mb3JtYXRpb24p ZihpbiloKHRoZSlnKG1ldGFkYXRhKWYob2YpaCh0aGUpZwooY2F0YWxvZ3MpZChiKXIoZWZvcmUp aihjb21wYXJpc29uLik1MTUgMTQyMCB5IEZhKFwwMTcpawpGaChBcmVhKWgoc3ApcyhlY2lcMDE0 Y2F0aW9uKWYob2YpZyhjZWxlc3RpYWwpZihzcGhlcmUpcApCbGFjayBCbGFjayA1MTUgMTYwMiBh IEZlKEFSRUEpNDIgYig6KWgoW0lOU0lERSllKHwpaShPVVRTSURFXSlkKEFSRUEwKQpoKHwpODIw IDE3MDIgeShBUkVBMSlnKFtPVkVSTEFQKWcofClpKFVOSU9OXSllKEFSRUEyKWcofCk4MjAKMTgw MiB5KFNIQVBFKTUxNSAyMDAxIHkoU0hBUEUpZyg6KWkoQk9YXChQT0lOVFwocmEsKWMoZGVjXCks KWkod2lkdGgsKWcKKGhlaWdodFssKWcoUG9zaXRpb24pZihBbmdsZV1cKSlnKHwpODYzIDIxMDAg eShDSVJDTEVcKFBPSU5UXChyYSwpZAooZGVjXCksKTQyIGIocmFkaXVzXCkpZih8KTg2MyAyMjAw IHkoT1ZBTFwoUE9JTlRcKHJhLClkKGRlY1wpLClrCihyYWRpdXMxLCllKHJhZGl1czIsWywpZihQ b3NpdGlvbilpKEFuZ2xlXVwpKWYofCk4NjMKMjMwMCB5KFRSSUFOR0xFXChQT0lOVFwocmEpbygx LClkKGRlYzFcKSwpayhQT0lOVFwocmEyLClmKGRlYzJcKSwpaAooUE9JTlRcKHJhMywpZShkZWMz XClcKSk2MzkgMjQ4MiB5KFBPSU5UXChyYSwpaChkZWNcKSkyNwpiIEZnKHNwKXIoZWNpXDAxNGVz KWgoYSloKHApcihvaW4pbih0KWYob24paCh0aGUpZihza3kpLTcKYiguKTQwIGIoSWYpMjkgYiBG ZShyYSllIEZnKGFuZClpIEZlKGRlYyllIEZnKGFyZSloKGNvbHVtbnMpZyhpbik1MTUKMjU4MiB5 KGEpaShjYXRhbG9nLClnKHRoZSloKGNvKXIob3JkaW5hdGUpZihcKGVxdWF0b3JpYWwsKWcoZ2Fs YWN0aWMsKWgKKG9yKWYoc29tZXRoaW5nKWcoZWxzZVwpKWgob2YpZih0aGVtKWkod2lsbCk1MTUg MjY4Mgp5KGIpcihlKWMoanVkZ2VkKWcoZnJvbSlmKHRoZWlyKWcoVUNEcy4pNjM5IDI3ODEgeSBG ZShJTlNJREUpcApGZygvKXAgRmUoT1VUU0lERSloIEZnKG1lYW5zKWsoaW5zaWRlL291dHNpZGUp aChvZilnKHRoZSloKGFyZWEsKWYKKHJlc3ApcihlY3RpdiluKGVseSktNyBiKC4pNTIgYihTcCly KGVjaVwwMTRjYS0pNTE1IDI4ODEKeSh0aW9uKTI3IGIod2l0aG91dCloKGIpcihvdGgpZyhvZiln KHRoZW0pZyh3KW4ob3JrcyllKGFzKWgKRmUoSU5TSURFKWUgRmcoaXMpaihzcClyKGVjaVwwMTRl ZC4pNjM5IDI5ODAgeSBGZShBUkVBKWQKRmcoY2FuKWgoYilyKGUpaChkZVwwMTRuZWQpZyhhcylm KG8pbih2KW4oZXJsYXApZihcKClwCkZlKE9WRVJMQVApcCBGZyhcKSlmKGFuZC9vciloKHVuaW9u KWkoXCgpcCBGZShVTklPTilwCkZnKFwpKWUob2YpaChtKW4odWx0aXBsZSk1MTUgMzA4MCB5IEZl KEFSRUEpcCBGZyhzLik0MwpiKEVhYyluKGgpMjkgYiBGZShBUkVBKWcgRmcoY2FuKWgoYilyKGUp aChhKWYocmVjdGFuZ2xlKWYoXCgpcApGZShCT1gpcCBGZyhcKSwpaChhKWcoY2lyY2xlKWcoXCgp cCBGZShDSVJDTEUpcCBGZyhcKSwpZShhbilqKG8pbih2KS01CmIoYWwpMjkgYihcKClwIEZlKE9W QUwpcCBGZyhcKSwpNTE1IDMxODAgeShvcillKGEpaCh0cmlhbmdsZSlmKFwoKXAKRmUoVFJJQU5H TEUpcCBGZyhcKS4pZihGKS03IGIob3IpMjggYiBGZShCT1gpZiBGZyhhbmQpaApGZShPVkFMKXAg RmcoLCllKHApcihvc2l0aW9uKWooYW5nbGUpZShjYW4paChiKXIoZSloKHNwKXIoZWNpXDAxNGVk LikzOQpiKElmKTUxNSAzMjc5IHkobm90KTI3IGIoc3ApcihlY2lcMDE0ZWQsKWgoYXhlcylmKHdp bGwpaChiKXIoZSlnCihhbGlnbmVkKWYod2l0aCloKGVxdWF0b3JpYWwpZShjbylyKG9yZGluYXRl cy4pNjM5IDMzNzkKeShXaXRoKTM0IGIodGhlc2UpZyhkZVwwMTRuaXRpb25zLClnKGFyYml0cmFy eSllKHNoYXApcihlcylnKG9uKWgodGhlKWgKKGNlbGVzdGlhbClmKHNwaGVyZSlmKGNhbiloKGIp cihlKWgoZXgtKTUxNSAzNDc5IHkocHJlc3NlZCkyNgpiKHRvKWkoc29tZSlmKGV4dGVuKW4odC4p NTE1IDM2NzggeSBGYShcMDE3KTMyIGIgRmgoVGltZSlnKHJhbmdlKWcoc3ApcwooZWNpXDAxNGNh dGlvbik2MzkgMzc3OCB5IEZnKFNwKXIoZWNpZnkpZChiKW4oeSllKHN0YXJ0aW5nKWcodGltZSlo CihhbmQpZihyYW5nZS4pMzYgYihVbmlvbikyNyBiKG9mKWgodGhlc2UpZyhjYW4pZihiKXIoZSlo KGFsbG8pbih3KW4KKGVkLik1MTUgMzk3NyB5IEZhKFwwMTcpayBGaChXKS04IGIoYSltKHYpbShl bGVuZ3RoKTMzCmIocmFuZ2UpZyhzcClzKGVjaVwwMTRjYXRpb24pNjM5IDQwNzYgeSBGZyhTcCly KGVjaWZ5KWYoYiluKHkpZgooZ2VuZXJhbCllKFwwMTRsdGVyKWkobmFtZXMsKWgod2hldGhlcilm KHNwKXIoZWNpXDAxNGVkKWcodyluKGEpbih2KW4KKGVsZW5ndGgpZShpcylpKHdpdGhpbiloKHRo ZSk1MTUgNDE3NiB5KGJhbmR3aWR0aClnKG9mKWYoZWFjKW4oaClnCihkYXRhLCloKG9yKWUod2hl dGhlcilpKGNlbiluKHRyYWwpZSh3KW4oYSluKHYpbihlbGVuZ3RoKWcob2YpaChlYWMpbgooaCln KGRhdGEpZyhpcylnKHdpdGhpbik1MTUgNDI3NiB5KHNwKXIoZWNpXDAxNGVkKWYodyluKGEpbih2 KW4KKGVsZW5ndGgpZihyYW5nZS4pNDQgYihFYWMpbihoKTI5IGIoXDAxNGx0ZXJzJyloKHNlbnNp dGl2aXQpbih5KWcoaXMpZwooYXNzdW1lZClnKHRvKWgoYilyKGUpZihzdG9yZWQpZyhpbik1MTUg NDM3NSB5KHRoZSllKGRhdGEpZihyZWdpc3RyeSktNwpiKC4pNTE1IDQ1NzUgeSBGaChPcClzKGVy YXRpb24pMzEgYihvZiloKHRhYmxlcyk2MzkgNDY3NAp5IEZnKFQpLTcgYihvKTQwIGIoY3JlYXRl KWYobmV3KWgodGFibGUpZyhmcm9tKWcobSluKHVsdGlwbGUpaCh0YWJsZXMpZgooXChmb3IpZyhl eGFtcGxlLClqKG1lcmdlKWModGFibGVzKWgoZm9yKTUxNSA0Nzc0IHkoaW5kZXApcihlbmRlbilu KHQpCjI0IGIoYXJlYXMpZShpbiluKHRvKWgob25lKWcodGFibGVcKSwpaSh0aGUpZihmb2xsbylu KHdpbmcpZShjb21tYW5kcyloCihjYW4pZyhiKXIoZSloKHVzZWQuKTM2IGIoQWxsKTI0IGIodGhl KTUxNSA0ODczIHkodGFibGVzKWooaGEpbih2KW4oZSlmCih0bylpKGhhKW4odiluKGUpZShzYW1l KWgoY29uXDAxNGd1cmF0aW9uKWYob24paShjb2x1bW5zLilwCkJsYWNrIDE5MjYgNTI1NSBhKDUp cCBCbGFjayBlb3AgZW5kCiUlUGFnZTogNiA2ClRlWERpY3QgYmVnaW4gNiA1IGJvcCBCbGFjayBC bGFjayBCbGFjayBCbGFjayA1MTUgNTIzCmEgRmUoY3JlYXRlKTQxIGIodmlldyloKG5ld3RhYmxl KWUoYXMpODIwIDYyMyB5KHNlbGVjdCloKCopaShmcm9tKWYKKHRhYmxlMSk4MjAgNzIyIHkod2hl cmUpZihbbm90XSloKGV4aXN0KWYodGFibGUyKTUxNQo5MjIgeShjcmVhdGUpZyh2aWV3KWgobmV3 dGFibGUpZShhcyk4MjAgMTAyMSB5KHNlbGVjdCloKCopaShmcm9tKWYKKHRhYmxlMSk4MjAgMTEy MSB5KHVuaW9uKWYoc2VsZWN0KWcoKilqKGZyb20pZSh0YWJsZTIpNjM5CjEzMDMgeSBGZyhUaGUp MTkgYihmb3JtZXIpZShjb21tYW5kKWgod2lsbCloKHNlbGVjdClmKHJlY29yZHMpZihjb21tb24p CmcodG8paShiKXIob3RoKWcgRmUodGFibGUxKWQgRmcoYW5kKWkgRmUodGFibGUyKXAgRmcoLik1 MTUKMTQwMyB5KElmKTI3IGIgRmUobm90KWYgRmcoaXMpaChzcClyKGVjaVwwMTRlZCwpZyhzZWxl Y3QpZyhyZWNvcmRzKWUKKGluKWogRmUodGFibGUxKWMgRmcoYnV0KWsobm90KWYoaW4pZyBGZSh0 YWJsZTIpcCBGZyguKTM0CmIoVGhlKTI3IGIobGF0dGVyKWcoY29tLSk1MTUgMTUwMyB5KG1hbmQp Zyh3aWxsKWgoY29uY2F0ZW5hdGUpZih0KW4odyluCihvKWcodGFibGUuKTUxNSAxNzAyIHkgRmgo Q3V0b3V0KTMzIGIob2YpZih0YWJsZSk2MzkKMTgwMiB5IEZnKFQpLTcgYihvKTIwIGIoY3JlYXRl KWcoY29tcGFjdClmKHRhYmxlKWkod2hpYyluKGgpZihjb24pbgoodGFpbnMpZih0aGUpaShyZWNv cmRzKWUod2l0aClpKHNvbWUpZShjKW4oaGFyYWN0ZXJpc3RpY3MpNTE1CjE5MDEgeShhbmQpMzcg YihpbiluKHRlcmVzdGluZylmKGNvbHVtbnMpaChmcm9tKWcoYmlnKWcodGFibGUsKWoodXNlKWQK KHRoZSlnKGZvbGxvKW4od2luZylmKGNvbW1hbmQpaChzYW1lKWcoYXMpNTE1IDIwMDEgeShjcmVh dGluZykyNgpiKHZpZXcpaShpbilmKFNRTC4pcCBCbGFjayBCbGFjayA1MTUgMjE4MyBhIEZlKGNy ZWF0ZSk0MQpiKHZpZXcpaChuZXd0YWJsZSk4MjAgMjI4MyB5KGFzKWgoc2VsZWN0KWUoY29sdW1u MSwpZihjb2x1bW4yLClnKC4uLikKODIwIDIzODMgeShmcm9tKWkodGFibGUpODIwIDI0ODIgeSh3 aGVyZSlmKGNvbHVtbjMpZyg9KWkob2JqX3N0YXIpZAooYW5kKTEwODEgMjU4MiB5KC4uLik1MTUg Mjc2NSB5IEZkKFwwMTUpMjcgYiBGZyhJbiloKHRoZSlnKGNhc2UpZihvZilnCihcKGNcKSk2Mzkg Mjg2NCB5KEluKTM5IGIodGhpcylmKGNhc2UsKWood2hhdClkKHcpbihlKWcoaGEpbih2KW4oZSlm CihpbiloKG1pbmQpaChpcylmKHNlYXJjKW4oaClmKGZvciloKHRoZSloKGRhdGEpZihvZilnKGFy ZWEpZih3aGVyZSk1MTUKMjk2NCB5KG9ic2VydiluKGVkKTI2IGIoaW4paihkaVwwMTNlcmVuKW4o dClmKHcpbihhKW4odiluKGVsZW5ndGgpZgooYW5kKWgoc2VhcmMpbihoKWYoZm9yKWgoZGF0YSln KG9mKWcoYXJlYSlmKHdoZXJlKWcob2JzZXJ2KW4oZWQpZyhhdCkKNTE1IDMwNjQgeShkaVwwMTNl cmVuKW4odClnKHRpbWUuKTYzOSAzMTYzIHkoQXMpaChhKWYoZ2VuZXJhbClmKGZvcm0pbgoodWxh LCloKHRoZSloKGZvbGxvKW4od2luZylmKHN5biluKHRheClmKGNhbiloKGIpcihlKWgodXNlZC4p cApCbGFjayBCbGFjayA1MTUgMzM0NiBhIEZlKHNlbGVjdCk0MSBiKGQxLmEsKTgyMCAzNDQ1Cnko ZDIuYSwpODIwIDM1NDUgeSguLi4pNTE1IDM2NDUgeShmcm9tKTg1IGIoW3NlcnZlcjFdLmRhdGEx KTM4CmIoZDEsKTc3NiAzNzQ0IHkoW3NlcnZlcjJdLmRhdGEyKWcoZDIsKTc3NiAzODQ0IHkoLi4u KTUxNQozOTQ0IHkod2hlcmUpaihBUkVBKWgoYXMpaChhKXAgQmxhY2sgMTkyNiA1MjU1IGEgRmco NilwCkJsYWNrIGVvcCBlbmQKJSVQYWdlOiA3IDcKVGVYRGljdCBiZWdpbiA3IDYgYm9wIEJsYWNr IEJsYWNrIDYzOSAyMTM2IGEgQGJlZ2luc3BlY2lhbAowIEBsbHggMCBAbGx5IDM0MiBAdXJ4IDIw NCBAdXJ5IDM0MjAgQHJ3aSBAc2V0c3BlY2lhbAolJUJlZ2luRG9jdW1lbnQ6IGZpZzMucHN0ZXgK JSFQUy1BZG9iZS0yLjAgRVBTRi0yLjAKJSVUaXRsZTogL2Rldi9mcy9DL3dvcmsvSlZPL2ZpZzMu ZmlnCiUlQ3JlYXRvcjogZmlnMmRldiBWZXJzaW9uIDMuMiBQYXRjaGxldmVsIDQKJSVDcmVhdGlv bkRhdGU6IFRodSBGZWIgMjcgMjE6Mjc6MzIgMjAwMwolJUZvcjogbnlhc3VkYUB0cC10MzAgKCkK JSVCb3VuZGluZ0JveDogMCAwIDM0MiAyMDQKJSVNYWduaWZpY2F0aW9uOiAwLjUwMDAKJSVFbmRD b21tZW50cwovJEYycHNEaWN0IDIwMCBkaWN0IGRlZgokRjJwc0RpY3QgYmVnaW4KJEYycHNEaWN0 IC9tdHJ4IG1hdHJpeCBwdXQKL2NvbC0xIHswIHNldGdyYXl9IGJpbmQgZGVmCi9jb2wwIHswLjAw MCAwLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMSB7MC4wMDAgMC4wMDAgMS4wMDAgc3Jn Yn0gYmluZCBkZWYKL2NvbDIgezAuMDAwIDEuMDAwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wz IHswLjAwMCAxLjAwMCAxLjAwMCBzcmdifSBiaW5kIGRlZgovY29sNCB7MS4wMDAgMC4wMDAgMC4w MDAgc3JnYn0gYmluZCBkZWYKL2NvbDUgezEuMDAwIDAuMDAwIDEuMDAwIHNyZ2J9IGJpbmQgZGVm Ci9jb2w2IHsxLjAwMCAxLjAwMCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sNyB7MS4wMDAgMS4w MDAgMS4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDggezAuMDAwIDAuMDAwIDAuNTYwIHNyZ2J9IGJp bmQgZGVmCi9jb2w5IHswLjAwMCAwLjAwMCAwLjY5MCBzcmdifSBiaW5kIGRlZgovY29sMTAgezAu MDAwIDAuMDAwIDAuODIwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxMSB7MC41MzAgMC44MTAgMS4wMDAg c3JnYn0gYmluZCBkZWYKL2NvbDEyIHswLjAwMCAwLjU2MCAwLjAwMCBzcmdifSBiaW5kIGRlZgov Y29sMTMgezAuMDAwIDAuNjkwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxNCB7MC4wMDAgMC44 MjAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDE1IHswLjAwMCAwLjU2MCAwLjU2MCBzcmdifSBi aW5kIGRlZgovY29sMTYgezAuMDAwIDAuNjkwIDAuNjkwIHNyZ2J9IGJpbmQgZGVmCi9jb2wxNyB7 MC4wMDAgMC44MjAgMC44MjAgc3JnYn0gYmluZCBkZWYKL2NvbDE4IHswLjU2MCAwLjAwMCAwLjAw MCBzcmdifSBiaW5kIGRlZgovY29sMTkgezAuNjkwIDAuMDAwIDAuMDAwIHNyZ2J9IGJpbmQgZGVm Ci9jb2wyMCB7MC44MjAgMC4wMDAgMC4wMDAgc3JnYn0gYmluZCBkZWYKL2NvbDIxIHswLjU2MCAw LjAwMCAwLjU2MCBzcmdifSBiaW5kIGRlZgovY29sMjIgezAuNjkwIDAuMDAwIDAuNjkwIHNyZ2J9 IGJpbmQgZGVmCi9jb2wyMyB7MC44MjAgMC4wMDAgMC44MjAgc3JnYn0gYmluZCBkZWYKL2NvbDI0 IHswLjUwMCAwLjE5MCAwLjAwMCBzcmdifSBiaW5kIGRlZgovY29sMjUgezAuNjMwIDAuMjUwIDAu MDAwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyNiB7MC43NTAgMC4zODAgMC4wMDAgc3JnYn0gYmluZCBk ZWYKL2NvbDI3IHsxLjAwMCAwLjUwMCAwLjUwMCBzcmdifSBiaW5kIGRlZgovY29sMjggezEuMDAw IDAuNjMwIDAuNjMwIHNyZ2J9IGJpbmQgZGVmCi9jb2wyOSB7MS4wMDAgMC43NTAgMC43NTAgc3Jn Yn0gYmluZCBkZWYKL2NvbDMwIHsxLjAwMCAwLjg4MCAwLjg4MCBzcmdifSBiaW5kIGRlZgovY29s MzEgezEuMDAwIDAuODQwIDAuMDAwIHNyZ2J9IGJpbmQgZGVmCgplbmQKc2F2ZQpuZXdwYXRoIDAg MjA0IG1vdmV0byAwIDAgbGluZXRvIDM0MiAwIGxpbmV0byAzNDIgMjA0IGxpbmV0byBjbG9zZXBh dGggY2xpcCBuZXdwYXRoCi0yOC43IDIxNC4yIHRyYW5zbGF0ZQoxIC0xIHNjYWxlCgovY3Age2Ns b3NlcGF0aH0gYmluZCBkZWYKL2VmIHtlb2ZpbGx9IGJpbmQgZGVmCi9nciB7Z3Jlc3RvcmV9IGJp bmQgZGVmCi9ncyB7Z3NhdmV9IGJpbmQgZGVmCi9zYSB7c2F2ZX0gYmluZCBkZWYKL3JzIHtyZXN0 b3JlfSBiaW5kIGRlZgovbCB7bGluZXRvfSBiaW5kIGRlZgovbSB7bW92ZXRvfSBiaW5kIGRlZgov cm0ge3Jtb3ZldG99IGJpbmQgZGVmCi9uIHtuZXdwYXRofSBiaW5kIGRlZgovcyB7c3Ryb2tlfSBi aW5kIGRlZgovc2gge3Nob3d9IGJpbmQgZGVmCi9zbGMge3NldGxpbmVjYXB9IGJpbmQgZGVmCi9z bGoge3NldGxpbmVqb2lufSBiaW5kIGRlZgovc2x3IHtzZXRsaW5ld2lkdGh9IGJpbmQgZGVmCi9z cmdiIHtzZXRyZ2Jjb2xvcn0gYmluZCBkZWYKL3JvdCB7cm90YXRlfSBiaW5kIGRlZgovc2Mge3Nj YWxlfSBiaW5kIGRlZgovc2Qge3NldGRhc2h9IGJpbmQgZGVmCi9mZiB7ZmluZGZvbnR9IGJpbmQg ZGVmCi9zZiB7c2V0Zm9udH0gYmluZCBkZWYKL3NjZiB7c2NhbGVmb250fSBiaW5kIGRlZgovc3cg e3N0cmluZ3dpZHRofSBiaW5kIGRlZgovdHIge3RyYW5zbGF0ZX0gYmluZCBkZWYKL3RudCB7ZHVw IGR1cCBjdXJyZW50cmdiY29sb3IKICA0IC0yIHJvbGwgZHVwIDEgZXhjaCBzdWIgMyAtMSByb2xs IG11bCBhZGQKICA0IC0yIHJvbGwgZHVwIDEgZXhjaCBzdWIgMyAtMSByb2xsIG11bCBhZGQKICA0 IC0yIHJvbGwgZHVwIDEgZXhjaCBzdWIgMyAtMSByb2xsIG11bCBhZGQgc3JnYn0KICBiaW5kIGRl Zgovc2hkIHtkdXAgZHVwIGN1cnJlbnRyZ2Jjb2xvciA0IC0yIHJvbGwgbXVsIDQgLTIgcm9sbCBt dWwKICA0IC0yIHJvbGwgbXVsIHNyZ2J9IGJpbmQgZGVmCiAvRHJhd0VsbGlwc2UgewoJL2VuZGFu Z2xlIGV4Y2ggZGVmCgkvc3RhcnRhbmdsZSBleGNoIGRlZgoJL3lyYWQgZXhjaCBkZWYKCS94cmFk IGV4Y2ggZGVmCgkveSBleGNoIGRlZgoJL3ggZXhjaCBkZWYKCS9zYXZlbWF0cml4IG10cnggY3Vy cmVudG1hdHJpeCBkZWYKCXggeSB0ciB4cmFkIHlyYWQgc2MgMCAwIDEgc3RhcnRhbmdsZSBlbmRh bmdsZSBhcmMKCWNsb3NlcGF0aAoJc2F2ZW1hdHJpeCBzZXRtYXRyaXgKCX0gZGVmCgovJEYycHNC ZWdpbiB7JEYycHNEaWN0IGJlZ2luIC8kRjJwc0VudGVyZWRTdGF0ZSBzYXZlIGRlZn0gZGVmCi8k RjJwc0VuZCB7JEYycHNFbnRlcmVkU3RhdGUgcmVzdG9yZSBlbmR9IGRlZgoKJEYycHNCZWdpbgox MCBzZXRtaXRlcmxpbWl0CjAgc2xqIDAgc2xjCiAwLjAzMDAwIDAuMDMwMDAgc2MKJQolIEZpZyBv YmplY3RzIGZvbGxvdwolCiUgCiUgaGVyZSBzdGFydHMgZmlndXJlIHdpdGggZGVwdGggNTAKL0hl bHZldGljYSBmZiAzMDAuMDAgc2NmIHNmCjIxMDAgMTA1MCBtCmdzIDEgLTEgc2MgKEFSRUEgaW5m b3JtYXRpb24pIGNvbDAgc2ggZ3IKJSBQb2x5bGluZQoxNS4wMDAgc2x3Cm4gMzE1MCA2NzAwIG0g MzA1MCA2OTUwIGwgMzI3NSA2ODAwIGwgMzAyNSA2ODAwIGwgMzI1MCA2OTUwIGwKIDMxNTAgNjcw MCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiAzNjAwIDYxMDAgbSAzNTAwIDYzNTAg bCAzNzI1IDYyMDAgbCAzNDc1IDYyMDAgbCAzNzAwIDYzNTAgbAogMzYwMCA2MTAwIGwgIGNwIGdz IGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDM5MDAgNjcwMCBtIDM4MDAgNjk1MCBsIDQwMjUgNjgw MCBsIDM3NzUgNjgwMCBsIDQwMDAgNjk1MCBsCiAzOTAwIDY3MDAgbCAgY3AgZ3MgY29sMCBzIGdy IAolIFBvbHlsaW5lCm4gNDIwMCA1OTUwIG0gNDEwMCA2MjAwIGwgNDMyNSA2MDUwIGwgNDA3NSA2 MDUwIGwgNDMwMCA2MjAwIGwKIDQyMDAgNTk1MCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxp bmUKbiA0NTAwIDY0NzUgbSA0NDAwIDY3MjUgbCA0NjI1IDY1NzUgbCA0Mzc1IDY1NzUgbCA0NjAw IDY3MjUgbAogNDUwMCA2NDc1IGwgIGNwIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDI1NTAg NjQwMCBtIDI0NTAgNjY1MCBsIDI2NzUgNjUwMCBsIDI0MjUgNjUwMCBsIDI2NTAgNjY1MCBsCiAy NTUwIDY0MDAgbCAgY3AgZ3MgY29sMCBzIGdyIAolIEVsbGlwc2UKbiAzNjAwIDYzNzUgMTUwMCA3 NTAgMCAzNjAgRHJhd0VsbGlwc2UgZ3MgY29sMCBzIGdyCgolIFBvbHlsaW5lCm4gODcwMCAxMzAw IG0gODYwMCAxNTUwIGwgODgyNSAxNDAwIGwgODU3NSAxNDAwIGwgODgwMCAxNTUwIGwKIDg3MDAg MTMwMCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA4ODUwIDIyMDAgbSA4NzUwIDI0 NTAgbCA4OTc1IDIzMDAgbCA4NzI1IDIzMDAgbCA4OTUwIDI0NTAgbAogODg1MCAyMjAwIGwgIGNw IGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDkzMDAgMTYwMCBtIDkyMDAgMTg1MCBsIDk0MjUg MTcwMCBsIDkxNzUgMTcwMCBsIDk0MDAgMTg1MCBsCiA5MzAwIDE2MDAgbCAgY3AgZ3MgY29sMCBz IGdyIAolIFBvbHlsaW5lCm4gOTYwMCAyMjAwIG0gOTUwMCAyNDUwIGwgOTcyNSAyMzAwIGwgOTQ3 NSAyMzAwIGwgOTcwMCAyNDUwIGwKIDk2MDAgMjIwMCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9s eWxpbmUKbiA5OTAwIDE0NTAgbSA5ODAwIDE3MDAgbCAxMDAyNSAxNTUwIGwgOTc3NSAxNTUwIGwg MTAwMDAgMTcwMCBsCiA5OTAwIDE0NTAgbCAgY3AgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4g MTAyMDAgMTk3NSBtIDEwMTAwIDIyMjUgbCAxMDMyNSAyMDc1IGwgMTAwNzUgMjA3NSBsIDEwMzAw IDIyMjUgbAogMTAyMDAgMTk3NSBsICBjcCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA4MjUw IDE5MDAgbSA4MTUwIDIxNTAgbCA4Mzc1IDIwMDAgbCA4MTI1IDIwMDAgbCA4MzUwIDIxNTAgbAog ODI1MCAxOTAwIGwgIGNwIGdzIGNvbDAgcyBnciAKJSBFbGxpcHNlCm4gOTMwMCAxODc1IDE1MDAg NzUwIDAgMzYwIERyYXdFbGxpcHNlIGdzIGNvbDAgcyBncgoKJSBQb2x5bGluZQpuIDg3MDAgNTgw MCBtIDg2MDAgNjA1MCBsIDg4MjUgNTkwMCBsIDg1NzUgNTkwMCBsIDg4MDAgNjA1MCBsCiA4NzAw IDU4MDAgbCAgY3AgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gODg1MCA2NzAwIG0gODc1MCA2 OTUwIGwgODk3NSA2ODAwIGwgODcyNSA2ODAwIGwgODk1MCA2OTUwIGwKIDg4NTAgNjcwMCBsICBj cCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiA5MzAwIDYxMDAgbSA5MjAwIDYzNTAgbCA5NDI1 IDYyMDAgbCA5MTc1IDYyMDAgbCA5NDAwIDYzNTAgbAogOTMwMCA2MTAwIGwgIGNwIGdzIGNvbDAg cyBnciAKJSBQb2x5bGluZQpuIDk2MDAgNjcwMCBtIDk1MDAgNjk1MCBsIDk3MjUgNjgwMCBsIDk0 NzUgNjgwMCBsIDk3MDAgNjk1MCBsCiA5NjAwIDY3MDAgbCAgY3AgZ3MgY29sMCBzIGdyIAolIFBv bHlsaW5lCm4gOTkwMCA1OTUwIG0gOTgwMCA2MjAwIGwgMTAwMjUgNjA1MCBsIDk3NzUgNjA1MCBs IDEwMDAwIDYyMDAgbAogOTkwMCA1OTUwIGwgIGNwIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpu IDEwMjAwIDY0NzUgbSAxMDEwMCA2NzI1IGwgMTAzMjUgNjU3NSBsIDEwMDc1IDY1NzUgbCAxMDMw MCA2NzI1IGwKIDEwMjAwIDY0NzUgbCAgY3AgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gODI1 MCA2NDAwIG0gODE1MCA2NjUwIGwgODM3NSA2NTAwIGwgODEyNSA2NTAwIGwgODM1MCA2NjUwIGwK IDgyNTAgNjQwMCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgRWxsaXBzZQpuIDkzMDAgNjM3NSAxNTAw IDc1MCAwIDM2MCBEcmF3RWxsaXBzZSBncyBjb2wwIHMgZ3IKCiUgUG9seWxpbmUKbiAxOTUwIDEy NzUgbSA0OTUwIDEyNzUgbCA0OTUwIDI3NzUgbCAxOTUwIDI3NzUgbAogY3AgZ3MgY29sMCBzIGdy IAolIFBvbHlsaW5lCm4gMjU1MCAxMjc1IG0KIDI1NTAgMjc3NSBsIGdzIGNvbDAgcyBnciAKJSBQ b2x5bGluZQpuIDMxNTAgMTI3NSBtCiAzMTUwIDI3NzUgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxp bmUKbiAzNzUwIDEyNzUgbQogMzc1MCAyNzc1IGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4g NDM1MCAxMjc1IG0KIDQzNTAgMjc3NSBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDE5NTAg MTU3NSBtCiA0OTUwIDE1NzUgbCBncyBjb2wwIHMgZ3IgCiUgUG9seWxpbmUKbiAxOTUwIDE4NzUg bQogNDk1MCAxODc1IGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gMTk1MCAyMTc1IG0KIDQ5 NTAgMjE3NSBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDE5NTAgMjQ3NSBtCiA0OTUwIDI0 NzUgbCBncyBjb2wwIHMgZ3IgCi9IZWx2ZXRpY2EgZmYgMzAwLjAwIHNjZiBzZgoyMDI1IDE4NzUg bQpncyAxIC0xIHNjIChhMSkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YK MjYyNSAxNTc1IG0KZ3MgMSAtMSBzYyAoZDEpIGNvbDAgc2ggZ3IKL0hlbHZldGljYSBmZiAzMDAu MDAgc2NmIHNmCjMyMjUgMTU3NSBtCmdzIDEgLTEgc2MgKGQyKSBjb2wwIHNoIGdyCi9IZWx2ZXRp Y2EgZmYgMzAwLjAwIHNjZiBzZgoyMDI1IDIxNzUgbQpncyAxIC0xIHNjIChhMikgY29sMCBzaCBn cgovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKMjAyNSAyNDc1IG0KZ3MgMSAtMSBzYyAoYTMp IGNvbDAgc2ggZ3IKJSBBcmMKbiAzMjQzLjggMTkxMi41IDIyNjkuMSAtMTM3LjMgMTM3LjMgYXJj bgpncyBjb2wwIHMgZ3IKCiUgQXJjCm4gNzQ0My44IDE5MTIuNSAyMjY5LjEgLTEzNy4zIDEzNy4z IGFyY24KZ3MgY29sMCBzIGdyCgolIEVsbGlwc2UKbiAyODUwIDE3MjUgNzUgNzUgMCAzNjAgRHJh d0VsbGlwc2UgZ3MgY29sNyAwLjAwIHNoZCBlZiBnciBncyBjb2wwIHMgZ3IKCiUgRWxsaXBzZQpu IDM0NTAgMTcyNSA3NSA3NSAwIDM2MCBEcmF3RWxsaXBzZSBncyBjb2w3IDAuMDAgc2hkIGVmIGdy IGdzIGNvbDAgcyBncgoKJSBQb2x5bGluZQpuIDg4NTAgNjAwMCBtIDEwNTAwIDYwMDAgbCAxMDUw MCA3MDUwIGwgODg1MCA3MDUwIGwKIGNwIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDI0NzUg NTc3NSBtIDQxMjUgNTc3NSBsIDQxMjUgNjgyNSBsIDI0NzUgNjgyNSBsCiBjcCBncyBjb2wwIHMg Z3IgCiUgUG9seWxpbmUKIFs5MF0gMCBzZApuIDgxNzUgMTI3NSBtIDk4MjUgMTI3NSBsIDk4MjUg MjMyNSBsIDgxNzUgMjMyNSBsCiBjcCBncyBjb2wwIHMgZ3IgIFtdIDAgc2QKJSBQb2x5bGluZQog WzkwXSAwIHNkCm4gODg1MCAxNTAwIG0gMTA1MDAgMTUwMCBsIDEwNTAwIDI1NTAgbCA4ODUwIDI1 NTAgbAogY3AgZ3MgY29sMCBzIGdyICBbXSAwIHNkCiUgUG9seWxpbmUKbiA4ODUwIDE1MDAgbSA5 ODI1IDE1MDAgbCA5ODI1IDIzMjUgbCA4ODUwIDIzMjUgbAogY3AgZ3MgY29sMCBzIGdyIAolIFBv bHlsaW5lCm4gMjg1MCAxNzI1IG0KIDMyMjUgNDIwMCBsIGdzIGNvbDcgMS4wMCBzaGQgZWYgZ3Ig Z3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCmdzICBjbGlwcGF0aAozNDY4IDYwMjQgbSAzNTg2IDYw MDUgbCAzNTQxIDU3MjEgbCAzNTIwIDU5NjggbCAzNDIzIDU3NDAgbCBjcAplb2NsaXAKbiAzMzAw IDQ1NzUgbQogMzUyNSA2MDAwIGwgZ3MgY29sMCBzIGdyIGdyCgolIGFycm93aGVhZApuIDM0MjMg NTc0MCBtIDM1MjAgNTk2OCBsIDM1NDEgNTcyMSBsIDM0MjMgNTc0MCBsICBjcCBncyAwLjAwIHNl dGdyYXkgZWYgZ3IgIGNvbDAgcwolIFBvbHlsaW5lCmdzICBjbGlwcGF0aAo5MDAxIDY0MzYgbSA5 MDI3IDYzMTkgbCA4NzQ2IDYyNTcgbCA4OTY4IDYzNjggbCA4NzIwIDYzNzQgbCBjcAplb2NsaXAK biA0MzUwIDQ1NzUgbSA0NTc1IDU0MDAgbAogOTAwMCA2Mzc1IGwgZ3MgY29sMCBzIGdyIGdyCgol IGFycm93aGVhZApuIDg3MjAgNjM3NCBtIDg5NjggNjM2OCBsIDg3NDYgNjI1NyBsIDg3MjAgNjM3 NCBsICBjcCBncyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNvbDAgcwolIFBvbHlsaW5lCm4gMzQ1MCAx NzI1IG0KIDQyMDAgNDIwMCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpuIDE1NzUgMzc1IG0K IDU3NzUgMzc1IGwgZ3MgY29sMCBzIGdyIAolIFBvbHlsaW5lCm4gMTU3NSAzNDUwIG0KIDU3NzUg MzQ1MCBsIGdzIGNvbDAgcyBnciAKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKMjczOSA1ODI1IG0g MjgzMCA1NzQ2IGwgMjY0MSA1NTMwIGwgMjc1NCA1NzUxIGwgMjU1MCA1NjA5IGwgY3AKZW9jbGlw Cm4gMjI1MCA1MTc1IG0KIDI3NzUgNTc3NSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQK biAyNTUwIDU2MDkgbSAyNzU0IDU3NTEgbCAyNjQxIDU1MzAgbCAyNTUwIDU2MDkgbCAgY3AgZ3Mg MC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKMTAxNDgg NTk2NSBtIDEwMjI5IDYwNTQgbCAxMDQ0MSA1ODYwIGwgMTAyMjQgNTk3OCBsIDEwMzYwIDU3NzEg bCBjcAplb2NsaXAKbiAxMTEwMCA1MTc1IG0KIDEwMjAwIDYwMDAgbCBncyBjb2wwIHMgZ3IgZ3IK CiUgYXJyb3doZWFkCm4gMTAzNjAgNTc3MSBtIDEwMjI0IDU5NzggbCAxMDQ0MSA1ODYwIGwgMTAz NjAgNTc3MSBsICBjcCBncyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNvbDAgcwolIFBvbHlsaW5lCmdz ICBjbGlwcGF0aAo1NzkwIDUwMTAgbSA1NzkwIDQ4OTAgbCA1NTAzIDQ4OTAgbCA1NzQzIDQ5NTAg bCA1NTAzIDUwMTAgbCBjcAplb2NsaXAKbiAyODUwIDQ5NTAgbQogNTc3NSA0OTUwIGwgZ3MgY29s MCBzIGdyIGdyCgolIGFycm93aGVhZApuIDU1MDMgNTAxMCBtIDU3NDMgNDk1MCBsIDU1MDMgNDg5 MCBsIDU1MDMgNTAxMCBsICBjcCBncyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNvbDAgcwolIFBvbHls aW5lCmdzICBjbGlwcGF0aAo3NDEwIDQ4OTAgbSA3NDEwIDUwMTAgbCA3Njk3IDUwMTAgbCA3NDU3 IDQ5NTAgbCA3Njk3IDQ4OTAgbCBjcAplb2NsaXAKbiAxMDQyNSA0OTUwIG0KIDc0MjUgNDk1MCBs IGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hlYWQKbiA3Njk3IDQ4OTAgbSA3NDU3IDQ5NTAgbCA3 Njk3IDUwMTAgbCA3Njk3IDQ4OTAgbCAgY3AgZ3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMK JSBQb2x5bGluZQpncyAgY2xpcHBhdGgKOTM2MCAyMzEwIG0gOTI0MCAyMzEwIGwgOTI0MCAyNTk3 IGwgOTMwMCAyMzU3IGwgOTM2MCAyNTk3IGwgY3AKZW9jbGlwCm4gNjYwMCA0ODAwIG0gNjYwMCAz NjAwIGwgOTMwMCAzNjAwIGwKIDkzMDAgMjMyNSBsIGdzIGNvbDAgcyBnciBncgoKJSBhcnJvd2hl YWQKbiA5MzYwIDI1OTcgbSA5MzAwIDIzNTcgbCA5MjQwIDI1OTcgbCA5MzYwIDI1OTcgbCAgY3Ag Z3MgMC4wMCBzZXRncmF5IGVmIGdyICBjb2wwIHMKJSBQb2x5bGluZQpncyAgY2xpcHBhdGgKNDQy MCA5MTMgbSA0NDAwIDEwMzEgbCA0NjgzIDEwNzkgbCA0NDU3IDk4MCBsIDQ3MDMgOTYwIGwgY3AK ZW9jbGlwCm4gODg1MCAxNzI1IG0KIDQ0MjUgOTc1IGwgZ3MgY29sMCBzIGdyIGdyCgolIGFycm93 aGVhZApuIDQ3MDMgOTYwIG0gNDQ1NyA5ODAgbCA0NjgzIDEwNzkgbCA0NzAzIDk2MCBsICBjcCBn cyAwLjAwIHNldGdyYXkgZWYgZ3IgIGNvbDAgcwovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YK MjkyNSA0NTAwIG0KZ3MgMSAtMSBzYyAoY3V0b3V0IHJlcXVlc3QpIGNvbDAgc2ggZ3IKL0hlbHZl dGljYSBmZiAzMDAuMDAgc2NmIHNmCjE3MjUgMzAwMCBtCmdzIDEgLTEgc2MgIDkwLjAgcm90IChE aXZpZGUgaW50byBwaWVjZXMpIGNvbDAgc2ggZ3IKL0hlbHZldGljYSBmZiAzMDAuMDAgc2NmIHNm CjEwNTAwIDUxMDAgbQpncyAxIC0xIHNjIChkYXRhMi5BUkVBXChcKSkgY29sMCBzaCBncgovSGVs dmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKOTc1IDUxMDAgbQpncyAxIC0xIHNjIChkYXRhMS5BUkVB XChcKSkgY29sMCBzaCBncgovSGVsdmV0aWNhIGZmIDMwMC4wMCBzY2Ygc2YKNTkyNSA1MTAwIG0K Z3MgMSAtMSBzYyAoT1ZFUkxBUCkgY29sMCBzaCBncgolIFBvbHlsaW5lCm4gMzAwMCA1ODAwIG0g MjkwMCA2MDUwIGwgMzEyNSA1OTAwIGwgMjg3NSA1OTAwIGwgMzEwMCA2MDUwIGwKIDMwMDAgNTgw MCBsICBjcCBncyBjb2wwIHMgZ3IgCiUgaGVyZSBlbmRzIGZpZ3VyZTsKJEYycHNFbmQKcnMKc2hv d3BhZ2UKCiUlRW5kRG9jdW1lbnQKIEBlbmRzcGVjaWFsIDE2NyB4IEZlKEFSRUEpMzAgYiBGZyhz cClyKGVjaVwwMTRlcyloKHRoZSlnKGFyZWEpZihzZWFyYykKbihoKWcoZm9yKWcodGhlKWkoZGF0 YS4pNDcgYihJZikzMSBiKGl0KWgoY2FuKWUoYilyKGUpaShleHByZXNzZWQpZShiKW4KKHkpaCBG ZShBUkVBKTUxNSAyNDAzIHkgRmcob3ApcihlcmFuZHMpayhkZXNjcmliKXIoZWQpZyhiKXIoZWZv cmUsKWoKKHRoYXQpZShleHByZXNzaW9uKWUod2lsbClpKGIpcihlKWgodXNlZC4pNjEgYihJZikz NwpiKG5vdCwpZyh1c2VyKWYoZGVcMDE0bmVkKTUxNSAyNTAyIHkoZnVuY3Rpb25zKTIzIGIod2ls bClnKGIpcihlKWcKKHVzZWQuKTM1IGIoT25lKTIyIGIoc3VnZ2VzdGlvbilmKGZvciloKHRoZSlo KGluKW4odGVyZmFjZSlmKG9mKWgodXNlcikKZihkZVwwMTRuZWQpaChmdW5jdGlvbnMpNTE1IDI2 MDIgeShpcykyOSBiKHRoYXQpaChvdXRwdXQpaCh3aWxsKWYoYilyCihlKWcoYSlmKGxpc3QpaChv ZilnKEhUTSlnKFwoSGllcmFyYyluKGhpY2FsKWYoVCktNyBiKHJpYW5nbGUpMjgKYihNZXNoXCkp aShpbmRpY2VzLik0NCBiKEYpLTcgYihvcik1MTUgMjcwMiB5KHRoZSkyOApiKGRhdGEpZihvZiln KHRpbWUpaChzZXJpZXMsKWYodGhpcyloKGxpc3QpZyh3aWxsKWcoYilyKGUpZyhhKWYocGFpciln CihvZilnKEhUTSloKGluZGV4KWcoYW5kKWYodGltZS4pNjM5IDI4MDEgeShUaGUpaihyZXRyaWV2 KW4oZWQpZihkYXRhKWgKKHdpbGwpZyhiKXIoZSloKGNvbnN0cnVjdGVkKWUoZnJvbSloKG1hbilu KHkpZihkYXRhKWgoXDAxNGxlcy4pNDQKYihIbyluKHcpbihldiluKGVyLCkyOSBiKHRoZSk1MTUg MjkwMSB5KHJldHJpZXYpbihlZCljKGRhdGEpaCh3aWxsKWcoYikKcihlKWgoc3RvcmVkKWYoaW4p Zyh0aGUpaChzeXN0ZW0pZihhcylnKGlmKWgodGhhdClmKGlzKWgob25lKWYoc2V0KWcKKG9mKWco ZGF0YSlnKGZvcilnKHVzZXJzKTUxNSAzMDAwIHkoYW5kKWQodGhlKWkoc2FtZSllKGltYWdlKWco YWNjZXNzKWYKKG1ldGhvKXIoZClqKGNhbillKGIpcihlKWgoYXBwbGllZClnKHNhbWUpZihhcyln KGZvcilnKHRoZSlpKGV4dGVybmFsKWUKKGRhdGEpNTE1IDMxMDAgeShzZXJ2KW4oZXJzLik2Mzkg MzIwMCB5KFRoZSkyOCBiKGZvbGxvKW4od2luZ3MpZShhcmUpaAooc2ltcGxlKWgoZXhhbXBsZXMu KTUxNSAzMzY3IHkgRmQoXDAxNylmIEZnKFJldHJpZXYpbihlKWcodGhlKWgoZGF0YSlmCihmb3Ip Zyh0aGUpaChhcmVhKWUod2hlcmUpaCgyKWcoY29sb3JzKWYoYXJlKWgoYSluKHYpLTUKYihhaWxh YmxlKXAgQmxhY2sgQmxhY2sgNTE1IDM1MDkgYSBGZShzZWxlY3QpNDEgYihYLmEsKTgyMAozNjA5 IHkoWS5hKTUxNSAzNzA4IHkoZnJvbSkxMjkgYihkYXRhMS53YXZlbGVuZ3RoKW8oMSkzNwpiKFgs KTgyMCAzODA4IHkoZGF0YTIud2F2ZWxlbmd0aClvKDIpZyhZKTUxNSAzOTA3IHkod2hlcmUpODUK YihcKFguQVJFQVwoXCkpNDAgYihPVkVSTEFQKWcoWS5BUkVBXChcKVwpKWcoYXMpaihhKTYzOQo0 MDUwIHkoWC5BUkVBXChcKSllKD0paShkYXRhMS53YXZlbGVuZ3RoKW8oMS4pbyhBUilvKEVBXCgp byhcKSkxMgpiIEZnKHJlcHJlc2VuKW4odHMpMTcgYih0aGUpaShhcmVhKWUod2hlcmUpaCh0aGUp ZyhkYXRhKTUxNQo0MTQ5IHkoaW4pMjggYihhbilmKGltYWdlKWcoZGF0YSlnKGFyYyluKGhpdilu KGUpZiBGZShkYXRhMSlmCkZnKGNvKW4odiluKGVycyloKGluKWkoYSlmKHcpbihhKW4odiluKGVs ZW5ndGgpZiBGZSh3YXZlbGVuZ3RoMSlwCkZnKC4pNTE1IDQzMTYgeSBGZChcMDE3KWggRmcoUmV0 cmlldiluKGUpZyh0aGUpaChkYXRhKWYoZm9yKWcodGhlKWgKKGFyZWEpZSh3aGVyZSloKG9ic2Vy diluKGVkKWYoYXQpaSgyKWYoZGlcMDEzZXJlbiluKHQpZyh0aW1lcylwCkJsYWNrIEJsYWNrIDUx NSA0NDU5IGEgRmUoc2VsZWN0KTQxIGIoWC5hLCk4MjAgNDU1OCB5KFkuYSk1MTUKNDY1OCB5KGZy b20pMTI5IGIoZGF0YSk0MiBiKFgsKWgoWSk1MTUgNDc1NyB5KHdoZXJlKTg1CmIoXChESUZGXChY Lm9ic19kYXRlKW8oLCkzNyBiKFkub2JzX2RhdGVcKSlpKD4pNDQgYigzMCllKGRheXNcKSk4NjMK NDg1NyB5KGFuZCk4NjMgNDk1NyB5KFguQVJFQVwoXCkpZihPVkVSTEFQKWYoWS5BUkVBXChcKVwp KWcoYXMpaihhKXAKQmxhY2sgMTkyNiA1MjU1IGEgRmcoNylwIEJsYWNrIGVvcCBlbmQKJSVUcmFp bGVyCgp1c2VyZGljdCAvZW5kLWhvb2sga25vd257ZW5kLWhvb2t9aWYKJSVFT0YK --=====================_3400409==_-- From - Fri Feb 28 16:45:45 2003 X-UIDL: 3e5baf6500000057 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1SFlZNb023544 for ; Fri, 28 Feb 2003 16:47:35 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1SFlZS17639 for ; Fri, 28 Feb 2003 16:47:35 +0100 (MET) Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAsQaWCI; Fri, 28 Feb 03 16:47:34 +0100 Received: from gumtree.tuc.noao.edu ([140.252.4.35] verified) by noao.edu (CommuniGate Pro SMTP 4.0.3) with ESMTP id 6633508; Fri, 28 Feb 2003 08:46:17 -0700 Received: (from robyn@localhost) by gumtree.tuc.noao.edu (8.11.6/8.11.6) id h1SFhpH08303; Fri, 28 Feb 2003 08:43:51 -0700 Date: Fri, 28 Feb 2003 08:43:51 -0700 From: Robyn Allsman To: Clive Page Cc: voql , metadata Subject: Re: new version of high level language Message-ID: <20030228084351.S4784@gumtree.tuc.noao.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Fri, Feb 28, 2003 at 09:08:15AM +0000 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hello All, To add to the list of DB types used for astronomy datasets, the MACHO Project image and variable star catalogs use a Z39.50 DB (Indexdata). The complete time-sequenced lightcurve catalog is "an astronomer-written DBMS" due to the expansion factor should it have been installed under a traditional DBM. > On Thu, 27 Feb 2003, Reagan Moore wrote: > > > We have the technology to map from an XML specification of > > attributes, values, and operations on values, to the SQL required by > > a particular database (Oracle, DB2, Sybase, SQLServer, PostgresSQL, > > Informix). > > > The technology does require the registration of the table structure, > > foreign keys, and schema of each database for the automation of the > > SQL generation. > > > Are there other types of databases in current use? -- Roberta (Robyn) Allsman phone: 520-318-8221 National Optical Astronomy Observatory FAX: 520-318-8360 950 N. Cherry Avenue email: robyn@noao.edu Tucson, AZ 85726-6732 USA From - Fri Feb 28 23:24:16 2003 X-UIDL: 3e5baf6500000061 X-Mozilla-Status: 0001 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1SMMhNb008205 for ; Fri, 28 Feb 2003 23:22:43 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h1SMMhw04057 for ; Fri, 28 Feb 2003 23:22:43 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAANSaa7h; Fri, 28 Feb 03 23:22:41 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.5/8.12.5) with ESMTP id h1SMLYle006413 for ; Fri, 28 Feb 2003 17:21:35 -0500 Message-ID: <3E5FE0AE.6090005@gsfc.nasa.gov> Date: Fri, 28 Feb 2003 17:20:30 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql Subject: version b Content-Type: multipart/mixed; boundary="------------050908080108080606090400" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------050908080108080606090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have now added constraints on dataObjects and on the classification system. So, the hierarchy that one can constrain on Object astroObject properties dataObject Tables Images Spectra class isClassOf hasSubClass isSubClassOf For some more detail see the attached png file (JPEG and GIF are much larger, but if anyone simply can't see these let me know and I will send that out). 1) One can access directly: tables, fields in tables, images or spectra by keyword, title, UCD etc. The image query can be the SIAP but I think, since the query returns into variables it should only return the URL to the images. We are not ready to do image arithmetic within VOQL variables. 2) Onc can ask questions about classification schemes, such as what are all subclasses of class X? 3) One can search for objects by ranges in their properties without reference to any type of dataObject. I think, to really make this pure, it needs a way to ask for flux measurements in an area or over a wavelength range with a certain spatial or wavelegth resolution, and to do this without mention of image or spectra or table. Within a constraint set one can ask for an objects classifications, but it takes a separate orConstraints to ask for subclasses or superclasses of the class. I believe this does all of what Patrick was asking for and all of JVOQL, except that certain built in things in JVOQL like cross-matching are here left to unspecified services. I have not yet made the metadata, voql split that Ray wants, but it looks feasible. Ed --------------050908080108080606090400 Content-Type: image/png; name="voqlb.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="voqlb.png" iVBORw0KGgoAAAANSUhEUgAAB+4AAAWWBAMAAABQspOZAAAAGFBMVEX///+AgID//8AAAADA wMD/vr7+b3D/AAD24rXlAAAgAElEQVR4nO2dTZajOLpAqUNn1bTwDnDkAjhBLKBPpBdQk+6c 1uR1TWuSldt/6AcMGIEAgSR0b0baGBvJYF9/QhJSlgEAAAAAAAAAAACcTaG53+8FyyyzbF72 7apLbncAsMG3qy7BewA7fLvqEt/HEiAWfLvqEt/HEiAWfLvqEt/HEiASSt+uusT3wQSIBLwH SA+8B0iPS3lPOx6AFdf2vtR38gl5o3otAaTNtb3vO67kv6M9wPW8L25NTG/+xF1Z3MTyrWzu 5FIhvC/upYj6zZO+Dz6AJ67mfaN4KTy/t3dNWb/oHjcxv+i9xPfBB/DE9by/t96LkC/cLjrv RYR/es+ZPiTLdb0XBfmi1Vx6f1c/BV28B0iV63n/Us6/jcr58oSfcj6kzNW8b+v17rIWT0Z1 Xc6/t/V6wnvq9SBpLue9BUXbpgeQKAl6X9zwHhInQe8BkgfvAdID7wHSA+8BEsS3qy7BewA7 fLvqErwHsMO3qy7BewA7fLvqEt/HEiAWfLvqEt/Hci9lO3nZjWWW3S1P4dtVl5xrKUAETHt/ qXa8k4+oY6idgAPA+8DBezgAvA8cvIcDSMD7uM2J+91DoOB94MT97iFQ8D5w4n73ECh4Hzhx v3sIFLwPnLjfPQQK3gfO892X7YIc9/s5KpgYDzTufYTTwfvAeb77doDv0WDfJQMDwmrwPnC6 UcDLdjI/ORC4HO1frL/JgcHFFABq9j/f7xeiAO8DR1xM0Z/uQ9zrGT/UjYr3z1lAfL9hiBe8 DwYZ77tp/YbeF1r6p/ec6cMO8D4Y1Cxfz2n9BvH+PvY+7n0Fz+B9MAxm97uX3SR+o3J+qddh PmwH74NBlfN70/rpar6uXk9N8CW8p14P9oH3wWB898PIrub0BdgD3geD8d0PNC+LO96DPQmM sxW39wAHgPcA6YH3AOmRgPfnHlCACMB7gPTAe4D0SOC6nJOPqGOonYADwPvAwXs4ALwPnIO9 D2GiNpbPWV7+Wl3K+7gj5pHvvlx+CVwEvI8LvAcX4H1c4D24AO/jAu/BBXgfF3gPLsD7uMB7 cAHexwXegwvwPi7wHlyA93GB9+ACq+8R3gfD0d4P5twSw3WrJwpG6LwWeB8X53qvHzFa3+XA +7g43HsxOndzW3bDcPdm5xFRv2QKniuA93FxivdyBj419ZaekkfNvtlO0gFpgPfBcLj3pY7x N+W+nGNv4D1n+smA98Fwgvelnm5LTq+nbgbxHq5HAuNsxe39kXT1enqavW6OPVWvV9wo518V vE+YZ31+ob0vVeWemnVLVvZRr3dJ8D5hRv12xnPpFi9r4Cok4P25BzReylF5vrjh/XWw6qeL 9wCXAu8B0iO963JOOKgHQkkbXID3cYH34AK8jwu8Bxek533c5nD9PbgA7+MC78EFeB8XeA8u wPu4uIr3tYkT30PK4H1cXMX7yvDp5Ce+h5TB+7i4jPdNaJ/6dPD+HPA+Li7jveHTwftzwPu4 uIz3dT2pfv54nPgu0gXv4+Iy3hs+Hbw/B8bVjIvLeE+89wrex8VlvDd8Onh/DngfF1fyPq/r 5n8mWu2rTFfv4/054H1cXMr7Kq+av8b8rBbL4tPB+4DA+2CI3fs33S2v9T6vtff6fB/vAwLv gyF67/V9633dxXv16eC9FxIYZytu74/Er/eU8z2C9wnjw/u2nE+9nlfwPmHO9n4KvPdCAt6f e0BhCN6HAeNow5ngfRjgPZwJ3odBetflnHBQDyT22gm8DwO8jwu8BxfgfVxcxXvj+Hp4fwrp eR+3OVfpr3e/P0yc8C4A7+MC78EFeB8XeA8uwPu4wHtwAd7HxXW8B5/gfVzgPbgA7+MC78EF eB8XeA8uwPu4wHtwAeNqxgXegwvwPi7wHlyA93GB9+ACvI8LvLfKxXjZj4n3U95XZOB9MOC9 VS6rvxV4PwHeBwPeW+WSG6bdNJK49wmMsxW390dyIe9XfyvwfooD9PMG3pu4kPe5Ho7fmo/H 5ynvLFDwPmEu5P26r0Quq/ZOeWeBkoD35x5QGBJcvJcT94iF/JR3FgqMow1nElq8z7X3Fd5P cJyF53P8MQUzJ3qvpttuAn8u/io5C6ech697ormT5QK8T+C6nBMO6oHEXjtxpvftPLuVnHNX eq/m4M26hzXxfuqhBu+DAe9nabvfiQ9a6d3E9FyGde19rSfg1QvKe1Gxh/cv4H0w4P0suhm+ H+8zeVN38b7/BPF++qHmUt7HbQ799WaZ8L6xnXL+C3gfF3g/y4v3ql5PFPVlLV4mq/PaJ9Q/ vMf74MH7Wfre20P7Pd4HDt7PstH79Prr4X1c4P0s27zP0uufj/dxgfez4L0leB8XeD8L3luC 93GB97PgvSV4Hxd4P0vr/erx9RL3fhq8Dwa8n6UbNuercbpdE5/HvrPAwPu4wPtZ8N4SvI8L vJ8F7y3B+7jA+1nw3iV4Hwx4P0viw+I6Bu+DAe9nwfttJDDOVtzeHwneJwveJwzeJwveJwze J0sC3p97QGEI3ocB42jDmeB9GOA9nAneh0F61+WccFAPJPbaiaf389fOzAtsfOWK63Lc71tM 4H1cXMf7+fnpZ0e7ezO+0v463LSG03sB7+PiMt4vqTkX8CvjK/HekvS8j9ucy/TXmw/3s16+ mV+J95bgfVxcxftlM80Bf/yT0XvlCu8fj+P2MnzwPi6u4v1SuJ8Z3Pqte8HrK229t6g7vDZ4 HxeX8j4ffzZ5b51xMgstdZ6LuS1Hr3zxXkyU06P9qZAr8d70UIP3wYD3rdSViPf56JUv3ted 6vqh3lhshPemhxq8D4YLeV9XuZiotpILeSOiXJGrNYve589bg/d5O+1lN0WeKB+oIgLezz7U 4H0wXMf7xvTGcnErF9p7vWbR+ypbive1nAk3y54z3+ppcDO8x/vIiN573VtOeS+CvKiWExPS yjnqm3UyKGfy/L2u86medrJaTsTzXKf0+krxQctEXrxX5/uV2BDvTQ81eB8M0Xuv7zvvm/N0 NRF1G/Jl9F4u52fL8T6b8F5X9BHvbV6E98FwLe+7cr6QN5elcNtyvmKpnN8W7Snnj8D7uLiO 94N6PSlvna+o11uO93kb3nW9nqgRoF5Pg/dxcSHvF7Dwfqb9vq4NySpov7d5Ed4HQ0Le7+qv l897n3x/PSvwPhiu4v1yD/oPYwf68W9G9ZzN1jbeJ98/3wq8D4areL98Pd7DKOb4erzs1fu8 fukL+Jr+sXsaFQmMsxW390dyqvdLAf/D7P3oN6Oa8n7xPALv++B9wpw7jvbCeDuPGe+H4+3I F3+qZ7gOdxt4nzDnej8/Bt7H7EyV/VfKcD/23mJ8PbzvkYD35x5QGNIbT3dxhtqZVNRHqc/h 88fYe7v5cA/axShgHG04k573S2p+ziSjTxLUXa9sgPeW4D2cSX/8/B1avg1L7N2L8d6S9K7L OeGgHkjstRN97+fd/JxNR7/o4/ExeDHeW4L3cXEl7/egvf72bagwXfAswfu4uLD3pdi3UjYq DFsWyqnd7gL+oGyA95ak533c5lymv16TXTF8Su6atfdfJ0vseG8J3sfFhby/jXZmnffT4L0l eB8X1/Fe5Ha7FfdbKQN/cS9uTVFfeN/cikfiQfPbIB/dyvGOTxuO95bgfVxcyfviVpSN+o3q jfHNglgpvJdrhPH6Z0A8uo3e3Bve7wLv4+JK3gvnh96XRed987PQ/Co0S6X8cShGlQHv0vC3 99FF9HhvCd7HxXW8F+f3Y+9vz3gvHkvvVfR/2W9p+Pvb+9vrWlgG7+PiQt6XRWNzIeK5Or/v 4n17fl/ICj35/G1c+d96f5/03ua6nBEH7nOI4H1cXMj7ffnOxnuL63BHpDYtNt7HBd5rZs/v 8X4JxtWMiyt6v4n3JqnXs3m8twTv4yIB7+WZ/Mb93O59Ypfp4H1cXNb7bsfK9uGWXcV7S/A+ Li7qfTlevL0+YcOL93oezJa6N8D24InUvLcC74PhOt6L1rmb7J3bLBQ31R9XteHddTfd5qmy eWpF8i/eq7l1nw/1/HiZmjLzCd5PgPfBcCHv789uuu2C6rMjO/HoNeW6Pe57n6vJMLN2fjzx J1aISfmaB2quPD0yZ+reJzDOVtzeH8np3mu5C7lQyJ47fe9lR91176rvvZgP92UebDlPpn6s n1ATZuP9BJ5VdQrem/DlvbBddc8fxXtl/ZoPrO19Jz5oqfPYexH5hfe1WN2EeryX4H3CnH9+ r66+Ff11bzfVX7eUF97J1bK37n3d+X2bi/igp73PVCmg1mf6eC9JwPtzDygMGV5/f5+L5jt+ oLtyfqYL9M9yvijdd6vTLeczjjacib33e0ofXb2ebMfT9XqVmDBbPVCrZb0e3k88bPGsqlOO P6Zgxlk/3flcZufBnpo0E+8nuFQ73gkH9UBir504y/vc7P3kU3g/Ad4HA95b5TIb76fA+wnw Phjw3iqXvM7XfSvwfoJLeR+3Odfpr3doLlOn8LPg/QR4Hwx4b5XL6m8F3k+A98GA91a5rB9f D+9fwftgwHs7bObDTXl6XLyPC7y3A+/nwfu4wHs78H4evI8LvLcD7+fB+7jAe3AB3scF3oML GFczLvAeXID3cYH34AK8jwu8BxfgfVzgPZwG3gcD3sNp4H0w4D0cQALjbMXt/ZHg/dEULQct bwbvEwbvY2bXp4f3CYP3h3Lw4cX7efYcHtgL3oeRPONow5ngfRjJ4z2cCd6HkXx61+VsPa5h EHvtBN6HkTzexwXeR8sZ1abW4H1c4H204L1X4jaH/nrRgvdewXsTeH8oz8Mru9bdyt5nKZbl 2p397qzB+7jA+2gZel8OPsnno3O0x/vIwPtoEYe3iebi717ciqK8lUXzV9z1XSFuxHPNCrX2 wDeD93GB99EivW8ie3krynsh74d34ka+ol27Onl78D4u8D5atPdFIZQeCN/+Ggy9X3mmj/fz 4L0JvD+UNt7fhe1979tfgXG8X5+8PXgfF3gfLf1y/m2mnN+c/FPOdw/em8D7Q1He63o95boy XN+19Xr3rrZvdfL2MK5mXOB9tCwe3rYxrxg18jlKfgDexwXeR4ut902cx3v34L0JvI8ZvJ8H 703gfcwc8OnhfTDgPUyD9/PgvQm8jxnG1Zwnbu+PBO9jBu/nwXsTeB8zeD8P3pvA+0MJany9 EQl4v+fwwF7wPozkGUcbzuQ63tdrEBuUL5u9b0vvfeLd4P0Sqw4POOY63lcrvnO52ECK+fay en16p3l/qXa8VYcnOGKvnUjd++FW75vSw/strDo8wYH3obDJ+7eJ9avTU6cN+8D7uMD7UFjl /eOhvB9v9L4lvSo3vilr0vM+bnPorxcKa+KzrIwrX8J984PQ1frZptfbYg94Hxd4HwrC01ze 1OKvJX/6W1fqCbnG4L286dLrr9Up1L0kq+EWe8D7uMD7UOg8NXmfV3Um16/2vk2tS6GXdC7S yx973z3exwXeh4KK93kt/urGz1qW55tH4mdArhRlcvGqFd6LAF8/ExTmN2mJ1DK5Eu83g/cm 8H4NyvtGTqlp46YMzu1CXilrxTdu7L34VcjkL8LY+7zbPlP3Oi11Mx/vacebB+9N4L0Nb7rX nPZeuFk1TtZ1z/t66L14tdpIV/J1SeSimi7v0lPBPnv1XiaovJdb4P1q8N4E3tvQ7oGu1xNG 1ioW9+J9tjHey5ODqXifdd4T77eB9ybw3oah90rLaqqcv6FeL68G5fwuScr5+8F7E3hvw9D7 XFa7ZboaTp7tq3q9qm2FW1evJxOSAV6eFIjyRFevl83W6zGu5jx4bwLvbeh7b8fqdrzxi/pP qS3wfjV4bwLvbVjv/d7+enX/gdoC71eD9ybw3ob13uv++VMbfTw6g9f0z3/g/Wrw3gTe27DL +/H1eA9f3luB98GA977Z5f1oqw+8Pw28N4H3Nuzz/m20OhDvExhnK27vjwTvbWj3wH48PFEP 14naXyvC/efUE/Pg/Rbw3gTe2/Dcg8ca2o2+GtZPVPa/0BYJ8H4DeG8C723Y7H05tdVnL+HF r257XT7eb2DP4YG94P3X0epnwltOG54wjvY8qw4POAbvB5t9DpL+ati245v8G/1eaPB+nlWH BxxzJe9XsizmovePj8fHid5fqh1v1eEJjthrJ/B+hmXvv33rig/rk++D93GB977x6n0b7hln azV7j5hf8N43B3p/Iul5H7c59NfzDd7HCd6bwHsbPHk/PSneZvA+LvDeN368f8P7neC9Cby3 wY/379L7t/fakf94Hxd47xuf5fz3t3dj9rTjzYP3JvDeBr/em7PH+3nw3gTe20C8jxO8N4H3 Nvj0fu78Hu/nwXsTeG+DN+/f5tvyGFdzHrw3gfc2hNpvB+/nwXsTeG8D3scJ3pvAextC3QO8 nwfvTeC9DaHuAeNoz4P3JvDehlD3AO/nwXsTeG9DqHvAuJrzxO39keC9DaHuAd7Pg/cm8N6G UPcA7+fBexN4b8M12vFGJOD9nsMDe8H7o2Ac7Xk2HlZwAt4fBd7Ps/GwghNS9r5QNItFccDy qjeT3nU5az+usIi9diJh74MC7+MC730T/x4I8D4u8N438e+BID3v4zaH/nq+iX8PBHgfF3jv m/j3QID3cYH3vol/DwR4Hxd475v490CA93GB976Jfw8EeB8XeO+b+PdAgPdxgfe+iX8PBHgf F3jvm/j3QID3cYH3vol/DwSMqxkXeO+bHXtwyOU4veUV4H1c4L1vAt2DlR8e3scF3vtm6x4E dfk93kcG3vvmGt7bpenbVZfgvQm8twHv4wTvTeC9DZf0PoFxtuL2/kjw3ga8jxO8N4H3NgTq /T7wPmHw3ga8j5NzDygMwfswYBxtOBO81yNe38qea2JZrl3d724reA9ngvfK8HJg2vPRSdon eF3OCQf1QGKvnUjb+yaai797cSuK8lYWzV9x13eFuBHPyQk2xFqX73oM3scF3vtml/dNZC9v RXkv5P3wTtzIV7RrVye/AryPC7z3zU7vi0IoPRC+/TUYer/yTB/vF4jbHPrr+WZvvL8L2/ve t78C43i/PvkV4H1c4L1vXJTzbzPl/Obkn3L+AeC9Cby3YZ/3ul5Pua4M13dtvd69q+1bnfwK 8D4u8N43h/XbaRvzilEjn6Pkh+B9XOC9b472vonzeH8AeG8C720IdA/wfgG8N4H3NgS6B3i/ AN6bwHsbAt0DvF8A703gvQ2B7gHjai6A9ybw3oZA9wDvF8B7E3hvQ6B7gPcL4L0JvLch0HE3 8H4BvDeB9zZcw3u7NH276hK8N4H3NrR7UK9AvL582eq9n6x9Yu/3KfB+Abw3gfc2tHtQ2X/l cvF6eXTfXlbfVyd3hPcJjLMVt/dHgvc27PJ+uFHfYLw/GLw3gfc27PH+bWL96uTUaYNb8D5h 8N6GLd4/HurojrfphW775Kp86m3tIwHv3R80sCdB73VlXPkS7psfhK7Wzza53ha7YBxtOJNr eZ93tua1+Ose9S2Wywbv5U2XXH+toK6yupdYNdxiF3gPZ4L3faa9b9PJqzqrey/W3lfNecPu vUjvupzdh8wrsddOXMz7ulbGV81fsyz/avGoXZmt8l4E+PqZlDC/SUWmI1fi/XZ2HzKv4L1v hvE+ryoZlqWsuVrO2gUV9sfei9+DTP4ijL3Puy0zda9TUTfz8Z7rcBdYd3xCA+9986a7zbXe q/Dc+N+Y2ax9el+33osXq210JV+XQi6q6fIuORXss1fvZVLKe7kF3q8nbnPor+ebcbwXSgov axWRe/E+Wx3vK3l6MBHvs8574v1G8N4E3tsw4b2Ss7Is5/d49b5fzu8So5zvALw3gfc2jL1X 9XfNfaYr4+TZvqrXW+m9qheUUT6TJwWiJNHV62Wz9Xp4vwDem8B7G1b321ndjjd+Uf8ptQXe rwfvTeC9Daf316v7D9QWeL8evDeB9zZs7Z8/tc3HozN4Tf/8B96vB+9N4L0Ne7wfX4/3wPvT wHsTeG/DHu9HG33g/XngvQm8t2GX92+j1aF4Pw3eBwPe+2bL+HpPUftrRbj/nHpiHrzfBN6b wHsbnnvwWEG7zVfD+onK/hfaIgHebwHvTeC9DVu9L6c2+uylu/jNba/Lx/st4L0JvLdhp/df R6uf6W45bXjCONoL4L0JvLdhp/eDrT4HKX81bNvxTf6Nfi80eL8A3pvAexuOmy9n0fvHx+Pj GO8TGGcrbu+PBO9t8On9t29d8WF98nPgfcLgvQ0+vW/D/f5xtkbgfcLgvQ2Bzou5jwS8P/eA whC8DwPG0YYzwfttTE+Ktx28hzPB+22ZevH+Uu14jg/gycReO4H3m3iX3r+91678x/u4wHvf eCznv7+9G3PnOtwF1h2f0MB733j13pw73i8Qtzn01/MN8T5O8N4E3tvg0fu583u8XwDvTeC9 Db68f5tvy8P7BfDeBN7bEGi/HbxfAO9N4L0NeB8neG8C720IdA/wfgG8N4H3NgS6B3i/AN6b wHsbAt0DvF8A703gvQ2B7gHjai6A9ybw3oZA9wDvF8B7E3hvQ6B7gPcL4L0JvLfhku14hjR9 u+oSvDeB9zZcw3u7NH276hK8N4H3NuB9nOC9Cby3YbP3haJZLIoDlnftVALjbMXt/ZHgvQ3x 78EEeJ8weG9D/HswAd4nDN7bEP8eTJCA9+ceUBgSvzXx74GAcbThTOK3Jv49EOA9nEn81sS/ B4L0rss54aAeSOy1E/FbE/8eCPA+LvDeN/HvgQDv4wLvfRP/HgjS8z5uc+iv55v490CA93GB 976Jfw8EeB8XeO+b+PdAgPdxgfe+cbEHh1yY01teBu/jAu99E/oe2H2KeB8XeO+b3XsQxIX4 eB8XeO8bvI8TvDeB9zbgfZzgvQm8t+GS3huS8u2qS/DeBN7bgPdxgvcm8N6G0L23A+/jAu99 g/dxgvcm8N6Ga3hvBd4HA977xqH3smvdrex9pmJZrrXtd3coeB8MeO8bx96Xg0/0+ehc7RMY Zytu748E721w4n0TzcXfvbgVRXkri+avuOu7QtyI5+RUG2Ktg3e9AN4nDN7b4Mb7JrKXt6K8 F/J+eCdu5CvatauTXw3eJwze2+DK+6IQSg+Eb38Nht6vPNPH+2m2HBZwBd538f4ubO973/4K jOP9+uSXYRxtOBO8H5TzbzPl/Obk/7hyPt7DmeC99l7X6ynXleH6rq3Xu3e1fauTXya963JW HcTgiL12Au+XxWwb84pRI5+j5CV4Hxd475vTvG/iPN67Y/2RDAm8903oe4D308RtDv31fBP6 HuD9NHhvAu9tCH0P8H4avDeB9zaEvgd4Pw3em8B7G0LfA7yfBu9N4L0Noe8B3k+D9ybw3obQ x93A+2nw3gTe24D3cYL3JvDehnYP6i2IDcuXzd/76dsn9n6fAu+nwXsTeG9DuwfVhu9eLjaU h/ntZfV9dboOvZ8G74MB733jxvvh1n2D8f4Y8N4E3tvgxPu3ifWr01WnDdvA+7jAe9/s8v7x UId5vHEvdNunW+VT788OvI8LvPfNdu91ZVz5Eu6bH4Su1s823d4Wh4H3wYD3vul7n3eSNhpO fdnalbm4kS82eC9vunT7a2UylUipy60abnEYeB8MeO8bg/dVPhWo6/79au+7X42qzno/K7n2 vmrOGxztVALjbMXt/ZHgvQ0D75son4u/Snifi7DcrZBLja9iSTyzynuZUrOVSEA435hftzlU smiB9yvBexN4b8Mw3udVJaNx3rsbrGiXslfvxU9CJn8Rxt53W9WZutdJqpv5eM842tPgvQm8 t+FN95ZrvVdRWeqpAnsta/Bab+ue92IrtbGu5OuSynO5cZtu1qY09l6kpsv5cgu8t2bLYQFX XMB7fd96L0x8yi1+BTJVCfcMz+vjfVWrlF7ifdZ5vy/eM442nMklvZ8r58943+PV+345X5cc XJbz8R7O5Hreyzo8XY3Xr9eTT7Xl/HxtvZ6sz5O/F/KkQCTc1etls/V6XJczje3nGyax105c y/t1rG7HG7+o/5TaAu+tsf18wwTvfeOvv96gZ5DaAu+tsf18wwTvfbO7f/7Uxh+PzuA1/fMf eG9N3ObQX883TrwfX4/3wPujwXsTeG+DE+9HW3/g/eHgvQm8t8GN92+j1Xh/NHhvAu9t2DW+ 3lPU/loR7j+nnpgH79eA9ybw3obnHjy20G781bB+orL/hbZIgPcrwHsTeG/Dbu/Lqa0/exks foXb6/LxfgV4bwLvbXDl/dfR6mcGW04bnuD9NHhvAu9tcOX9YPPPQRZfDdt2fJN/o98LDd5P g/cm8N6GE+bLWfT+8fH4cOq94Z36dtUleG8C720Iwvtv37riw/rkBXgfF3jvmyC8b8P95nG2 8D4u8N43oc+LaQfexwXe++Ya3luB98GA977x7P30pHjHgPfBgPe+8ev92zHeJzDOVtzeHwne 2+DX+3fp/dt77dZ/vE8YvLchhHL++9u78W0wjvY0eG8C720Iw3vz28D7abYcFnAF3ocR7xlH G84E7114P3d+j/fTWB5fOAS83+3923xbHtflTGN3eEMl9toJvD+6GgXvp9l7XP2C977B+zjZ e1z9gve+CX0P8H6auM2hv55vQt8DvJ8G703gvQ2h7wHeT4P3JvDehtD3AO+nwXsTeG9D6HuA 99PgvYmLeT81Lq391SyDrQdPOH+jbsH7afDexMW8n5pwKt+2df/ngna8OMF7E9fyfnr6CduA P9y6/3OB93GC9yau5f30/JK2AX+0de/nAu/jBO9NXMp702xTdgF/vHXv52K/94WiWSyKA5at 3gTjasYF3ltimk46f6mom9u67ha6WsHQ6/XswPu4wHtLpLDtBJLtQq6XFkv7WveqrmqlvrzB +4jBexMX9l6z0vtcxnu8vwQpeG8/o2q/hbqc3XbVQI7+W7+rLM8r8SftlQaLu1Xe926v5r0V eB8Mdu/edHZaf8MAACAASURBVHJrRIogvTfOvm7f9D1+A05bv+3fgdK+8V786btV3ufZdeO9 FXgfDId7b950RcA/sPV7MWtdyGi8l6pnVRPopfFZXQvvRcVevlT8qUT9XyW8lw/FmX6tlxfr BGMkgXG24vbeju3eG8P9qoB/YOv3Em0Gfe+zSkX6lfE+Syfe4/0lWO+9mFm1XNjSOuAf2fq9 mLe+V+X8TP9Thfx6tfcCvL8EeP+CrrcrZ8O9bdP33W/rd897Vaknz9JVvR7x3kQC3p97QP0w 8F6czb4chSrvvab3pX49XtWwEdymtO+z9btfzn++6ydrvU+j/R7vL8HI+4HkkuGKee+fG8kb 6+z9tH6/eD/adfrrSfD+ishva1O6bQJ981943yzJv0rdyZXqQTbyvqqzqnlO3MvbWrd9r/be T+t3m4HpjOVD1GQspzLaKlc1IP0M4ia963JOOKgHYt+Ol6tAX7d3pgfZyHtpfKX0l7e67Xut 955av7sMDNfjPay8H29dOfL+kAtxesvW4H1czHv/bLzOZHO1tluE+Oz5oPVetGMrLZ+N0+Ir LnxX0tfiNlfb2zZ9e2797rScDvgflt6PeiBkEcT7Vd2s8T4uFrzX9zLeV894n/W87z0QZ7sv 8b7nvQzXsu1bvmZtvZ7feD893s7D0vvh1lXv/GD7HgRx4b0mPe/jbsdz4L2xnF+25fzqWc6v NpfzNf68nxpfT4T7T7t0+pv1zw/wPk5S8V6X82W9nrC5X6+nKvnH9XplV6+XPev1ss31er7j /f0xjWVCbWOkuvvA+8hJxvsJXtvxJUPv+ysHbPDeX/t9w9dJ7T9tE+rtdP/8AO/jBO9fV/f7 6814H1N/PcGecD+8ILl3foD3cZKy90as+ufbNX3f/bZ+9zOYCvif1inprb81//o/GMF6vwq8 j4ujvZ+7Hm/1uXGLq9ZvGxxmoH8pPj4GPxh4Hyd4P0Hn/cymtk3fd6+t3zMZlOLglXIvBwqa fOwC/uD8AO/jBO8neHpvHm9nzcnxAa3flvQyKEc92OSxG3p/6z94YfL8wIX38o3dyt6HKZbl 2pX97raC93Fh571Fn7oRnffGbe2bvu+HtH7b5vxcvI2O1oT395cHazJYydD7cvDmno9O0Z5x NSPDzntj2/UM7fdyqjLs+Rpb3Ld+W/LMQOzO7VY0cbVU80kUt0Yv4X1xa9Y0vwrFrYm5zb/F pJbX2iDyaaK5+GveQlE0OYt3Utz1XSFuxHNyag2xdnNWi+B9XBzv/cymn/bv033rt23G3VIp 5Cob9RvVG+ObBbFSeC/XyLViXWnyfrrJcqf34qdHvK1C3g/vxI18Rbt2dfLW4H1cnOD915mX 2OO89duSQbxvnB96XxZ97+W6ZpUhJZVU/Tb0f7f3RSGUHgjf/hoMvV95po/3s+D9gvfGbT/X vFH96+Gu9duS4fn92PvbIN43q25qwZzUWxP231/WbqKN93dhe9/79ldgHO/XJ+8WvA8GW++3 4PaLo38snLV+WzKoz79JjQp9ft/F++Imy/h3dX5vivet9++uvZdez5Tzxfs7upxvl6JvV12C 9yYMXxzV6HRbzn1IF/AHpwhe2u/HO3br3S4l5Tze63o95boyXN+19Xr3rrZvdfJbSWCcrbi9 n8eJ96Ovm1rbeW84fBOrJ08RwvF+WZMjzu/nX6CPYjFq5HOU/Ax4HzUuvC9HX6CR971149fY EFM/3Sap99fkjvdetjcekPwMeB81LryXLVuiUfsmAr8ohMpz45tqAVenoKWoBpeN44U4IdUN 4cPTUdet35YMM5jun7PrTPga42yNSMD7HUcneFx8J0VFl6oDv+mq77uq+C6f1eOl+JY9G8fb hQGuW78tmfC+fD643fsrBKvrLa7hPeNoXwkn3t/bXi1P74ue90XReq9/BQq9evjlcd76bcmr 97f+A8noW35WP92DwftZth7WGHDxnSxfvS8H8f4+8l68SHWKeX0vDmvDLen125FnK6LeXJ2h iOa8m+qiW6pHov5MnrmosxS7+vOEvL9UO97m4xoER7bjaWRAF43b+vz+ruO96uEuBbmr83u1 RrSS3266lXz0Xhy2flvS817/KOnfMNU9T626y0fy10oVb9RrVmYQGHg/y+bjGgQneD+f16hK 3/x+/Md7+QtWdHUVN+X9Xf123XQpRfbbUa+xEwfv42TzcQ0C396P68QXvPd5fl8OYrk6fZH3 6pF63CsOjC/bXcxgLYyv55O42/Hi6afruvXbPltNKS+5KYTS6mJc4bc8z5ddd7vze9Eg2bVb rslgLXjvE7w3ccY4UL777chrcZ1ksG5ck3uXb3/t4BTIPrH3+xR4Pwvem0jFezcZrBrLTM46 8DqO2WAyAvsE8X4DeG8iBe/dZbDR++FmfYPx/lDw3sTFvJ/end07uc/7t4n1qxN0MKsw3scF 3ltnYPTezfn9Ou9N85L0Qrd9glU+9cZWgfdxgffWGbwOnDtYsfV7sMF7XRlXToxS3pt7zDJB 69nKZsH7uMB76wxKNbaN7LGjuxaqywsLPZbVthGr+97nT1fz8dyD+XNxMO/oxKvyLsHxtmIm 4l42VbZidtJZ8D4u8N46g2c3vOHlhbpPrmX3PGMGS973Hq/2vt02r+p+Orn2Xsw7tvMwMa5m XOC9dQb62sFbQ3Nf9L2XlxRsLOkPvK9rIXwuwnJe9R/Vza36y1Z5327bJCX+hPlNKjIduRLv t4L3Jq7nvbx28CYvI5JXDfZG0lXrdmSg4n1eVSooC+/FonyUP1eKr9zYe/F7oCcJH3mfP7dV 9zo5dTMf7xlHexa8N3E17wt50aDsil/cVbyX5/elGjdo6/m97jTXeq+Cc+e9rMWT4bnnvXh5 O2dYv+NdI3AuX94mmD23HXpfi6SU93ILvF8L3pu4mPdG3LXj6QifKXVb78UT9cZ4X9XttqN4 n3XeO4n3VuB9MOD9/gz2fQMmvFeC19bl/B6v3vfL+V0qzsv5VuB9MOB9KBn0yvniT3vf1etl uV6dravXq9W28oRAV/N19XrZbL0e42rOErf38+B9kP3zV7fjjV/Uf0ptgfdrwXsTeL8mgxP7 6w26Bqgt8H4teG8C79dksL5//tRWH88pxNb0z5+amxjvZ9lxdIIn2LHfOlL3fnw93sOT94yj fSXwPnTvR5t94P1ZrDk6sYH3wXv/NlodsveXasdbc3TC48zxdI/gOt7bD4cn6+E6UftrP/pT BdsnhvcbWHN0wgPvw8ngsYp2q6+G9ROV/S+0RQK8X8+aoxMeeB9OBmu9L6c2++ylvPjdba/L x/v1xN2OR3+9cDLY6P3X0epnyltOG57g/Sx4bwLv12Ww0fvBdp+DtL8atu34Jv9GvxcavJ8F 703g/bEZLB/fRe8fH48PvN8E3pvA+2MzcOH9t29d8WF98j3wPi7wPt4MXHjfhnvH42zhfeDg fbwZnHF8bcH7uMD7eDPAe5/gvQm8PzaDfcd3elK8reB9XOB9vBnsOr5vh3o/Dd4HA97Hm8Gu 4/suvX97r934j/dxgffxZuCgnP/+9m7Mn3G0Z8F7E3h/bAZOvDfnj/ez4L0JvD82g5DivRV4 Hwx4H28GDryfO7/H+1nw3gTeH5vBXu/f5tvyGFdzlri9nwfvQ87g4OOL97PgvQm8PzYDvPcJ 3pvA+yAy2Arez7Lj6ARPsN/Jjvi1DPYYM472LFsPawwE+53siF/LYI8x3s+y9bDGQLDfyY74 tQz2GDPuxiybj2sQMJ7u5TPYCt7Psvm4BgHeXz6DreD9LJuPaxDgfbwZhNSOl573cbfj0V8v 3gzw3id4bwLvj80A732C9ybw/tgMykLRLBbFActr3gvexwXeXz6DU8D7uMD7y2dwCngfF3h/ +QxOAe/jAu8vn8Ep4H1c4P3lMzgFvI8LvL98BqfAuJpxgfeXz+AU8D4u8P7yGZwC3scF3l8+ g1PA+7jA+8tnEA54Hwx4f/kMwgHvgwHvL5+BDxIYZytu7+fB+xgyaK/PKW7HLG8A76MG7y+Q wT7w3gDem8D7MzI4+PuH9wZ2HNPgCTwW3SPQ8vAMwvCecbSvBN6HnwHe+2HfYQ0bvA8/g4i8 v1Q73s7j6hnG0409A7z3w87j6hm8jz2DMOqV8T4u8D72DPDeD2Ec963QXy/2DML4/uF9XOB9 7Bl0n2AplsrB8NdFu3Zrv7v172LyoQbvgwHvY89g6P1w0Pti8NyR4H1c4H3sGcjO9Dfx19w0 d8W9EH83fVfexHLznFih1h4B3scF3seewU1G88bx8iYkF/fDu+ZGvqJbuzb5DS/D+8DB+9gz 0N4XQumiL3yhfw2G3q8908d7A3hvAu/PyKCN981t0Q/09/ZXYBTv1ye/4WV4Hzh4H3sGvXJ+ MVfOL4s75XyH4L0JvD8jA+W9rtdTrkvD9V1brye931Cvt837afA+GPA+9gwWv39adHUy4D75 FS/D+2DA+9gzsPS+Cfd47xK8N4H3QWSwD7w3gPcm8D6IDPbh8uuN98GA95fPYB94bwDvTeB9 EBnsg3E1DcTt/Tx4f4EM9oH3BvDeBN4HkcE+8N4A3pvA+zMyCGN8PbutfLvqkh3HNHgCj0X3 CLQ8PIMwvGcc7SuB9+dlUK/nXWwnFXvrrx6kbp/a9NvDewN2xyVO8P68DKr1X72n99XL6jZ1 68Ty6bfHdTkG7I5LqDCebigZ7PF+aHffYLw/CrvjEip4H0oGe7yvJtbr1K0Ty+v31zdnDd7H Bd6HksEG7z8en/ITHMvdC90rvM/wfg1xt+PRXy+UDNZ6n+vKuNvEps9aP1vvn1tsA+/jAu9D yUDIm8ubum6/W3V3nzerq1ysyLXlubyZ9l6uePG+fVley0TaxPPhFtvA+7jA+1Ay6OTNq3ws cp3VYmXduZpt8L5LtR7mUKstmvQ+PjfvBd7HxXW8X2ipXkrH2AB+xLueykDFexHVK3nXFL2r RnTx16xolnOxQi7X8rXiy2fnvQjwYluRuPoBEWUKmXguVmZ4vx68N3Gu9wvnxwtlWHMD+DHv +zUD5X2tonF71y1XYlm6qu5evc9loUAVCEbePxNUCfQTF09lM97TjmcA702c6v1SBZaheXpy 60ED+FHvvMtAFzK097U8v28eL3ovKvZyvWneL640FteybKAeZCrYZ6/eyxKFLueLLfB+BXhv 4lTvF6vDZwP+TAP4ce99mIGu16tbsQfey1L65nhf63Rf4r2Unni/Cbw3cab3y+1VcwF/rgH8 yHffz2CunJ+paD3rfZ9X73vlfLVEOX8neG/iTO8tWr9nmqi7mu7q5bU+6vVkgH/W63Xea31X e6/q82Skz+VJQdar11P1/I69nwbvg+Fi3ufy/9OD6tlqPddErV9T1bquvC/OyXvQkWcvzXmj 57OV7fcj6v4DuQXerwDvTXjz/kk1Xp7zPpfxPhTvs7oerxmwt7/e8FdFboH3K8B7E+d6nwtt xf+6EtVbqgzblImrSi5ZeN+7DcH7ZWT//PtE9cRDP7Guf/5Ht1UPvDeA9yZO9r6RPs/F/0b1 9k9pL5aWvc+zsOL9Mp2o1Xj96d5bgffBEL33Xeu36MFe56K9qpU+F7pXemnQqD1GNoCLVq3q tQH88D3Q93u8H3U/eOD98eC9iZPjvQjYg3gva/gqvWRTrxdtvB9u/OHf+wTG2Yrb+3li816U 8+t+Ob9aUc7X+PJ+/vKCSZ6iDi4vaLR/3KeemAfvV4H3Js72XtXr5bms1xOl+1rFe9t6Pb/x /n5/rOfTsO3nM/3FckTX/oH3a8B7E4H026n690ve+2u/3+q9+v59Ha6f2LflA4T3a9h0XCIh nnG2LLyXhdlw++vt8/4+Xt2x5bShh8t+ungfCfF4b9E//zH1tZ7eOhevHmZw+B7s9H4Q8Ic5 LKbyIf8ekwcI7w3YHZc4icf75eLsx4z3460rL95vY1nMRe+/Nf/O8P5S7Xh2xyVUjmzHOwP7 6++nv9aTW+dZWt4/Pj7wfi12xyVULuP9UsD/mP5aT25dyZePMziIELzX4X7uAK17F3gfONfx fqGlWnyt59IZtGTL0sE4g4M43vszSM/7MI77Vq7SX+9uEdY+5xJqL8VVdx94vw68j4sLef91 yfv5hNSnqTqx5M+XX9t7Z3uH93FxIe+XAv7nfErDluzu5df23tlVR3gfF1fyfiHgL6Skt+7a tCYyOASf3r+pzOu33f7jfVxcyfud6J+Hj2EXlkt7rzJ/a8K+cbRh2vEM4L0Jz96XYt9K/SYG +zm9013AH5QOkvD+He9Xg/cmTva+LIZPyV0beH/rnpl8a5OVAUl4T7xfD96bONn722hnxt6X w2fWZ3AM/r2fPb/HewN4b+Jc70Vut1txv5Uy8Bf3ognrN+G9Wtv8EzdifSFfU9xMSS2vdYhv 79/n3wDjahrAexNne98IXTaSN6qLgvxNnd43b0KuFZFfPXcTPw36+T7TMe/a3jtLHu/j4kre C6+H3peFjPdl0aztfhNK7f3o7RnatPDe3cvwPhiu4704vx97LwWXhutQL5+7Ke/H+z5dxxW8 9weD9wbw3sTp9fmN6oWI8er8/hnv7zLe3+X5/f1WSO8N5/cvbVp47w68D4YLeb8q34nXEO+n wHsDeG8iRu/jO78/GMbVNBC39/PE6f32pCbatPDe4Va+XXUJ3ps4v/3+gPeA9w638u2qS/De RCDe73sbwXsfRjue3Va+XXXJjmMaPIHHovuL9y+Odyu26oH3W16G91ETlffFXfXFFX1yVTfd u+qXKxr3bsX4sp3VGRwE3sfJvsMaNlF5/+yOp/voyH47965v7t4MDmJvBoVC9lY4YJnrcgzs /Ng8c2Q73hkMvC9kX9ybuC/63osOPS/d81ZncBDhH2Mb8D4uLuW96J5biovv7m3vXB3vpfXl JvPx3gq8j4sLeS+66Arby7vshCu8l+f34kK9Ul55i/eHkZ73cbfjXbG/3oiLt+OFAd7HRQLe 7/uA8N4KvI+LBLxPPYNTwPu4wPvLZ3AKeB8XeH/5DE4B7+MC7y+fwSngfVzg/eUzOAW8jwu8 v3wGp4D3cYH3l8/gFBhXMy7wPv4MDrkep7dsA97HBd5fPoN94L0BvDeB92dkEOT199PgfTDg fewZhOG9FXgfDHgfewZ47we8N4H3Z2QQpPcJjLMVt/fz4H34GeC9H/DeBN6fkUGQ3z+8jxq8 Dz+DIL9/CXh/7gE9l8Dblu8RaHl4BmF4zzjaVwLvw8+gU0wOeV3e+9MEFO1a6353u9/F5MMW 36665Njj6Re8Dz+DoffDyUGKwXNHkt51OQcf0IO5zni6qWYgO9PfSjlmsJg3oLgX4u+m78qb WC7lHEJ67RHgfVzgfewZqEltGsfFHGE3eT+8U/OE6SX5A7Ay+Q0vw/vAwfvYM9DeF0Lpoi98 oX8Nht6vPdPHewNh1Kduhf56sWfQxns592fP+3v7KzCK9+uT3/AyvA8cvI89g145v5gr56uZ gSnnuwLvTeD9GRko73W9nnJdzf1daNFVvZ70fkO9Ht4bwHsTeH9GBovfPy26Ohlwn/zky/A+ cPA+9gwsvW/CPd67BO9N4H0QGewD7w3gvQm8DyKDfeC9Abw3gfdBZLAPvDeA9ybwPogM9sG4 mgbw3gTeB5HBPvDeAN6bwPsgMtgH3hvAexN4f0YGYYyvh/dxgfexZxCG91bgfTDgfSgZ1Ot5 F9vJT/Ctv3qQun1q028P7w3gvQm8X5NBtf6r9/S+elndpm6dWD799hhH20Bg3q+MFhJztNj1 VvB+TQZ7vB/a3TcY748iMO/tvz7v09sMosWut4L3azLY4301sV6nbp1YXr+/vrmt4P3ZbPB+ Jlrseit4vyaDDd5/PD6lYmO5ex/hCu8zvF+Du4PlhA3ez0QLH3uwinS9z/VZ2W1i0+d5nK33 ozO/1TCOtmfsvz4yWtzno4WffVjBtbzPu0+vsbpdrLv7vFld5XpFrj+rKe/lihfv25fltcyo TTcfbrENvPeMpff5sw6v3aLuFp7Rwuuu2HBZ76t8/EnWzSfUrKy3et8lWA8Tr9UWTXofn5v3 Ir3rcjYfqmPofaB5u1CLb8vzc6+yqW9NVVe1Ur/3rfG9N4tczPsmyotoLARv/onPrflUmhtx n4tPKK/bj2mF9yrJuhbpqt8OkZFMNxcrM7xfz+ZDdQzjH/JMCF93y5n2/+Vbk8t4j/feMlDx Pq8q+XHlvbtuuRLLtY74408wl+UB9TmPvH+mlcn7frriqWzGe67DNWD58Z6F/MhloJA/8TJW CPPrNoBU9dS3Juvd4v2pGeh+E6336mOTAbme9V6cquV607zfA0OU3WSxQD3IMp3ki/eyMKHL +WILvF9BgO14eRcvMnWvvzfqZjLe55n7eE873hpa76WX2u9s4L0sqm+J922SL/FeSk+830Qg 3vfDhgr22av34sPX5fxRtBBfgeo1Wux6S3i/hp730+X87tOc9r7Pq/e9cr5aopy/k1C81/fq 66Mqcl7jfdZ5L9768FtDvPeSQUuvnN9VvvXq9Trv29qaVfV66hRPfPjyZz7r1eup7wPeryVM 7/vlfB0jZsv5Grw/PYOWyQbYPHtpzns+NfkJPj/GpX47df+B3ALvVxCg96rhR0Z5ca+q+bp6 PVO0IN57yaBl2u+6nlyd7e+vN/xBkVvg/QpC9H6SwQc96b3j9nu8X8PW/vn3iR6XD/3Euv75 H91WPfDeQDTeDyLHRLRw3l8P79eww/vxth94fzzReD/GeDWXiBfDRLeB92vY4/3oisoH3h9P 9N6PN6nw/swMWvZ4P9z4w7/30+C9e3Z4P4oWGd6fmUGL/UBJHU9RByMmNdo/7lNPzIP3q4jf ++E2lQwYw0S3gffreKzn07Dt5zPVxS9Ed/kW3q8hMO9XRgv57gdBQZ0fDhPdBt6vY5v36vv3 dbi+l+pyIGhfgfdrCMz7NV+fz/bzai/FVXcfeH9iBk/2eH8fr+5YGQjGuPx64717dnmvz/BV iU+Ee7w/LYMnu7z/2l+9Mt0P+fd44P0KruD9ffiz330B8D78S5GXv3+L34NvzT+33icwzlbc 3mu+jr4AL4luAe/PwIH3j48PvF9LcN5vYvgF+HSSKN6fgQvvv70EgmPelG9XXXIN778OvgBu EsX7Mwjk+zckAe/PPaBG9n4/J8v/wX/p8T4Q7xlH2xOHfD+D/9Lj/T7vne0d3nti5yc4vXnw X3q83+f9voHUzO8igetyXB25nWz8frYf0PQXIPgvPd7v8v5N7V39ttt/vPfEPu8NX4Dgv/R4 76Cc/9b86r/vTB7vPbEz3k9/AYL/0uO9E+/f8X41YdSnOvL+3aX3tOOdAfHeD5fy3mm8x/sz cFCfP3d+j/cGLuS94/N7vD+Dvd6/z+8h3hu4jPcTXwC8v7j3zpLHe0/s9N5pohq8PwO89wPe m8D7C4D3BvDeBN5fALw3gPcm8P4C4L0BvDeB9xeAcTUN4L0JvL8AeG8A703g/QXAewN4bwLv zyDIdrxp8N49eB9pBnsJw3sr8N49eB9pBnvBez/gvQm8P4NC0XyQZXHAMuNoG4jb+yMTxftk wfuzwPtIM7gkeH8WeB9pBpckAe/PPaBGAvT+DPA+DBhH2xN4H2kG1wDvPYH3kWZwDdK7LueE g2pDgO14Z4D3YYD3nsD7SDO4BnjvCbyPNINrkJ73cbfj0V/PdwbXAO89gfeRZnAN8N4TeB9p BtcA7z2B98dmUC9inGoqBfDeE3h/bAbV4hcB740PNXjvHrw/NgO8nwXvPYH3x2aA97PgvSfw /tgMlr3/eHwe/WbCBe89gffHZoD3szCupifw/tgMhPe5lD+vq7z/K1BXzaoM75fBe/fg/bEZ PE2vs7rvfV41K8QC3i+B9+7B+2MzUPFex3qxIOJ+Vgvn87oWz+L9EnjvHrw/NgPlvY71eVXp ZXEn/meJe28F3rsH7w/KQPfG097XWRvv5bII+XhvC967B++PRdfr1Tre13JZiI/3EyQwzlbc 3h+Z6AW9F6fzsnxfd+V86vUmwPuzwPtj6er1VDueuFH1epks62d43wfvzwLvj4V+O2tIwPtz D6iRAL0/A7wPA8bR9gTeHwvez4L3nsD7Y8H7WdK7LueEg2pDgO14Z4D3YYD3nsD7Y8H7WfDe E3h/LMvj6+G98aHmUt7H3Y5Hfz1rHot8nvdmQgPvPYH3R4P3M+C9J/D+aPB+Brz3BN4fDd7P gPeewHvwCN57Au/BI3jvCbwHj+C9J/AePIL3nsB78AjjanoC78EjeO8JvAeP4L0n8B48gvee SNz75ctmxpzw5mAI3rsnce+XL5MdkZ/w5mAI3rsH79eB90eSwDhbcXt/ZKJ4nyx4fxZ4v478 8Tjh7aUK3p8F3q9B1uy9n/D+EiUB7889oEYC9P4MJr2v87p++Zyq/qT1chHv3cE42p7A+ydy 3rrRxzRcUWU53rsE7z2B92KmulzOUavmpa8z+VepO7lSz2iH985J77qcEw6qDQG2451B3/tc Bfq6vTM9yPDeOXjviVS9173vVLzvvBchPns+aL1vXqBeKRYrvHcH3nsiVe/1vZ6evovqWc/7 3oMsU+IT7x2Tnvdxt+Ndqb+e0XvK+YeD957A+7acL+v1hPf9ej1VyU+93lHgvSfwfpLXdnwJ 7feOwXtP4P0kBu/pr+cYvPcE3q+D/vlOwXtP4P068N4peO8JvF8H3jsF7z2B9+vAe6fgvScS 9379+Hp47xLG1fRE4t7bTFc75oS3lwx47wm8x3uP4L0n8B7vPYL3nsB7vA8dvHdP8t5D8OC9 e/AewiGBcbbi9v7IRPE+WfD+LPAewgHvzwLvIRwS8P7cA2okQO/PIPx3mAaMo+0JvAeP4L0n 8B48kt51OSccVBsCbMc7g23X5Xh9y5cE7z2RuPerrsNlDmzn4L0n8N4evHdOet7H3Y53lf56 eO8XCPh7tAAAIABJREFUvPcE3tvDWDvOwXtP4L0tjKF9AHjvCbzX5PXrmPlqcqz2gbjBe7fg vSfwXpMPJNer+o+YI+sA8N4TeK/nw1MTXvfnxqtr5sY7Grz3BN5n/YlvmQv3XPDeE6l6r3vg 9byX09+2qjfP6AdN0JevysRihfduwXtPpOq9vu/H+6znfe+BqPIj3h8E42p6Au+nvaecfwp4 7wm8V/V62vt+vV6WUa93NHjvCbx/4bUdX0L7/QHgvSfw/gWD9/TX8wXeuwfv7aF/vh/w3j14 bw/eH00C42zF7f2RieJ9suD9WeC9PXh/NHh/Fol7v258Pbw/mAS8P/eAGgnQ+zPYOh+ux7d8 SRhH2xN4j/cewXtP4D3eeyS963JOOKg2BNiOdwZ4HwZ474nkvQef4L0n8B48kp73cbfjXaW/ 3kTuvV0L5DO6MHjvCbwfcRsutw/PeFMJgveewPsRt4nlcupJcADeeyJ578uiKdqXRVO8L5pH xb24ycd6uVlsnmj+l6V4WKgXFPK1sB+89wTe34XU91spF+43sWfdsvxfindUyqdEwV+tCOTj ix289wTe30W0F94Xrffycet9UXTei7WF8r4I5OOLHbz3BN6rCC7+37X3t0G8v3feDwsAJ7zL 64P3nsD7Nt6LE/fmvL2L9+pUXpzqF/pUoJAvEjfizP+Ed3l98N4TyXu/QCAf01VhXE1P4P0s RPVjwXtP4D14BO89gffgEbz3BN5D6OC9e/AeQgfv3YP3EA4JjLMVt/dHJor3yYL3Z4H3EA54 fxZ4D+GQgPfnHlAjAXp/BuG/wzRgHG1P4D14BO89gffgkfSuyznhoNoQYDveGYT/DtMA7z2R uPcrJsV89/qGLwreeyJx71fMg433B5Ce93G3412lvx7e+wXvPYH3tuD9AeC9J/Delo/H5wlv LDHw3hN4b0Uuq/ZOeGOJgfeewPuOqpH75WPSL8jlzQlvLDHw3hN435JX4t/oU8qf3ld47x68 9wTeizJ887+qa+F9syz/KnVXi+cqvD8KvPcE3stA3ziu4n3df9g+wPujwHtPpOq97oQ39F6E +O5h82TPe1Gxh/fOYVxNTyTqfcso3mc973sPiPdHgfeewHuj96qcn6kyAd4fAt57Au9VRb6o yFPe9+v1xGO8PxC89wTeT1GPl2m/9wjeuwfvp+h5L8M9/fV8gvfuwXtb6J9/PAmMsxW390cm ivfJgvdngfe24P3x4P1Z4L0teH88CXh/7gE1EqD3Z7JifD28PwDG0fZE4t7f7w97Pn2/1+uB 957Ae7z3SHrX5dgembeXAueW4/tmSiDAdrxzwXuf4L2J15qnLQM8VqYE8B7vPYL3Bt5et9zQ XfTNmEDy3oNP0vPesh1vqqFpfcCvjAkE6P2Z7XjgF7yfZiLcbwj441R6CeA9eATvp5nuV7J2 vrY2lbp6SQDvwSN4P426GExfB9rdybXrva/E4JHVMAG8B4/g/TSt95pd3ucy3uM9hAPeTyNG gKnyvJLONuG6ysWl4du8793iPQQB3k9TNVFaaJ+LO/FXZdVG7/MslnhfCG7tAssXXsb7kTnd OM9a+Lyu5Wm+nMClEs+suKSkEuPFyKKDfDhIYJubtN/DAeC9vn9631bviVP8jfV6kcR7gAHJ eu+knK/Be4iMJL0f1Ovle+r1iPcQJWl6L8kH2273Pob2e4ABCXs/7Ld37f56AAMS9H66f/7a S0Jf+uc/E8B7CJ0EvZ/soP+x+lLwypgA3kM4JDDOlqU5U9ffrx8C4s2YQPLjbEFA4H239Brw PzYM/VKZEsB7CAe8fy699L4TQz6tPaBvpgTwHsIhAe/nD0DPHDcjvZkSwHsIB7x/Ln6d8H79 Ef1qSOBQ71dcQrD5SgG4EHjfW3YzsKshgUO9XzELFbPLQxLX5cwfgL6OrwF/yyH9Op3Aoe14 eA+rwPsDDqrLjPAeDgDvzU+V4uCU04PSFJbH1yqjOY7wfls5Bi5EAt5b93grRzLLDae9LyeW FgjF+7WXHMAVwfv+sRi+dMr7cnC3pKUhozWs9T4Xo/yMqPLe78LaSwzhiuD9c6fF4bgV91sp A39xL25NUV9439wWcrH5f5OrykK+qrwVpXrhMmd5P5Bcr+o/EgOM4H3q4P1zpxt/G41vwuvG +GZBrBTeyzXNzU1Ef3Wv17VPWRzp471vIn1dC+/lQiZGAJB3cqV6kOE9CPD+udN3afDA+7Lo vC8KEeaV8EF6L40f3NYvDzK8BwHe94/Fi/e3XrxvZQ/K+24c3857EeI71cVgvupBE/T1CEDi 5XifOHjf2+uiEbkQQV2d33fxXp3fy3h/F+f3wnsV+oX2Yp3FkT7E+5Z+vM963vceiCo/4j0o 8H5q9y3WrMaP95TzYQq8n9p9izWrOdz7TJfwhff9er0so14PrEjc+0M43vsRr+34EtrvwUTS 3t96t4ODsqaXjk1GVjj3nv56YCJt7+UGr/MIxua9EfrnwzRpe69vx+f0eA8XJ03vRYdb0VJ3 K2+6j+5NNuqL1rqbbMtTt9vAewidNL3XXXZuz547pboup9FeddGVz2wE7yEcEhhnyz7et96L Lrk971UXHdl1vyg2l/UPbThYN74e3icP3ndL5TPe3wfet5fliKe2N+Uf3GA4NRiwmWPfCwQP 3j8Xi1t7fq8urZXn9+IHQMf7Qt9uA+8hHBLwfv4ADHR8rcR3B95DOOD98GjgPaQA3rs/pp4z Algkgety5g9A6N7v6SoEYADvDzioLjPCezgAvD/goLrMCO/hABLwPoXrcAFWgfdHHFWHGeE9 HADeH3FUHWaE93AAeH/EUXWYUSHpFlhm2cUy3i+r5wba7yF08N49eA+hg/fuwXsIHbx3D95D 6OC9e/AeQgfv3YP3EDp47x68h9DBe/fgPYQO3rsH7yF08N49eA+hg/fuwXsIHt+uugTvAezw 7apLEvDeOEPGgXnCBfHtqksS8N40TVZ+YJ5wQU4V82Dm9/Qa3jehfWrX8R5WcbabRzK/p9fw 3rDreA+rOFXMg5nf02t4X9eT6jPzLazhUu1487t6De8Nu473sAa8d8/R8T6fkB/vYQ147x7i PYTOpbxPpB0vF5X6zWm++Guivzzhx3tYA9675wTvs+Zf3vxVahnvYR14754jMnrT3fJ63jfB Xnpf4z2sBe/dc4j3+r4f7ysd7wV4D2vAe/ec7T3xHtaC9+45yfumnE+9HmwD791ztPdP8qxt y8d7WAPeu+c877PuIh28hzXgvXtO9L4D72ENeO8evIfQwXv34D2EDt67B+8hdPDePUd6bxxf D+9hBXjvniO9v98fJg7IFa4K3rsH7yF4fLvqErwHsMO3qy7BewA7fLvqkiS8B3CAb1ddMr+n eA/Q4ttVl8zvKd4DtPh21SXze4r3AJpLtePN7yreA2jw3j14D6GD9+7BewidS3lPOx6AFXjv nmdGb8bLaBrepzbtv2AqzbkEJzYDmATv3fPMyHTVrGRq6urBBv0fhqXrcOeTBRiC9+7pMnqb f7uvAX+4QT6Rpp4mYwa8h2Xw3j1dRgvB+dXQ0Qbvr2kS78EFeO+eNqOFcP8a8Mcb5K9pVmqq rBkYeQeWwXv3WMfmfFQP127Qqf2s/1sR7/EeFsF79wzmttH/pczNCu2tupNP9IJ6+2TdRnV5 M/T+Jd7no4OA97AM3rtn0vu8+fc0ds77XMZ7k/cvOz2u5sN7WAbv3dNzVExSX4k57GSsr5q7 ZjGvmxvh9rT3vVuD92piPHEnkqq6+bCZKQ8swXv3PB3Nhfi5CPSV8L7RvpKLVSXC/7T3ebYU 7/UsuPJOzZHZzovLzLhgB967p+10V8nCfS3Ur6X3QvhaLSpFRcVe/uxpV4maPlFKkMG7Fr8U tV5+vkRUB1ZyHmzxXJbhPawH793Tj/d5P95XMt5n3Z+hXm/x/F6U7UW8lyf3eA/rwXv3jMr5 zV+jpQz9NuV8DeV8OBC8d8+oXi8XVlayHa+t18vm6vWW432/Xi/LZWG/xntYgw8/jyI8718Y rDN7b26/b19iPAh4DxbsdS0kwvd+2MlmR389vIdd7JYtIALzfrF//sdI0Zf++U+J6acLTtnq WIjM72l41+O9THIz2qDCeziIHZoFx/yeBnf9/ceL96Pr7zO8h4PY41lozO9pcOPtTExqN9ig 6p0J4D245FLtePO7Gtr4eiLcf4437b+gfyawYnw9vIdF8N49vYyMk9ea5rAdXKfbOxOwmA+X mXHBGrx3Ty+jr/OCfr5uq/ZEtff1zgTwHlxyKe8Da8cTrBbUcCaA9+ASvHdPP6PZgP85sbHe 4Fvzr+8w3oNL8N49+zLS7n58DH4amC8HXIL37hlkVI7uF+kC/iB04z24BO/d88yoLIrV3g8K 8p+vaQLsB+/d08uoHMT7+fdnmybAbvDePUPvi3t5E5H/rv7dy7K8yUe3Ui6KB8tvE+/BJXjv nlG8v92aWC//30TIL5vHenWzKOwfbj09ny3eg0vw3j1j74tCel80lheN9/dCxHrpffMzIB4M NlZb12+1KU2A3eC9e17i/f0uw7oI/MJ7UezvvL+Nq/ze1E19fzekCbAbvHfP2HtxAi/O6GXM l6f88vy+ubuLs/up8/u3xvpJ741X4xy7S3Ax8N49+zKaj/em63CZ/RrWgPfuceC98fy+ktfn voL3sAa8d89u799fUyDeg0vw3j1HZGSeB1vBKDuwirPdPJIUvDfsOt7DKk4V82BS8F7EezVZ 1mAQfbyHVXiT9ABS8D5TyuM97MKXo0cwv6fX8V7MrpfXckK8Vn28h1X49NQ183t6He+rvJsN N9cn/HgPq/AqqmPm9zRu73W3PF3Er7X3Xe0+3sMaLtWON7+rUXvfouN91cb7dtfxHtaA9+45 03vK+bAFvHfP0d7L+jzq9WAHl/L+wu14LfTbARfgvXvwHkIH792D9xA6eO8evIfQwXv34D2E Dt67B+8hdPDePUdmZBxfD+9hBXjvnmMzYhZc2A/euwfvIXTw3j14D6GD9+7BewgdvHcPc9tA 6OC9e/AeQgfv3YP3EDp47x68h+Dx7apL8B7ADt+uugTvAezw7apL8B7ADt+uumR+T/EeoMW3 qy6Z39MLef9mvDyn4/D3AFHj21WXzO/plbxfPBTMiw1zXKodb35X8R5Ag/fuwXsIHbx3TxDe c50OzHAp75Npx8N72Afeu+ck79VUOXLanCd580DMlYn3MAfeu+fMeC+nyesdgnbKPLyHOfDe PafFex3raxHhm+W8ruQU2WId3sMceO+es7xvY32dt8tiYuyaeA+L4L17Dsyo7Y0n9rbORZjP 2ulxVcjHe7AB791zYEbvOgext7Jgr+J9JZeF/ngPNuC9e87yXpTtZfle/slyPvV6YAXeu+e0 eC/K+7Jur651vZ5ox8N7WATv3XOS97PgPcyB9+7BewgdvHcP3kPo4L178B5CB+/dg/cQOnjv HryH4DlBx9NIx/vl8fXwHubw7apLkvH+fv9qnBaX+XHBAt+uugTv8R7s8O2qS+b3FO8BWny7 6pL5PcV7gBbfrrpkfk8v5T3AHi7Vjje/q3gPoMF79+A9hA7euwfvIXQu5X1C7XgAe8B79+A9 hA7euwfvIXTw3j14D6GD9+55ZjS4fmaFs8bN7K/L2ZArpAPeu+eZUdV/d/ZTU78ZN7O+DrcD 72GCAL3P7YPZE2mY9H4QC/u7er73Iz2tFayMm+E9OCFE77ds9PR+IE3/W3++90N/rQP+m3kz vAcnXM77oRJ9Z073/sVOSwcr82brvf94fLrcN7gGl/N+JE3PmdO9H/urz2AWN+9e/boZ3oMT ruL9x+Pf0vuxEb2A78f7/t7ko3dk2Fy/OK9zNQFmb7PhfDlduqp6Q63Ihz83eA8TXMJ7FRCl 9+2Xvu4WusasyLyvRLzPR5tNe1+rZbwHW0L3PpfTO/fQ3+q6/8rWjqf3VV3pOn554837usrF T5D6W+V9PtizSe91wtJ6OS+mXJGLHww9LXaG9zBJ+N7rCV67x70n6/4Wfe+lbJl/7/OmtC7+ y7913sspLhfifZ2r+W/lxPdyPlw5M267KI8V3sMEoXqf1yqeqRnem/CVqwlf61ouZ+LcVy5V 2YT3vVsf3nd9CqTrKiDL3RAnJMvdE+TJidjpXKfyupnYKTURrjwCdd15L34B6krPjpvhPUxz qtJWSIufMUt8x7tFFcWq/oTv2av3eeY13rco72WkV+9m1fm9VbyvtN8D72t1cqTEx3uY4iyb LegHMxGzXr1X5Vn5pP6iqxc/A6J4UopQ6aTEffXaee8M2nJ+vaWcr1j2Pu//QqoVNeV8WOJE r5fQp+7ya15PxXtdnu1935X4r/V6gcR7Va+Xb6nXs4r38hyircXr1etV1OvBPEfLvIJp78cB beD9sJx/H/aVCcD7IWu9n2+/twPvYYoVXh5N33tVztd1e7JeTwUydQqry/n5qF7vHly8H0J/ PQiFtXIeSN/7VUx676/9vuXFzg+7ySzGvxfVU168ByeE1I633Xtdh3cPo79ex/h6PMtJbMbX 42V4D465hPeZ7p9/n+if/5wJ/nzv38bv0XLyquHvRYX34JqreT+OsZVP70fj7VhPWjccb0du +amewXtwwqW8n7j+PvPq/WDsHxHuP+22G40k9PHi/WKfv16ulnlCSlzO+2GMrXqVaR68v2+c o7a9FFffPcbeW82H2/LpfK8gekL03j6Y9cPav6fG1+tXpvnw/utGBav+EekVFPAenBCg91n2 L/sv9ZN/t+PpDpzpVab58H4U8K03G/x49bbEe3DCBb0fFJJ7lWlevB/4+Wm/nd7i4/Ex2BLv wQkX9P4+LP93X3wv3m9Fe/3tm7pvVzM6Ljjhit63zjyG0oTlfWlYbtF7NQz3eA9uCNL7rbTz 5bTODKXx4H1ZFKM13ZQ+S95/7f+mdWvxHpxwSe+7gD+Qxof3y0817/k287IReA9OuKT3g1r0 z3alJ++L++3WBP6y0ftWluKmKQPI2+bmfmseFHJ5tOm04XgPTrim95N4KedrtRvjG/0b7cWN fEY9Fr8JIt7fxjH/De/hQC7p/bThfuJ9q7bwv5A3omgv43/f+3FFwLu6hPB9NI813oMTLun9 9NAW3r2/6QflM/4/4/14U2n4+9v72+tagL1c0fs35Ur9NvTf3/m9iO/3psgvT/ILeX6vz+nF eYAs85fjin/t/X3S+xXX5dT8VMArV/ReufLWhP3Bd95r+719lb1mNt6vuA6XibBhir2uOcS1 9+/Re286v8d72Mle1xxy5Xi/mnf5w/W6VoL3sJO9rjnEcX1+AOf3vTj/0kC/iQ3eM/AGTLDX NYfs9r7dpzdZIzbGq/ddA/3qAv8AvAc37HXNIc68n8ZvvL8N7u6j1bYM58vJsnb2SzXU/nCy YDWjLt7DFHtdc8gFvS/Ku2jBK26iY478p1Y0z9xu92Z9oZ63Te8l3qsJgya8V7MJZXgPU1yq HW9+V72034s+Oo3gd90/V/fVEWtls33bR9c27I/mx5NqqxlD26nx9GR5Wa0nCMV7mADvj0R4 L7rm6M55Isi33pfCe9lhZ7P3vSmC26lw+3MJqilF8R4mwPsjKXVQv6vrccpevJdddXXoL60v xX2OFyq8lxN+P2cMzeR8ge38uHgPZi7lfXDX48nT+Zs8v7+pE/tS3N1k6L+rbroq3q+r5tfl fCV+3/s6b+cRxXuYAe/9sb1Fv1fO793pv3b6cOr1wAjee2NHS/6zXk/V4vXq9Spdr5fJsn6G 9zAF3scI/XZgH3gfI3gP+8D7GMF72Afexwjewz7wPkbwHvaB9zGC97APvI+RNePr4T28gvdx MphGa4FP328WggPv4wTvYQ94Hyd4D3vA+zjBe9gD3gMkiAthHYH3ACfhQlhH4D3ASbgQ1hF4 D3ASLoR1xPXG2QIIFBfCOgLvAU7ChbCOwHuAc7hUO978ruI9gCZB78WgdJN/hx9sgEBI0Htj NocfbIBAuJT3du14xs2PP9oAYYD3T44/2gBhgPcd+eNx/PEGCIEEvZ/ORo5N8378AQcIgNS9 z/XU8SpzvIc0SN37+ul9jveQCgl6L16Zy8mk8zpXU8tleA9Jkar3csZYPWlsrTLHe0iGlLyv 1Z94pfJeThPfet8UACq8hzRIyXt9L7LRM8QT7yFN8B7vIT2S9r4p5yvzM7yHpEjQ+5nM8R7S AO819NeDhMD7DvrnQzrsdc0hXvvn4z2kxF7XHIL3ACex1zWHePY+w3tIhr2uOeSkcbZMw+vh PaSDC2Edcdp4usaZYw8+1gCh4EJYR+A9wDlcqh1vflfxHkCD93gP6ZGk9wCJcynvmQcbwIpk vb/1XlwON3xNptx+gAECJE3vG9H73o+2u708wHu4Fnh/H4le9h+WgzuAi5Cm97dG7lspbsuy uN+LWyF+B8Rds/JWNIvdA/GyG97DtUjY+8Z54b1+WKi7u1556x40iZZ4D9ciSe/LorhJ78tS lupvSm8Z/wtVCLh1Dxr7C7yHa5Gm96I6X5hdNCf65cD7rhDQPbjpQgHAdUjYe1G5J2K6qNcr 7l28l0X8Nt6ragDiPVyMJL0HSBy8B0gPvAdID7yf4/ayAHAF8H5OaryHa5K29+XLwpBb+wze w7VwIawjzvO+kB1xy6K83UQX3UJ1zpUr77J3rnhKtOLJ5ZtcDXAhXAjriBPb73WnnPJe3Nse u3e18n5XHXVUn51u6eiPAeBUXAjriLO9Vx3yi5v+CZjyviian4YC7+FquBDWEaeNs9V6X5bP K3TEVTgT8V5elov3cDVcCOuI88bXE+f38hLcm473d31+L7wvn1fo3vR/zu/hYrgQ1hGBjatJ p3y4LJdqx5vfVbwH0OA9QHrgfXsgesu3qZUA1+FS3m/vr3dX7Xia29RKgOuQtvf9A9Eu3Kbi PfX5cCnS9F4OpyM66OquuXfZK1f8K29yfF3Vj2ewEuA6JOl9O3ReocfLvfd66gzG2eyvBLgO CXtfqBtZlteKF1PeF3gPVyNh7+/P0fPvz2F0J+K9XIn5cCGS9F5eg6tP8m/FrT2VF4/k3DiF HF17uBLv4UKk6f3E1Jf3YZPd0ogcADGD99MrGWELrowH7+seA9XDG1cT4Jqc731ufID3AOdw vveV8RHeA5zD6d7n5od4D3AOp3s/lrsyP7UavAew4mzv2/ie192CQC7iPcBJ7HVtJdr7PK9z ZXv+XIv3ACex17WVaO8rEe+fyuM9wKnsdW0l+fgW7wHOZ69rK2kNPyTez+8p3gO07HXNlraH nlwS1Xm56q+Xi/v8tfPeFub3FO8BWlw4bYOWul+fT7wH8MNp7Xgj77vl872vZ3g//IADBIAv 7z3G+7ls8B6SwJ/3B7Tfz+8q3gNofMZ7vXB2fz28h+Q52/uJ/vkfj39PP7Wa/d5/PD4PP+QA 3jnd+9fr8fAe4GRO9/71+nvv3tfPRbyHJDjf+/F4O/nDt/c98B6S4Hzvx+PrfXjxvq6zvK6a vzqv6qx5H6puEe8hCTx4nw/vHj68zyupe16J/+ovF+vxHpLAg/ftorr7OM/73hi+uYzwT+9F cyLeQzL48D7vl/Qb7R+vL9nGinK+KOGLsN953/4KfR5+yAG848P77KH4eHzI+39PvGQTW8r5 eZ1RzofU8OL9v5T3376p+6mXbGJ9vZ7ynno9SAwv3j8Dfj/c044HcBJ+vNcBfxju8R7gJPx4 v/kl8+A9gBV+vJ9WD+8BTmKva7b0bcvxHsAre12zZTABpmpCr0YjaeI9wEnsdc2W13J+lVe5 +SVbsPN+bnw9vIc02OuaLVPeZ469n9/T53i6jxk+jz3cAEGw1zVbzoj383uK9wAte12z5dV7 9+f383uK9wAaX+14+YTleA9wDpfqtzO/q8yXA6DBe4D0uJT3zIMNYAXeA6QH3gOkB94DpAfe A6QH3gOkR4Lez12XY+T4TwLgPBL0fks2+fGfBMB54L0VeA+XAu+twHu4FHhvRf54HP9ZAJwF 3lsga/bej/8wAE4ide/ltDm9x+0svVX/Dcl7vIfrgPfiX//xk/zpfY73cCVS9b6ucjlFXi3l bhZrOUeemCZXTJeXN3dyqVZvDO/hWux1zZawvM+z+jkl7nN2XHmnntSP5c8C3sPV2OuaLQF4 r7ve6flwJ7wXIV+U9OvOe/XiSmyF93Ah9rpmSwDe63sZ76sJ70UVn7yrWu91pR/xHq7GXtds CWecraH3Wd0r8ucj7ynnw0XZ65otYXmvy/mqbq+S9XqZrMUTwrfl/Ix6Pbgqe12zJTDvV0H7 PVyMS7Xjze8q/fUANHhvBf3z4VLgvRV4D5fiUt5zPR6AFXhvBd7DpUjQ+03j6+E9XIkEvZ+f D9fI0Z8EwHngPd5DeuA93kN64D3eQ3ok6T1A4uA9QHrgPUB64D1AeuA9QHrgPUB64D1AeuA9 QIIMxMmXLk9ZVK//4oHH4Xi/+pqc4z8EgJMZiJMviLX0/PAFgwfheL82G+bAhusx/IovKbDk SGV8hPcA4TD8ii8psO75/sN4x9nCe7gew6/4kgKPx+zzY6Uq81MWW69mfk83e881OXA5hl/x WQFeK+vGhryseFYGxuq93APG0IZrMWzHM3ovn6i6m7lXvaxQa4P0Ph/8jOm3nw/2kzkz4IJY el93ClzK+zrrt0z2l/On98yRBZdjwvtaTRTXziAnZo9rp4VdkDMi7+VOSrnlkt5JsSwmx1RL zI0HV2XK+2w4P6y6y6y9b8wR+nQrzvN+zTzYYp96c2B3c+FmzIUL12fa+7ruXFDBXnlfy0A4 251v2F8vz+X2S/WBJ3nf60b46r3cyedcuKqk0+403sO1MMT7LOsFelEA7ryMN963THqvdlLO g629z9qTG+I9XI4DyvnjFeF6n413su895Xy4LpPe63o9Ud+l6vWyPIp6PXvvZW2easeTS6rm H9LLAAAHiElEQVQqs3qW8zPq9eDCzLTjvVx8dyXvraH9Hi7IGu+D7693hPf014MLYtlvp31+ Zf/8j+frY/We/vlwQdx6P74e74H3AAHi1vuRuh94DxAijr0fjrfzwHuAEBl5vzTU3JL3g/56 Itz/u30iHO+X9nFipw/+EABOZjye7r+WpoVdUG+8/RqpT/J+w3y4h34EAKfj2vts+Op/r5Ea 7wHOwbn3/zK8Gu8BwmFW2w3eDwL+v1dJjfcAJ7HXNVtC8h4gdfa6ZgveA4TDhD6/v6z5Zfz4 9SVL+B9nCwBaxu4Uxe/L3q/XHu8BAuJFnt+HVssHv4zW4D1AzLzOg/17VjR/jeu//CLuxdLv v4iF3wuxJNeI5d/1C5snbX4G8B4gGKa8//0XofIvv8t7Ed1/kQvyf7sma8xXL8R7gNgweN9E 8l+y1vKiECuk68XT+99b73+fqBDYJPVu78tCc2t2jGWWWTYuv8ij4n3W8775Dfildf3V+19+ f01jm9S7vQeAjQjvMxnv5fl9Y/wvhVghXBdLv/8i6wAypb94wbi2fxK8B0gPvAdID7wHSA+8 B0gPvAdID7wHSA+8B0gPvAdID7wHSA+8B0gPvAdID3vvFyfvGMPvBUCgrPD+gKQBwAd4D5Ae eA+QHgd6/9GfnwMAwuEo71Ut4IY3BACHs837odH6BXX/Vfl4EwAIhk3e51Ve9R/1Xtz+IORi O7wHCJKV3ud11fzV7VIt7upaLmfNnVqqMrwHCJmV3gu7KxnU5VJe6btMLOrH8mm8BwgXC+/b /ndy+cX7WpX6RdzX3qvzfFGxh/cAQWLfyD4d7xvN1V0X75X4xHuAcNnkfa+A3+lPOR8gGlZ6 L+rtKhnS5VIua/HqXjk/p14PIHhWer/u1XgPECSHeU9/PYBgOcr7jP75AMGC9wDpgfcA6YH3 AOmxwvu14+vhPUCgrBkU51+Plfz7qHcNAHvAe4D0wHuA9MB7gPRg0FuA9MB7gPTAe4D0wHuA 9MB7gPTAe4D0wHuA9MB7gPRoB8efub6GnwaAi2Ex6SXeA1wMvAdID7wHSA8L7xk/A+BiLHnP eNgA12NicvvB88x/AXA9Xr0fBnfmuwK4HoPJ7cUk1mKiu0zeMs8dwEUZeJ91M9rKya6Z1xbg mrSd8uSyqMUbey8q9vAe4Ip08V5OcU+8B0gByvkA6aG9F1V7jfs13gMkgLnfzuyzABAx9NcD SA/65wOkB94DpAfeA6QH3gOkx9z4engPcFXmJrv9t+83BwCHgPcA6YH3AOmB9wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABAiX/77cxu+3zgAbOXL/zZqj/cAjvj1588/Jp/47W91/+Wn+t+s +fHl528/s99+iofff/79fK1U8suLl9/F+p/f/x6unYv2f/6G9wDH04g28lL7+/T+y0+16td/ fv3nt59/fBcPv/Q1/C7TMHs/MP/LnNl4D3AGf/09jscj75X56v63H7/9/PMv5X3W8/7v36a9 F0n81PfdSrwH8I3wXkRwGcf/acrxzaPmT5Xj//ny49cfP7///PHz549Mhu7m+Z/K+z+al/xo fBde/xA6N2k0JwJi859//CYLEY3vzcrvP8QWf+sTgy9/CYP//v7nX398+efXH5lYaIz+689f s+zPX//87c/snyxrsmnOHf7MfqpHv+I9gFP+km7+aP8avuvFRtOfTcFeey+k++uvJh5Li5vl f0Tk/v5DLP/680+Vxs/v8q99/fd//vddeS/XS++Vw3//9sf3LPvx5e9MLIg4n/1PPCvs/1W8 6p/s5z9yUTzK8B7AKX/93Vj6W/vXhFd5Oi8eCe+/C2u7M/zvTSD/559/5IP//vy/73//9b/m lF/E8H/+8/NX8cLvf4u/3378k6nXqxXiX1u9p2r1/v5VCP1n808sNI+/NDk3Kxvvm9u/v3xp fk/+yX6oR7/hPYBbpPd/SembW1EMF5L/pbz/q+H/nt6LeP/j5w/9I/BP4/3//RRl/KbE8H8/ ZTXA93+U900y4iU//vPivTq9//Gl4Y+G/4iFn43jvyrvf/tTL/z6U4Z8vAc4gOb8Xhbrf5O3 2ff/Scl/au9//vWz5704v/+7OX3/oprtGu//bH4KRCrff2jvfyrvm2QyeX7/4v1fyvvsS/bl j+yP7D9iQf4OaO//yf7bmP7HH9/xHuAwpPdf/iO8b26zn38ozf8jvW+K+T//03kv6/Mb11W9 nvL+u2j9/+3vZmtdzv+P9L5JJpvz/h9RvhfF/P+Jheb8/tdmSZXzRVH/tz+b11HOBziK33SN no73P0U5v6vX+29z+v4fuUJW34n2+7+///HzWYn3x28/e2k84/3Pv9rze7Hiu7qT+SmD//nj +x///b/mLP5/YkHU8v3xX+29OPGXzQRtvR7eA7jm158/ZDveb/JWFti/d+14XxrT1Urhveyv Jyz8Ihrifv5o/pqzfJGIagWU//5W5fwf2vsvynu5PlMvlTSif/8hau/EQpPmX6pGT7fjifaB rG3Hw3uAgJDN8z9WbjTXL0eXBcR5/a9TzxyyFwCwBun9dOd+M5be/zX1zP8Dyi5MrVQHGMYA AAAASUVORK5CYII= --------------050908080108080606090400-- From - Tue Mar 4 11:17:54 2003 X-UIDL: 3e5baf6500000093 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h24AJ5X5022467 for ; Tue, 4 Mar 2003 11:19:06 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h24AJ4n28417 for ; Tue, 4 Mar 2003 11:19:04 +0100 (MET) Received: from mailsend.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAGJaWF3; Tue, 4 Mar 03 11:19:03 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18q9SA-0005p3-00 for voql@ivoa.net; Tue, 04 Mar 2003 10:15:18 +0000 Received: (qmail 4464 invoked from network); 4 Mar 2003 10:15:40 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 4 Mar 2003 10:15:40 -0000 Reply-To: From: "Tony Linde" To: Subject: Splitting VOQL up Date: Tue, 4 Mar 2003 10:15:18 -0000 Organization: University of Leicester Message-ID: <005501c2e236$f4f08530$b524d28f@bunyip> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: I've put down a few thoughts on VOQL, from an idealised VO activity diagram to proposals for splitting the VOQL up into a number of more specific, focussed languages. The document is still in preliminary form at: http://wiki.astrogrid.org/bin/view/Main/TonyOnVOQL I thought this might help in the discussions about the current proposed formats from Ed and Masatoshi. I'll post the document onto the IVOA wiki after adding feedback (unless it gets totally trashed :) ). Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 AstroGrid Project Manager Fax: +44 (0)116 252 3311 Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 University of Leicester Email: ael@star.le.ac.uk Leicester, UK LE1 7RH Web: http://www.astrogrid.org From - Wed Mar 5 00:17:30 2003 X-UIDL: 3e5baf65000000b3 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h24NImvK015167 for ; Wed, 5 Mar 2003 00:18:48 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h24NIls05097 for ; Wed, 5 Mar 2003 00:18:47 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAATma47j; Wed, 5 Mar 03 00:18:46 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h24NHZPT027153; Tue, 4 Mar 2003 18:17:35 -0500 Message-ID: <3E653473.4040105@gsfc.nasa.gov> Date: Tue, 04 Mar 2003 18:19:15 -0500 From: Ed Shaya Reply-To: edward.j.shaya.1@gsfc.nasa.gov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ael@star.le.ac.uk, voql , metadata Subject: Re: Splitting VOQL up References: <005501c2e236$f4f08530$b524d28f@bunyip> In-Reply-To: <005501c2e236$f4f08530$b524d28f@bunyip> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Tony, Overall the scheme looks fine. Just a few points. 1) In the diagram the arrow to the Ontology should come back to the Problem Assistant. I doubt that there needs to be a line from ontology to Workflow directly. 2) The RQL will probably also been in XML for extensibility and transformation purposes. 3) After Registry, before Workflow submits, it probably needs to go to the human again because there may be more than 1 way to solve the problem and they would be of differing levels of completeness. These various paths may not be be obvious until the registry is searched. 4) One needs a final analsysis of the logic and math of the problem after all queries have been resolved. 5) I think what you call the Problem Statement Languate (PSL) can in fact be mostly separated from a specific ontology or metadata language, as Ray pointed out. This is clearly important because one does not want all software to be rewritten when there is a change in the ontology or metadata arrangement. In fact in each of the VOQL "Languages" there needs to be such an effort of independence from the rapidly changing part of the problem (otherwise you never finish). The way to do this by keeping to abstract types of objects and properties on everything. For the PSL, the language merely needs to express that there are objects with properties. These properties have names and values and query return to variables. The values can be numeric, string, or bags of other objects. The query return variables can be constants or depend on other variables. The other parts of the VOQL will probably break down similarly. There will be families of properties that resolve in the later stages (workflow etc) in very similar ways, so property families can be formed. Once a usefully large set of property families are listed, the software development could begin. That is, there could be a realizable system that would respond to some subset of queries that is independent of specifics of ontologies. An early design of VOQL can inform us on both metadata that needs to be available at registries and the level and direction of ontological development needed. Once the NVO science queries are in a consistent machine readable format, requirements on the metadata and ontology will be clearer. That is not to detract from the effort that has already gone on in reducing the science queries into requirements. It is just time to reach the next level of this analysis. Ed Tony Linde wrote: >I've put down a few thoughts on VOQL, from an idealised VO activity >diagram to proposals for splitting the VOQL up into a number of more >specific, focussed languages. The document is still in preliminary form >at: > http://wiki.astrogrid.org/bin/view/Main/TonyOnVOQL > >I thought this might help in the discussions about the current proposed >formats from Ed and Masatoshi. > >I'll post the document onto the IVOA wiki after adding feedback (unless >it gets totally trashed :) ). > >Cheers, >Tony. > >__ >Tony Linde Phone: +44 (0)116 223 1292 >AstroGrid Project Manager Fax: +44 (0)116 252 3311 >Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 >University of Leicester Email: ael@star.le.ac.uk >Leicester, UK LE1 7RH Web: http://www.astrogrid.org > > > From - Wed Mar 5 10:22:31 2003 X-UIDL: 3e5baf65000000ba X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h259KLvK001013 for ; Wed, 5 Mar 2003 10:20:21 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h259KLh20326 for ; Wed, 5 Mar 2003 10:20:21 +0100 (MET) Received: from ntp2b.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAThaOSN; Wed, 5 Mar 03 10:20:20 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by apollo.le.ac.uk with smtp (Exim 3.16 #1) id 18qV0t-0002PO-00 for voql@ivoa.net; Wed, 05 Mar 2003 09:16:35 +0000 Received: (qmail 10079 invoked from network); 5 Mar 2003 09:16:56 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 5 Mar 2003 09:16:56 -0000 Reply-To: From: "Tony Linde" To: "'voql'" Subject: RE: Splitting VOQL up Date: Wed, 5 Mar 2003 09:16:33 -0000 Organization: University of Leicester Message-ID: <009e01c2e2f7$ea68a040$b524d28f@bunyip> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E653473.4040105@gsfc.nasa.gov> Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ed, Thanks for the response. > 1) In the diagram the arrow to the Ontology should come back to the > Problem Assistant. I doubt that there needs to be a line > from ontology You're probably right but it may be that, in order to keep the problem statement concise and human interpretable, terms are used which the workflow needs to resolve into more detail by going back into the ontology - but I agree that it'd be good if that is unnecessary. > 2) The RQL will probably also been in XML for extensibility and > transformation purposes. Again, probably. But a query language needs to be parsed, interpreted and executed - I'm not sure transformation is necessary - and any language can be extended - look at the SQL extensions around. That said, I'd prefer xml-based languages since we have mechanisms to transmit and parse them. > 3) After Registry, before Workflow submits, it probably needs ... There's loads of detail missing from the diagram - I only wanted to capture the key interfaces. Unless people think it is worth expanding this diagram further? > 4) One needs a final analsysis of the logic and math of the problem ... Definitely. > 5) I think what you call the Problem Statement Languate (PSL) can in > fact be mostly separated from a specific ontology or metadata > language, ... I think I understand what you're getting at. No language would be designed that dealt in specifics. The syntax of the language would state what types of object could be used in which place and how it all hung together. But the names of those types of object would also be in the ontology, presumably at the top of some hierarchy. > query return to variables Don't understand what you mean by this. > There will be families of properties that resolve in the later stages > (workflow etc) in very similar ways, so property families can > be formed. Definitely. These are the hierarchies from which the ontology is composed. But there will be multiple hierarchies (the main two being 'is a type of' and 'is composed of') and they and the terms within them will be inter-related. A term can belong to more than one hierarchy. > That is, there could be a realizable system > that would respond to some subset of queries that is independent of > specifics of ontologies. Don't understand what you mean by this. > An early design of VOQL can inform us on both metadata that ... Which part of the VOQL? PSL? WFL? RQL? AQL? > Once the NVO science queries are in a consistent > machine readable format, requirements on the metadata and > ontology will be clearer. I think I see what you're getting at and I half agree. Using this as an approach to looking at the AstroOntology, its scope and how we might approach its creation would certainly be useful. I'm not sure that it might not confuse the exploration of metadata, though, by bringing in terms and concepts that cannot be dealt with in this early stage of VO development. And having the language in a 'machine readable format' might confuse the issue further. Certainly, I find it very difficult to mentally parse your schema to see how it might aid in VOQL development. It might be better to come up with a 'human readable format' first and then look at mechanising it later. And though we might have a machine readable format, we are a long way from making that machine *interpretable* - that'll have to wait for the ontology, I think. Cheers, Tony. > -----Original Message----- > From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] > Sent: 04 March 2003 23:19 > To: ael@star.le.ac.uk; voql; metadata > Subject: Re: Splitting VOQL up > > > Tony, > > Overall the scheme looks fine. Just a few points. > 1) In the diagram the arrow to the Ontology should come back to the > Problem Assistant. I doubt that there needs to be a line > from ontology > to Workflow directly. > 2) The RQL will probably also been in XML for extensibility and > transformation purposes. > 3) After Registry, before Workflow submits, it probably needs > to go to > the human again because there may be more than 1 way to solve the > problem and they would be of differing levels of completeness. These > various paths may not be be obvious until the registry is searched. > 4) One needs a final analsysis of the logic and math of the problem > after all queries have been resolved. > 5) I think what you call the Problem Statement Languate (PSL) can in > fact be mostly separated from a specific ontology or metadata > language, > as Ray pointed out. This is clearly important because one > does not want > all software to be rewritten when there is a change in the > ontology or > metadata arrangement. In fact in each of the VOQL "Languages" there > needs to be such an effort of independence from the rapidly changing > part of the problem (otherwise you never finish). > > The way to do this by keeping to abstract types of objects and > properties on everything. For the PSL, the language merely needs to > express that there are objects with properties. These > properties have > names and values and query return to variables. The values can be > numeric, string, or bags of other objects. The query return > variables > can be constants or depend on other variables. The other > parts of the > VOQL will probably break down similarly. > > There will be families of properties that resolve in the later stages > (workflow etc) in very similar ways, so property families can > be formed. > Once a usefully large set of property families are listed, > the software > development could begin. That is, there could be a realizable system > that would respond to some subset of queries that is independent of > specifics of ontologies. > > An early design of VOQL can inform us on both metadata that > needs to be > available at registries and the level and direction of ontological > development needed. Once the NVO science queries are in a consistent > machine readable format, requirements on the metadata and > ontology will > be clearer. That is not to detract from the effort that has already > gone on in reducing the science queries into requirements. > It is just > time to reach the next level of this analysis. > > Ed From - Wed Mar 5 18:42:31 2003 X-UIDL: 3e5baf65000000d6 X-Mozilla-Status: 0011 X-Mozilla-Status2: 10000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h25HevvK003024 for ; Wed, 5 Mar 2003 18:40:57 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h25Heup17791 for ; Wed, 5 Mar 2003 18:40:56 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAItaOVI; Wed, 5 Mar 03 18:40:53 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h25HdkPT008844 for ; Wed, 5 Mar 2003 12:39:47 -0500 Message-ID: <3E6636C0.30407@gsfc.nasa.gov> Date: Wed, 05 Mar 2003 12:41:20 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "'voql'" Subject: Re: Splitting VOQL up References: <009e01c2e2f7$ea68a040$b524d28f@bunyip> In-Reply-To: <009e01c2e2f7$ea68a040$b524d28f@bunyip> Content-Type: multipart/mixed; boundary="------------010907070504070905090103" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: This is a multi-part message in MIME format. --------------010907070504070905090103 Content-Type: multipart/alternative; boundary="------------040209090306070105000801" --------------040209090306070105000801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tony, > > >> query return to variables >> >> > >Don't understand what you mean by this. > > All I was noting here is that in PSL query for a particular propery of some type of object, say, the result can go into a variable so the user can create (mathematical, logical, statistical) expressions and can then manipulate that variable in various mathematical or statistical ways. Also, I have now examined the first 4 NVO science use cases and found that it would be highly useful (although not absolutely necessary) to allow users to create variables with variable arguments, such as magnitude(optical_band). Then one can have expressions in which magnitudes of a given specific band are considered one at a time. The problem arises when the query is for "radio data" or "optical data" and the user either doesn't care about which sub-band is used or wants all such available data. > > >>There will be families of properties that resolve in the later stages >>(workflow etc) in very similar ways, so property families can >>be formed. >> >> > >Definitely. These are the hierarchies from which the ontology is >composed. But there will be multiple hierarchies (the main two being 'is >a type of' and 'is composed of') and they and the terms within them will >be inter-related. A term can belong to more than one hierarchy. > > In addition, there are families of similar behavior in workflow that may or may not ordinarily show up in ontology: "requires cross-matching", "requires averaging over all return values", "may require a quality flag", "can be in tables, but can also be derived from two other UCD types", "never in tables, must use image service", etc. > > >>That is, there could be a realizable system >>that would respond to some subset of queries that is independent of >>specifics of ontologies. >> >> > >Don't understand what you mean by this. > Another way to put this is we can demo it before it is done. > > > >> An early design of VOQL can inform us on both metadata that ... >> >> > >Which part of the VOQL? PSL? WFL? RQL? AQL? > > I think each of us would answer a different part. Everyone has their own perspective on the most essential part of a query system. To me it is the user interface, which would need a PSL that includes a large part of AQL (bad for the abbreviation to be the same as Astronomy Query Language, ADQL). > > >>Once the NVO science queries are in a consistent >>machine readable format, requirements on the metadata and >>ontology will be clearer. >> >> > >I think I see what you're getting at and I half agree. Using this as an >approach to looking at the AstroOntology, its scope and how we might >approach its creation would certainly be useful. I'm not sure that it >might not confuse the exploration of metadata, though, by bringing in >terms and concepts that cannot be dealt with in this early stage of VO >development. > >And having the language in a 'machine readable format' might confuse the >issue further. Certainly, I find it very difficult to mentally parse >your schema to see how it might aid in VOQL development. It might be >better to come up with a 'human readable format' first and then look at >mechanising it later. And though we might have a machine readable >format, we are a long way from making that machine *interpretable* - >that'll have to wait for the ontology, I think. > > But, validation is also a very useful tool. The language is complicated enough that one can easily write down a query in short hand and it looks about right, but a validator immediately points out the inconsistency and actually suggests alternative designs. If you are not used to reading XML don't worry, I am almost at the point where I can generate an XSLT to transform it to a pretty web page. I believe that the page can look something like this: Begin Request AND these constraints { Find me astronomical objects with following properties: AND these propererties { 1. name: is assigned to *var1* 2. class is "cluster of galaxies | galaxy cluster" 3. Measurement quantities satisfy: a. X-ray brightness > 3.3E7 : assign value to *var2 * A. Time of measurement in interval "12:23:1998" to "1:14:1999"* * b etc } Using the above variables satisfy the following mathematical expressions{ 1. *var2* < *(var3* - *var4) }* OR these constraints { [some constraints for wich 1 must be true etc ] } } Please return a table with the following columns in order var1 var2 var3 End Request Meanwhile, let me know if the attached postscript file is any easier to read. >Cheers, >Tony. > > > >>-----Original Message----- >>From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] >>Sent: 04 March 2003 23:19 >>To: ael@star.le.ac.uk; voql; metadata >>Subject: Re: Splitting VOQL up >> >> >>Tony, >> >> Overall the scheme looks fine. Just a few points. >>1) In the diagram the arrow to the Ontology should come back to the >>Problem Assistant. I doubt that there needs to be a line >>from ontology >>to Workflow directly. >>2) The RQL will probably also been in XML for extensibility and >>transformation purposes. >>3) After Registry, before Workflow submits, it probably needs >>to go to >>the human again because there may be more than 1 way to solve the >>problem and they would be of differing levels of completeness. These >>various paths may not be be obvious until the registry is searched. >>4) One needs a final analsysis of the logic and math of the problem >>after all queries have been resolved. >>5) I think what you call the Problem Statement Languate (PSL) can in >>fact be mostly separated from a specific ontology or metadata >>language, >>as Ray pointed out. This is clearly important because one >>does not want >>all software to be rewritten when there is a change in the >>ontology or >>metadata arrangement. In fact in each of the VOQL "Languages" there >>needs to be such an effort of independence from the rapidly changing >>part of the problem (otherwise you never finish). >> >>The way to do this by keeping to abstract types of objects and >>properties on everything. For the PSL, the language merely needs to >>express that there are objects with properties. These >>properties have >>names and values and query return to variables. The values can be >>numeric, string, or bags of other objects. The query return >>variables >>can be constants or depend on other variables. The other >>parts of the >>VOQL will probably break down similarly. >> >>There will be families of properties that resolve in the later stages >>(workflow etc) in very similar ways, so property families can >>be formed. >> Once a usefully large set of property families are listed, >>the software >>development could begin. That is, there could be a realizable system >>that would respond to some subset of queries that is independent of >>specifics of ontologies. >> >> An early design of VOQL can inform us on both metadata that >>needs to be >>available at registries and the level and direction of ontological >>development needed. Once the NVO science queries are in a consistent >>machine readable format, requirements on the metadata and >>ontology will >>be clearer. That is not to detract from the effort that has already >>gone on in reducing the science queries into requirements. >>It is just >>time to reach the next level of this analysis. >> >>Ed >> >> > > > --------------040209090306070105000801 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tony,
  
 query return to variables
    

Don't understand what you mean by this.
All I was noting here is that in PSL query for a particular propery of some type of object, say, the result can go into a variable so the user can create (mathematical, logical, statistical) expressions and  can then manipulate that variable in various mathematical or statistical ways.  Also, I have now examined the first 4 NVO science use cases and found that it would be highly useful (although not absolutely necessary)  to allow users to create variables with variable arguments, such as magnitude(optical_band).  Then one can have expressions in which  magnitudes of a given specific band are considered one at a time.  The problem arises when the query is for "radio data" or "optical data" and the user either doesn't care about which sub-band is used or wants all such available data.
  
There will be families of properties that resolve in the later stages 
(workflow etc) in very similar ways, so property families can 
be formed. 
    

Definitely. These are the hierarchies from which the ontology is
composed. But there will be multiple hierarchies (the main two being 'is
a type of' and 'is composed of') and they and the terms within them will
be inter-related. A term can belong to more than one hierarchy.
In addition, there are families of similar behavior in workflow that may or may not ordinarily  show up in ontology: "requires cross-matching", "requires averaging over all return values", "may require a quality flag", "can be in tables, but can also be derived from two other UCD types", "never in tables, must use image service", etc.
  
That is, there could be a realizable system 
that would respond to some subset of queries that is independent of 
specifics of ontologies.
    

Don't understand what you mean by this.
Another way to put this is we can demo it before it is done.


  
 An early design of VOQL can inform us on both metadata that ...
    

Which part of the VOQL? PSL? WFL? RQL? AQL?
I think each of us would answer a different part.  Everyone has their own perspective on the most essential part of a query system.  To me it is the user interface, which would need a PSL that includes a large part of AQL (bad for the abbreviation to be the same as Astronomy Query Language, ADQL).  
  
Once the NVO science queries are in a consistent 
machine readable format, requirements on the metadata and 
ontology will be clearer.
    

I think I see what you're getting at and I half agree. Using this as an
approach to looking at the AstroOntology, its scope and how we might
approach its creation would certainly be useful. I'm not sure that it
might not confuse the exploration of metadata, though, by bringing in
terms and concepts that cannot be dealt with in this early stage of VO
development. 

And having the language in a 'machine readable format' might confuse the
issue further. Certainly, I find it very difficult to mentally parse
your schema to see how it might aid in VOQL development. It might be
better to come up with a 'human readable format' first and then look at
mechanising it later. And though we might have a machine readable
format, we are a long way from making that machine *interpretable* -
that'll have to wait for the ontology, I think.
But, validation is also a very useful tool.  The language is complicated enough that one can easily write down a query in short hand and it looks about right, but a validator immediately points out the inconsistency and actually suggests alternative designs.  If you are not used to reading XML don't worry, I am almost at the point where I can generate an XSLT to transform it to a pretty web page.  I believe that the page can look something like this:
Begin Request
AND these constraints {
        Find me astronomical objects with following properties:
            AND these propererties {
                1. name:  is assigned to var1
                2. class is "cluster of galaxies | galaxy cluster"
                3. Measurement quantities satisfy:
                        a. X-ray brightness > 3.3E7 :  assign value to var2
                            A. Time of measurement in interval "12:23:1998" to "1:14:1999"      
                        b etc
         }
         Using the above variables satisfy the following mathematical expressions{
                1. var2 < (var3 - var4)

        }
        OR these constraints {
           [some constraints for wich 1 must be true etc ]
        }
}
Please return a table with the following columns in order
  var1     var2     var3
End Request

  Meanwhile, let me know if the attached postscript file is any easier to read. 
Cheers,
Tony. 

  
-----Original Message-----
From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] 
Sent: 04 March 2003 23:19
To: ael@star.le.ac.uk; voql; metadata
Subject: Re: Splitting VOQL up


Tony,

    Overall the scheme looks fine.  Just a few points.
1) In the diagram the arrow to the Ontology should come back to the 
Problem Assistant.  I doubt that there needs to be a line 
from ontology 
to Workflow directly.
2)  The RQL will probably also been in XML for extensibility and 
transformation purposes.
3) After Registry, before Workflow submits, it probably needs 
to go to 
the human again because there may be more than 1 way to solve the 
problem and they would be of differing levels of completeness.  These 
various paths may not be be obvious until the registry is searched.
4) One needs a final analsysis of the logic and math of the problem 
after all queries have been resolved.
5)  I think what you call the Problem Statement Languate (PSL) can in 
fact be mostly separated from a specific ontology or metadata 
language, 
as Ray pointed out.  This is clearly important because one 
does not want 
all software to be rewritten when there is a change in the 
ontology or 
metadata arrangement.  In fact in each of the VOQL "Languages" there 
needs to be such an effort of independence from the rapidly changing 
part of the problem (otherwise you never finish).

The way to do this by keeping to abstract types of objects and 
properties on everything.  For the  PSL, the language merely needs to 
express that there are objects with properties.  These 
properties have 
names and values and query return to variables.  The values can be 
numeric, string, or bags of other objects.  The query return 
variables 
can be constants or depend on other variables.  The  other 
parts of the 
VOQL will probably break down similarly.  

There will be families of properties that resolve in the later stages 
(workflow etc) in very similar ways, so property families can 
be formed. 
 Once a usefully large set of property families are listed, 
the software 
development could begin.  That is, there could be a realizable system 
that would respond to some subset of queries that is independent of 
specifics of ontologies.

 An early design of VOQL can inform us on both metadata that 
needs to be 
available at registries and the level and direction of ontological 
development needed.  Once the NVO science queries are in a consistent 
machine readable format, requirements on the metadata and 
ontology will 
be clearer.  That is not to detract from the effort that has already 
gone on in reducing the science queries into requirements.  
It is just 
time to reach the next level of this analysis.

Ed
--------------040209090306070105000801-- --------------010907070504070905090103 Content-Type: application/postscript; name="useCase1.ps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="useCase1.ps" %!PS-Adobe-3.0 %%Title: useCase1 %%Creator: PScript5.dll Version 5.2 %%CreationDate: 3/5/2003 12:0:14 %%For: shaya %%BoundingBox: (atend) %%Pages: (atend) %%Orientation: Landscape %%PageOrder: Special %%DocumentNeededResources: (atend) %%DocumentSuppliedResources: (atend) %%DocumentData: Clean7Bit %%TargetDevice: (LaserJet 4) (2011.110) 1 %%LanguageLevel: 2 %%EndComments %%BeginDefaults %%PageBoundingBox: 15 13 597 780 %%ViewingOrientation: 0 1 -1 0 %%EndDefaults %%BeginProlog %%BeginResource: file Pscript_WinNT_ErrorHandler 5.0 0 /currentpacking where{pop/oldpack currentpacking def/setpacking where{pop false setpacking}if}if/$brkpage 64 dict def $brkpage begin/prnt{dup type/stringtype ne{=string cvs}if dup length 6 mul/tx exch def/ty 10 def currentpoint/toy exch def/tox exch def 1 setgray newpath tox toy 2 sub moveto 0 ty rlineto tx 0 rlineto 0 ty neg rlineto closepath fill tox toy moveto 0 setgray show}bind def /nl{currentpoint exch pop lmargin exch moveto 0 -10 rmoveto}def/=={/cp 0 def typeprint nl}def/typeprint{dup type exec}readonly def/lmargin 72 def/rmargin 72 def/tprint{dup length cp add rmargin gt{nl/cp 0 def}if dup length cp add/cp exch def prnt}readonly def/cvsprint{=string cvs tprint( )tprint}readonly def /integertype{cvsprint}readonly def/realtype{cvsprint}readonly def/booleantype {cvsprint}readonly def/operatortype{(--)tprint =string cvs tprint(-- )tprint} readonly def/marktype{pop(-mark- )tprint}readonly def/dicttype{pop (-dictionary- )tprint}readonly def/nulltype{pop(-null- )tprint}readonly def /filetype{pop(-filestream- )tprint}readonly def/savetype{pop(-savelevel- ) tprint}readonly def/fonttype{pop(-fontid- )tprint}readonly def/nametype{dup xcheck not{(/)tprint}if cvsprint}readonly def/stringtype{dup rcheck{(\()tprint tprint(\))tprint}{pop(-string- )tprint}ifelse}readonly def/arraytype{dup rcheck {dup xcheck{({)tprint{typeprint}forall(})tprint}{([)tprint{typeprint}forall(]) tprint}ifelse}{pop(-array- )tprint}ifelse}readonly def/packedarraytype{dup rcheck{dup xcheck{({)tprint{typeprint}forall(})tprint}{([)tprint{typeprint} forall(])tprint}ifelse}{pop(-packedarray- )tprint}ifelse}readonly def/courier /Courier findfont 10 scalefont def end errordict/handleerror{systemdict begin $error begin $brkpage begin newerror{/newerror false store vmstatus pop pop 0 ne{grestoreall}if errorname(VMerror)ne{showpage}if initgraphics courier setfont lmargin 720 moveto errorname(VMerror)eq{userdict/ehsave known{clear userdict /ehsave get restore 2 vmreclaim}if vmstatus exch pop exch pop PrtVMMsg}{ (ERROR: )prnt errorname prnt nl(OFFENDING COMMAND: )prnt/command load prnt $error/ostack known{nl nl(STACK:)prnt nl nl $error/ostack get aload length{==} repeat}if}ifelse systemdict/showpage get exec(%%[ Error: )print errorname =print(; OffendingCommand: )print/command load =print( ]%%)= flush}if end end end}dup 0 systemdict put dup 4 $brkpage put bind readonly put/currentpacking where{pop/setpacking where{pop oldpack setpacking}if}if %%EndResource userdict /Pscript_WinNT_Incr 230 dict dup begin put %%BeginResource: file Pscript_FatalError 5.0 0 userdict begin/FatalErrorIf{{initgraphics findfont 1 index 0 eq{exch pop}{dup length dict begin{1 index/FID ne{def}{pop pop}ifelse}forall/Encoding {ISOLatin1Encoding}stopped{StandardEncoding}if def currentdict end /ErrFont-Latin1 exch definefont}ifelse exch scalefont setfont counttomark 3 div cvi{moveto show}repeat showpage quit}{cleartomark}ifelse}bind def end %%EndResource userdict begin/PrtVMMsg{vmstatus exch sub exch pop gt{[ (This job requires more memory than is available in this printer.)100 500 (Try one or more of the following, and then print again:)100 485 (For the output format, choose Optimize For Portability.)115 470 (In the Device Settings page, make sure the Available PostScript Memory is accurate.) 115 455(Reduce the number of fonts in the document.)115 440 (Print the document in parts.)115 425 12/Times-Roman showpage (%%[ PrinterError: Low Printer VM ]%%)= true FatalErrorIf}if}bind def end version cvi 2016 ge{/VM?{pop}bind def}{/VM? userdict/PrtVMMsg get def}ifelse 105000 VM? %%BeginResource: file Pscript_Win_Basic 5.0 0 /d/def load def/,/load load d/~/exch , d/?/ifelse , d/!/pop , d/`/begin , d/^ /index , d/@/dup , d/+/translate , d/$/roll , d/U/userdict , d/M/moveto , d/- /rlineto , d/&/currentdict , d/:/gsave , d/;/grestore , d/F/false , d/T/true , d/N/newpath , d/E/end , d/Ac/arc , d/An/arcn , d/A/ashow , d/D/awidthshow , d/C /closepath , d/V/div , d/O/eofill , d/L/fill , d/I/lineto , d/-c/curveto , d/-M /rmoveto , d/+S/scale , d/Ji/setfont , d/Lc/setlinecap , d/Lj/setlinejoin , d /Lw/setlinewidth , d/Lm/setmiterlimit , d/sd/setdash , d/S/show , d/LH/showpage , d/K/stroke , d/W/widthshow , d/R/rotate , d/L2? false/languagelevel where{pop languagelevel 2 ge{pop true}if}if d L2?{/xS/xshow , d/yS/yshow , d/zS/xyshow , d}if/b{bind d}bind d/bd{bind d}bind d/xd{~ d}bd/ld{, d}bd/bn/bind ld/lw/Lw ld /lc/Lc ld/lj/Lj ld/sg/setgray ld/ADO_mxRot null d/self & d/OrgMx matrix currentmatrix d/reinitialize{: OrgMx setmatrix[/TextInit/GraphInit/UtilsInit counttomark{@ where{self eq}{F}?{cvx exec}{!}?}repeat cleartomark ;}b /initialize{`{/Pscript_Win_Data where{!}{U/Pscript_Win_Data & put}?/ADO_mxRot ~ d/TextInitialised? F d reinitialize E}{U/Pscript_Win_Data 230 dict @ ` put /ADO_mxRot ~ d/TextInitialised? F d reinitialize}?}b/terminate{!{& self eq {exit}{E}?}loop E}b/suspend/terminate , d/resume{` Pscript_Win_Data `}b U ` /lucas 21690 d/featurebegin{countdictstack lucas[}b/featurecleanup{stopped {cleartomark @ lucas eq{! exit}if}loop countdictstack ~ sub @ 0 gt{{E}repeat} {!}?}b E/snap{transform 0.25 sub round 0.25 add ~ 0.25 sub round 0.25 add ~ itransform}b/dsnap{dtransform round ~ round ~ idtransform}b/nonzero_round{@ 0.5 ge{round}{@ -0.5 lt{round}{0 ge{1}{-1}?}?}?}b/nonzero_dsnap{dtransform nonzero_round ~ nonzero_round ~ idtransform}b U<04>cvn{}put/rr{1 ^ 0 - 0 ~ - neg 0 - C}b/irp{4 -2 $ + +S fx 4 2 $ M 1 ^ 0 - 0 ~ - neg 0 -}b/rp{4 2 $ M 1 ^ 0 - 0 ~ - neg 0 -}b/solid{[]0 sd}b/g{@ not{U/DefIf_save save put}if U/DefIf_bool 2 ^ put}b/DefIf_El{if U/DefIf_bool get not @{U/DefIf_save get restore}if}b/e {DefIf_El !}b/UDF{L2?{undefinefont}{!}?}b/UDR{L2?{undefineresource}{! !}?}b /freeVM{/Courier findfont[40 0 0 -40 0 0]makefont Ji 2 vmreclaim}b/hfRedefFont {findfont @ length dict `{1 ^/FID ne{d}{! !}?}forall & E @ ` ~{/CharStrings 1 dict `/.notdef 0 d & E d}if/Encoding 256 array 0 1 255{1 ^ ~/.notdef put}for d E definefont !}bind d/hfMkCIDFont{/CIDFont findresource @ length 2 add dict `{1 ^ @/FID eq ~ @/XUID eq ~/UIDBase eq or or{! !}{d}?}forall/CDevProc ~ d/Metrics2 16 dict d/CIDFontName 1 ^ d & E 1 ^ ~/CIDFont defineresource ![~]composefont !} bind d %%EndResource %%BeginResource: file Pscript_Win_Utils_L2 5.0 0 /rf/rectfill , d/fx{1 1 dtransform @ 0 ge{1 sub 0.5}{1 add -0.5}? 3 -1 $ @ 0 ge {1 sub 0.5}{1 add -0.5}? 3 1 $ 4 1 $ idtransform 4 -2 $ idtransform}b/BZ{4 -2 $ snap + +S fx rf}b/rs/rectstroke , d/rc/rectclip , d/UtilsInit{currentglobal{F setglobal}if}b/scol{! setcolor}b/colspA/DeviceGray d/colspABC/DeviceRGB d /colspRefresh{colspABC setcolorspace}b/SetColSpace{colspABC setcolorspace}b /resourcestatus where{!/ColorRendering/ProcSet resourcestatus{! ! T}{F}?}{F}? not{/ColorRendering<>/defineresource where{!/ProcSet defineresource !}{! !}?}if/buildcrdname{/ColorRendering/ProcSet findresource ` mark GetHalftoneName @ type @/nametype ne ~/stringtype ne and{!/none}if(.) GetPageDeviceName @ type @/nametype ne ~/stringtype ne and{!/none}if(.)5 ^ 0 5 -1 1{^ length add}for string 6 1 $ 5 ^ 5{~ 1 ^ cvs length 1 ^ length 1 ^ sub getinterval}repeat ! cvn 3 1 $ ! ! E}b/definecolorrendering{~ buildcrdname ~ /ColorRendering defineresource !}b/findcolorrendering where{!}{ /findcolorrendering{buildcrdname @/ColorRendering resourcestatus{! ! T}{ /ColorRendering/ProcSet findresource ` GetSubstituteCRD E F}?}b}? /selectcolorrendering{findcolorrendering !/ColorRendering findresource setcolorrendering}b/G2UBegin{findresource/FontInfo get/GlyphNames2Unicode get `}bind d/G2CCBegin{findresource/FontInfo get/GlyphNames2HostCode get `}bind d /G2UEnd{E}bind d/AddFontInfoBegin{/FontInfo 8 dict @ `}bind d/AddFontInfo{ /GlyphNames2Unicode 16 dict d/GlyphNames2HostCode 16 dict d}bind d /AddFontInfoEnd{E d}bind d/T0AddCFFMtx2{/CIDFont findresource/Metrics2 get ` d E}bind d %%EndResource end %%EndProlog %%BeginSetup statusdict begin (%%[ ProductName: ) print product print ( ]%%)= flush end [ 0 1 -1 0 0 0 ] false Pscript_WinNT_Incr dup /initialize get exec featurebegin{ %%BeginNonPPDFeature: JobTimeout 0 0 /languagelevel where{pop languagelevel}{1}ifelse 2 ge{1 dict dup/JobTimeout 4 -1 roll put setuserparams}{statusdict/setjobtimeout get exec}ifelse %%EndNonPPDFeature }featurecleanup featurebegin{ %%BeginNonPPDFeature: WaitTimeout 300 300 /languagelevel where{pop languagelevel}{1}ifelse 2 ge{1 dict dup/WaitTimeout 4 -1 roll put setuserparams}{statusdict/waittimeout 3 -1 roll put}ifelse %%EndNonPPDFeature }featurecleanup featurebegin{ %%BeginFeature: *PageSize Letter 1 dict dup /Policies 2 dict dup /PageSize 2 put dup /MediaType 0 put put setpagedevice 2 dict dup /PageSize [612 792] put dup /ImagingBBox null put setpagedevice %%EndFeature }featurecleanup featurebegin{ %%BeginFeature: *Option1 False %%EndFeature }featurecleanup featurebegin{ %%BeginFeature: *Option2 False %%EndFeature }featurecleanup featurebegin{ %%BeginFeature: *Resolution 300dpi %%EndFeature }featurecleanup 1 setlinecap 1 setlinejoin /mysetup [ 0 72 300 V 72 300 V 0 15.00094 12.99968 ] def %%EndSetup userdict begin /ehsave save def end %%Page: 1 1 %%PageBoundingBox: 15 13 597 780 %%EndPageComments %%BeginPageSetup /DeviceRGB dup setcolorspace /colspABC exch def mysetup concat colspRefresh %%EndPageSetup Pscript_WinNT_Incr begin %%BeginResource: file Pscript_Win_Dib_L2 5.0 0 /iw 0 d/ih 0 d/im_save 0 d/s 0 d/polarity 0 d/smoothflag 0 d/mystring 0 d/bpc 0 d/maskcolor 0 d/mask? F d/setup1asciiproc{[currentfile mystring/readhexstring cvx/! cvx]cvx bind}b/setup1binaryproc{[currentfile mystring/readstring cvx/! cvx]cvx bind}b/setup2asciiproc{currentfile/ASCII85Decode filter/RunLengthDecode filter}b/setup2binaryproc{currentfile/RunLengthDecode filter}b/jpegasciiproc {currentfile/ASCII85Decode filter<>/DCTDecode filter}b/jpegbinaryproc {currentfile<>/DCTDecode filter}b/mycolorspace{colspABC}d/myimagedict {/myimagedict 10 dict d myimagedict @ `/ImageType 1 d/MultipleDataSource F d E} b/imageprocarray[/setup1binaryproc/setup1asciiproc/setup2binaryproc /setup2asciiproc/setup1binarydecodeproc/setup1asciidecodeproc]d/jpegprocarray[ /jpegasciiproc/jpegbinaryproc]d/Q{/im_save save d scol imageprocarray ~ get/s ~ , d/polarity ~ d/smoothflag ~ d +/dx 2 ^ d/dy 1 ^ d +S/mystring ~ string d/bpc ~ d/ih ~ d/iw ~ d fx rf}b/X{/im_save save d/mask? ~ d/maskcolor ~ d imageprocarray ~ get/s ~ , d/polarity ~ d/smoothflag ~ d +/dx 2 ^ d/dy 1 ^ d +S /mystring ~ string d/bpc ~ d/ih ~ d/iw ~ d}b/Z{im_save restore}b/beginjpeg{ /jpeg_save save d jpegprocarray ~ get/jpegimageproc ~ , d + +S/bpc ~ d/ih ~ d /iw ~ d bpc 24 eq{/DeviceRGB}{/DeviceGray}? setcolorspace myimagedict @ ` /ImageType 1 d/Width iw d/Height ih d/Decode bpc 24 eq{[0 1 0 1 0 1]}{[0 1]}? d /ImageMatrix[iw 0 0 ih 0 0]d/BitsPerComponent 8 d/DataSource jpegimageproc d E image}b/endjpeg{jpeg_save restore}b/Y{scol myimagedict @ ` mask?{/polarity maskcolor 0 get 0 eq{T}{F}? d}if/Width iw d/Height ih d/Decode polarity{[1 0]}{ [0 1]}? d/ImageMatrix[iw 0 0 ih 0 0]d/DataSource s d/BitsPerComponent 1 d /Interpolate smoothflag d E imagemask}bd/doclutimage{/rgbclut ~ d bpc @ 8 eq{! 255}{@ 4 eq{! 15}{2 eq{3}{1}?}?}?/hival ~ d[/Indexed currentcolorspace hival rgbclut]setcolorspace myimagedict @ ` mask?{/ImageType 4 d/MaskColor maskcolor d}if/Width iw d/Height ih d/Decode[0 hival]d/ImageMatrix[iw 0 0 ih 0 0]d /DataSource s d/BitsPerComponent bpc d/Interpolate smoothflag d E image}b /doCMYKclutimage{/CMYKclut ~ d bpc @ 8 eq{! 255}{4 eq{15}{3}?}?/hival ~ d[ /Indexed/DeviceCMYK hival CMYKclut]setcolorspace myimagedict @ ` mask?{ /ImageType 4 d/MaskColor maskcolor d}if/Width iw d/Height ih d/Decode[0 hival]d /ImageMatrix[iw 0 0 ih 0 0]d/DataSource s d/BitsPerComponent bpc d/Interpolate smoothflag d E image}b/doNimage{bpc 24 eq{currentcolorspace}{colspA}? setcolorspace myimagedict @ ` mask?{/ImageType 4 d/MaskColor maskcolor d}if /Width iw d/Height ih d/Decode bpc 24 eq{[0 1 0 1 0 1]}{[0 1]}? d/ImageMatrix [iw 0 0 ih 0 0]d/DataSource s d/BitsPerComponent bpc 24 eq{8}{bpc}? d /Interpolate smoothflag d E image}b/doCMYKimage{/DeviceCMYK setcolorspace myimagedict @ ` mask?{/ImageType 4 d/MaskColor maskcolor d}if/Width iw d/Height ih d/Decode[0 1 0 1 0 1 0 1]d/ImageMatrix[iw 0 0 ih 0 0]d/DataSource s d /BitsPerComponent 8 d/Interpolate smoothflag d E image}b %%EndResource end reinitialize /DeviceGray dup setcolorspace /colspABC exch def : 550 348 8 550 172 109 1509 0 F F 3 [ 0 ] F X doNimage JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$qZ#aZJcC<$qu;6IK)aI' JcCB&JcCN*c2`FqM#W&+MuUcsJcC]/JcCf2^&W`aOT0n3PQ/&kJcCu7JcD&9YQ07SQiDX:R/a5f JcD/V>u2ISH"0?T)YG`JcDABJcDDCS,e-?U&T]DUApS\JcDMFJcDPGPQ6:7V>l,HVZ2_X JcDYJJcD\KMu\G/WW.PLWrIkTJcDeNJcDhOKE-T'XoEtPXoEtQJcDnQJcDqRJH5ZLJcDtSJcE"T JH5NHJcE%UJcE%UJH5HFJcE(VJcE+WJH5CCX8qqnec::$d/S[sd/Vc!mJjNnmJki>JcF-tJcF*s gApI;\cCsogAlg)dJndtdJqu%jSupojT"!8JcF0uJcF0uh#QF6^]bCn h>c=3JcF7"JcF4!hZ2F2`W4cnhZ/6-eGk+"eGnD+g&K+ng&Kq0JcF:#JcF:#hZ2:.aoL&nhZ/6- f)L=$ec4P-ec3hnec4P-JcF=$JcF=$huM7+c2c>nhuJ?.fDgF%fDjb/dJqPndJr,)JcFC&JcF@% huM.(dK%Vni;eH/f`-O&f`0k0cMuAoli6b\m/PuDJcFF'JcFC&i;h+%ec>+;o)S4Yi;eH/g&HX' g&Kt1bQ$2pmf2_UnGhDHJcFI(JcFI(huLn!g&UUAlN$JThuJ?.g])j)gAg(2aT(#qn,MVPo)IVJ JcFL)JcFL)huLdsh>m$Ek5b)QhuJ?.h#Ds*g]-13`W+irn,MJLoDd_KJcFO*JcFO*hZ1UpiW/HI j8efOhZ/6-h>`'+h#H:4_Z/Zsn,MAIoDd_KJcFR+JcFR+hZ1LmjoFlMi;iKLhZ/6-hZ&0,h>c@4 _#NTun,M8Fo`*eKJcFU,JcFU,h>k=jl2^;Qh>m3Jh>i-,huA9-hZ)F4^AmO"n,M2DoDd\JJcFX- JcFX-h>k4gmJu_UgApmGh>i-,i;\B.huDO5]Dq@#n,M)Ao`*bJJcF[.JcF[.h#P%dnc8.Yf`:[E h#N$+iW"K/i;_U5\c;:%n,M#?o`*_IJcF^/JcF^/g]4kap&OR]f)YICg]2p*ir=T0iW%[5\,Z4' n,Lr=o`*\HJcFa0JcF^/g]4e_q>g!aeH#7Ag]2p*ir=T0ir@^4[f?7*n,Ll;o`*YGJcFd1JcFa0 g&SP\rW)Eee,].@g&Q^(j8X]1j8[d4[/U++n,Li:o`*SEJcFg2JcFd1f`7cHdK&q>f`6U'jSsf2 j8[d4U]8aBoDdJDJcFg2JcFg2f)VZId/`h=f)UC%jo9o3jT!g3VZ5$DoDdDBJcFj3JcFg2f)V`K d/`b;f)UC%jo9o3jo JcFm4JcFj3e,ZWNciEV9e,Y("k5U#4k5Wj0YQ)rLnc.#;JcFp5JcFm4dK$NOciES8dK"jukPp,5 k5Wg/ZN&8OnGgl9JcFp5JcFm4ciCHQciES8ciAXskPp,5kPrg-[f=\SnGgc6JcFs6JcFp5blG9R ciES8blE=pkl656kPra+])U+WnGg]4JcFs6JcFp5b5f3Td/`Y8b5d+nkl656kl8a)^AlR\n,LK0 JcG!7JcFs6a8j$Ud/`Y8a8gekl2Q>7kl8['_Z/!`n,LE.JcG!7JcFs6`W3sWd/`Y8`W1Sil2Q>7 kl8U%`rFEdn,L?,JcG!7JcG!7_Z7dXd/`Y8_Z58flMlG8l2SU#b5]ihn,L6)JcG$8JcG!7_#V^Z d/`Y8_#T&dlMlG8l2SO!cMu8ln,L0'JcG$8JcG!7^AuX\d/`Y8^AriblMlG8l2SHtdf7\pn,L*% JcG$8JcG!7]`?R^d/`Y8]`bn'n,KisJcG'9JcG$8[K,4b dK&b9[K(mYli2P9lMn6li;_7+n,KcqJcG'9JcG$8ZiK(be,\t;ZiG[Wli2P9lMn0jj8[U/n,K]o JcG'9JcG$8Z2itceH#(YQ07Sli2P9 lMn$fkPs07n,KQkJcG'9JcG$8YQ3hcfDt@>YQ07Sli2P9lMn*hjo.ln,L0' JcG$8JcG!7_#Va[ciEP7_#T&dlMlG8l2SU#bQ#ohn,L6)JcG$8JcG!7_Z7gYciEP7_Z58flMlG8 kl8U%a8aKdn,L?,JcG!7JcFs6`W4!XciEP7`W1Sil2Q>7kl8['_uJ'`n,LE.JcG!7JcFs6a8j'V ciEP7a8gekl2Q>7kl8a)^]2X\n,LK0JcG!7JcFs6aoK-TciEP7aoI"ml2Q>7kPra+]Dp4Xn,LT3 JcFs6JcFp5blG@Bg]2p*ir=T0i;_U5\Gu7&n,Lu>o`*_I JcF^/JcF[.h#P"coDn@[fDtRDh#N$+iW"K/i;_U5])V=$n,M&@o`*_IJcF^/JcFX-h>k1fn,VqW g&UdFh>i-,i;\B.huDO5]`7C"n,M,Bo`*bJJcF[.JcFU,h>k:ili?MSh#R*Ih>i-,huA9-hZ)F4 ^]3R!n,M5Eo`*bJJcFX-JcFR+hZ1IlkQ()OhZ3c@4_>iWtn,M>HoDd\JJcFU, JcFO*huLXoj8eZKiW/TMhuJ?.h>`'+h#H73`;efsn,MGKoDd\JJcFR+JcFL)huLarhuN6GjoFuP huJ?.h#Ds*g]-13`rFlqn,MPNo)IVJJcFO*JcFI(huLjug]6gCklC;ShuJ?.g])j)g&L"2aoC&p mf2YSnGhGIJcFI(JcFF'huLt#fDt@>mf;kWhuJ?.gAca(f`0n1bl?5omJlbXmf25GJcFF'JcFC& huM(&e,\h7q#Kd]huJ?.g&HX'fDjb/d/VMod/W#(JcFC&JcF=$huM4*ciDMohuJ?.fDgF%f)OY. e,R\ne,S>+JcF@%JcF:#huM=-bQ-2nhuJ?.f)L=$eGnG,fDitnfDjb/JcF:#JcF7"hZ2@0a8jon hZ/6-ec14#e,S8)h#G@oh#H42JcF7"JcF0uh>lI5_>rKnh>i-,e,P"!df8)&ir?doir@d6JcF4! JcF-tg]6I9]E%'ng]2p*df4mud/Vf"lMn?olMoQJcE4ZJcE.XJH56@JcE1Y JcE(VJH5BDJcE+WJcE%UJH5HFJcE(VJcDtSJH5TJJcE"TJcDnQJH,ZMJcDqRJcDkPJcLB%Y5a(Q X8dnSJcDhOJcD_LM?&5-WrIYMVuMbWJcD\KJcDSHOoU(5VZ25IU]6V[JcDPGJcDGDRK.p=UAofE TDtJ_JcDDCJcD;@U&]cET)XBARfB;dJcD5>JcD):XoO%QR/_a;PlJ)jJcD#8JcCl4\c@<]P5g+5 NrQlpJcCf2JcCW-a8gekMuSA.L&]R$JcCK)JcC<$s8UpUJcC<$!<7WMJcGECnc47@JcGHDJcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)Q2gLWJcC<$e,P"!Q2gLWJcFs6i;ei:JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6i;ei: JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!G o`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'mMoDnC\o`4jg blI54o`4R_i;iWPirJNIp&OU^p&OpgkQ$>:MuWDLoDeF_q>\S;o)J@_p&EkKp]'.Onc/:_nGi1^ q>]LUM>rJ5oDnRaoDn[da8kl4o`4^ch#R3Lh>m0Ip&OU^p&OpgiW+o:M?!2Jp]'jcp]&86p&F[b p]'"Kp]'"Kp&F^cnGi1^q>]CRN;n_6oDn^eoDnUb`W5`4o`4degAq!JgApsIp&OU^p&O.Qp&L*P L]?uHqu?9gp&E#3pAadcq#B(Kp]&qIp]'penGi1^iW&ZQNW4b5oDnjioDnO`p&Oabo`4^coDnXc o`4gfoDm_Io`4U`o)SRcp&OU^p&O%Np]-?SK`C]Fs8V]koDeLao`+Rap&F[bp]'mdq>^*fh#I$I nc/4]q>^-gnGi1^i;`QPNrOb3kQ(2Rp&Oabo`4Xap&Ojeo`4gfo`3eIo`4L]o`4gfp&OU^p&O%N p]-?SK)b*9nc/:_o`+Rao`+Ubp]'mdq>^*fh#I$In,N%\qZ$6hnGi1^iW&ZQNW4S0li?PTp&Oab o`4Xao`4deo`4gfo)RYIo`4I\o`4jgp&OU^p&O+PpAg3QJc>`Mmf;eUp&Oabo`4Xao`4deo`4gf hZ36Io`4F[p&Oshp&OU^p&Opgi;ei:JcGcMnGqtVp&Oabo`4Xao`4deo`4deh#R-Jo`4F[p&Osh p&OU^p&OpgiW+o:JcG`Lo)S.Wp&Oabo`4Xao`4deo`4adg]7*Ko`4F[p&Oshp&OU^p&OpgirFu: JcG`Lo)S.Wp&Oabo`4Xao`4deo`4^cg]7-Lo`4F[p&Oshp&OU^p&OpgjoC2:JcGcMnGqtVp&Oab o`4Xao`4deo`4Xah>m?No`4F[p&Oshp&OU^p&K[DjSsf2!<;Kfmf2t\o`+Rao`+Raq#C!emf2;I q>^*fn,N%\qZ$6hnGi1^JcFg2JcG*;n,N(]o`+Rao`+Raq#C!eh#I$Iq>^*fn,N%\qZ$6hnGi1^ JcFg2K)b-:nGi1^o`+Rao`+Raq#C!eg]-sIq>^*fn,N%\qZ$6hnGi1^JcFg2K`C38o)JC`o`+Ra o`+Raq#C!eg]-sIq>^*fnGi.]q>^-gnGi1^JcFg2L&^cFs8V]koDeLao`+Rao`+Raq#C!eg]-sI q>^*fo)J:]q>^*fnc/:_JcFg2LB$lGrVuKio`+Ubo`+Rao`+Raq#C!eh#I$Iq>^*fo`+I^p]'jc oDeLaJcFg2L]?uHqu?9gp&F^co`+Rao`+Raq#C!eq#B"Iq>].KpA`kIJcFg2M#[)Iq>^'epAagd o`+Rao`+Raq#C!eq#B%Jq#B(Ko`*\HJcFg2M?!2Jp]'jcp]'peo`+Rao`+Raq#C!eq#B(Kp]'"K o)IMGJcFg2MZ<;Kp&FXaq#C$fo`+Rao`+Raq#C!eq#B+LpA`tLn,M5EJcFg2MuWDLoDeF_q>^-g o`+Rao`+Raq#C!eq#B.Mp&EqMli5lCJcFg2N;rMMnc/4]qZ$6ho`+Rao`+Raq#C!eq#B7Po)IbN j8\0?JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j3/JcFd1JcC<$ d/Wb=_Z09/JcFd1JcC<$d/Wb=`W,K/JcFd1JcC<$d/Wb=g]-(0JcFa0JcC<$d/Wb=g]-+1JcF^/ JcC<$d/Wb=g]-.2JcF[.JcC<$d/Wb=g]-44JcFU,JcC<$d/Wb=g]-:6JcFO*JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)~> Z ; 0 0 scol Pscript_WinNT_Incr begin %%BeginResource: file Pscript_Text 5.0 0 /TextInit{TextInitialised? not{/Pscript_Windows_Font & d/TextInitialised? T d /fM[1 0 0 1 0 0]d/mFM matrix d/iMat[1 0 0.212557 1 0 0]d}if}b/copyfont{1 ^ length add dict `{1 ^/FID ne{d}{! !}?}forall & E}b/EncodeDict 11 dict d/bullets {{/bullet}repeat}b/rF{3 copyfont @ ` ~ EncodeDict ~ get/Encoding ~ 3 ^/0 eq{& /CharStrings known{CharStrings/Eth known not{! EncodeDict/ANSIEncodingOld get} if}if}if d E}b/mF{@ 7 1 $ findfont ~{@/Encoding get @ StandardEncoding eq{! T}{ {ISOLatin1Encoding}stopped{! F}{eq}?{T}{@ ` T 32 1 127{Encoding 1 ^ get StandardEncoding 3 -1 $ get eq and}for E}?}?}{F}?{1 ^ ~ rF}{0 copyfont}? 6 -2 $ ! ! ~ !/pd_charset @ where{~ get 128 eq{@ FDV 2 copy get @ length array copy put pd_CoverFCRange}if}{!}? 2 ^ ~ definefont fM 5 4 -1 $ put fM 4 0 put fM makefont Pscript_Windows_Font 3 1 $ put}b/sLT{: Lw -M currentpoint snap M 0 - 0 Lc K ;}b/xUP null d/yUP null d/uW null d/xSP null d/ySP null d/sW null d/sSU{N /uW ~ d/yUP ~ d/xUP ~ d}b/sU{xUP yUP uW sLT}b/sST{N/sW ~ d/ySP ~ d/xSP ~ d}b/sT {xSP ySP sW sLT}b/sR{: + R 0 0 M}b/sRxy{: matrix astore concat 0 0 M}b/eR/; , d /AddOrigFP{{&/FontInfo known{&/FontInfo get length 6 add}{6}? dict ` /WinPitchAndFamily ~ d/WinCharSet ~ d/OrigFontType ~ d/OrigFontStyle ~ d /OrigFontName ~ d & E/FontInfo ~ d}{! ! ! ! !}?}b/mFS{makefont Pscript_Windows_Font 3 1 $ put}b/mF42D{0 copyfont `/FontName ~ d 2 copy ~ sub 1 add dict `/.notdef 0 d 2 copy 1 ~{@ 3 ^ sub Encoding ~ get ~ d}for & E /CharStrings ~ d ! ! & @ E/FontName get ~ definefont}b/mF42{15 dict ` @ 4 1 $ FontName ~ d/FontType 0 d/FMapType 2 d/FontMatrix[1 0 0 1 0 0]d 1 ^ 254 add 255 idiv @ array/Encoding ~ d 0 1 3 -1 $ 1 sub{@ Encoding 3 1 $ put}for/FDepVector Encoding length array d/CharStrings 2 dict `/.notdef 0 d & E d 0 1 Encoding length 1 sub{@ @ 10 lt{! FontName length 1 add string}{100 lt{FontName length 2 add string}{FontName length 3 add string}?}? @ 0 FontName @ length string cvs putinterval @ 3 -1 $ @ 4 1 $ 3 string cvs FontName length ~ putinterval cvn 1 ^ 256 mul @ 255 add 3 -1 $ 4 ^ findfont mF42D FDepVector 3 1 $ put}for & @ E /FontName get ~ definefont ! ! ! mF}b/mF_OTF_V{~ ! ~ ! 4 -1 $ ! findfont 2 ^ ~ definefont fM @ @ 4 6 -1 $ neg put 5 0 put 90 matrix R matrix concatmatrix makefont Pscript_Windows_Font 3 1 $ put}b/mF_TTF_V{3{~ !}repeat 3 -1 $ ! findfont 1 ^ ~ definefont Pscript_Windows_Font 3 1 $ put}b/UmF{L2? {Pscript_Windows_Font ~ undef}{!}?}b/UmF42{@ findfont/FDepVector get{/FontName get undefinefont}forall undefinefont}b %%EndResource end reinitialize Pscript_WinNT_Incr begin %%BeginResource: file Pscript_Encoding256 5.0 0 /CharCol256Encoding[/.notdef/breve/caron/dotaccent/dotlessi/fi/fl/fraction /hungarumlaut/Lslash/lslash/minus/ogonek/ring/Zcaron/zcaron/.notdef/.notdef /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef /.notdef/.notdef/.notdef/.notdef/.notdef/space/exclam/quotedbl/numbersign /dollar/percent/ampersand/quotesingle/parenleft/parenright/asterisk/plus/comma /hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S /T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/grave /a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright /asciitilde/.notdef/Euro/.notdef/quotesinglbase/florin/quotedblbase/ellipsis /dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/.notdef /.notdef/.notdef/.notdef/quoteleft/quoteright/quotedblleft/quotedblright/bullet /endash/emdash/tilde/trademark/scaron/guilsinglright/oe/.notdef/.notdef /Ydieresis/.notdef/exclamdown/cent/sterling/currency/yen/brokenbar/section /dieresis/copyright/ordfeminine/guillemotleft/logicalnot/.notdef/registered /macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph /periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter /onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis /Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute /Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls /agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute /ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve /oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex /udieresis/yacute/thorn/ydieresis]def EncodeDict/256 CharCol256Encoding put %%EndResource end reinitialize %%IncludeResource: font Helvetica Pscript_WinNT_Incr begin %%BeginResource: file Pscript_Win_Euro_L2 5.0 0 /UseT3EuroFont{/currentdistillerparams where{pop currentdistillerparams /CoreDistVersion get 4000 le}{false}ifelse}bind def/NewEuroT3Font?{dup/FontType get 3 eq{dup/EuroFont known exch/BaseFont known and}{pop false}ifelse}bind def /T1FontHasEuro{dup/CharStrings known not{dup NewEuroT3Font?{dup/EuroGlyphName get exch/EuroFont get/CharStrings get exch known{true}{false}ifelse}{pop false} ifelse}{dup/FontType get 1 eq{/CharStrings get/Euro known}{dup/InfoDict known{ /InfoDict get/Euro known}{/CharStrings get/Euro known}ifelse}ifelse}ifelse}bind def/FontHasEuro{findfont dup/Blend known{pop true}{T1FontHasEuro}ifelse}bind def/EuroEncodingIdx 1 def/EuroFontHdr{12 dict begin/FontInfo 10 dict dup begin /version(001.000)readonly def/Notice(Copyright (c)1999 Adobe Systems Incorporated. All Rights Reserved.)readonly def/FullName(Euro)readonly def /FamilyName(Euro)readonly def/Weight(Regular)readonly def/isFixedPitch false def/ItalicAngle 0 def/UnderlinePosition -100 def/UnderlineThickness 50 def end readonly def/FontName/Euro def/Encoding 256 array 0 1 255{1 index exch/.notdef put}for def/PaintType 0 def/FontType 1 def/FontMatrix[0.001 0 0 0.001 0 0]def /FontBBox{-25 -23 1500 804}readonly def currentdict end dup/Private 20 dict dup begin/ND{def}def/NP{put}def/lenIV -1 def/RD{string currentfile exch readhexstring pop}def/-|{string currentfile exch readstring pop}executeonly def /|-{def}executeonly def/|{put}executeonly def/BlueValues[-20 0 706 736 547 572] |-/OtherBlues[-211 -203]|-/BlueScale 0.0312917 def/MinFeature{16 16}|-/StdHW [60]|-/StdVW[71]|-/ForceBold false def/password 5839 def/Erode{8.5 dup 3 -1 roll 0.1 mul exch 0.5 sub mul cvi sub dup mul 71 0 dtransform dup mul exch dup mul add le{pop pop 1.0 1.0}{pop pop 0.0 1.5}ifelse}def/OtherSubrs[{}{}{} {systemdict/internaldict known not{pop 3}{1183615869 systemdict/internaldict get exec dup/startlock known{/startlock get exec}{dup/strtlck known{/strtlck get exec}{pop 3}ifelse}ifelse}ifelse}executeonly]|-/Subrs 5 array dup 0 <8E8B0C100C110C110C210B>put dup 1<8B8C0C100B>put dup 2<8B8D0C100B>put dup 3<0B> put dup 4<8E8C8E0C100C110A0B>put |- 2 index/CharStrings 256 dict dup begin /.notdef<8b8b0d0e>def end end put put dup/FontName get exch definefont pop}bind def/AddEuroGlyph{2 index exch EuroEncodingIdx 1 eq{EuroFontHdr}if systemdict begin/Euro findfont dup dup/Encoding get 5 1 roll/Private get begin/CharStrings get dup 3 index known{pop pop pop pop end end}{begin 1 index exch def end end end EuroEncodingIdx dup 1 add/EuroEncodingIdx exch def exch put}ifelse}bind def /GetNewXUID{currentdict/XUID known{[7 XUID aload pop]true}{currentdict/UniqueID known{[7 UniqueID]true}{false}ifelse}ifelse}bind def/BuildT3EuroFont{exch 16 dict begin dup/FontName exch def findfont dup/Encoding get/Encoding exch def dup length 1 add dict copy dup/FID undef begin dup dup/FontName exch def /Encoding 256 array 0 1 255{1 index exch/.notdef put}for def GetNewXUID{/XUID exch def}if currentdict end definefont pop/BaseFont exch findfont 1000 scalefont def/EuroFont exch findfont 1000 scalefont def pop/EuroGlyphName exch def/FontType 3 def/FontMatrix[.001 0 0 .001 0 0]def/FontBBox BaseFont/FontBBox get def/Char 1 string def/BuildChar{exch dup begin/Encoding get 1 index get /Euro eq{BaseFont T1FontHasEuro{false}{true}ifelse}{false}ifelse{EuroFont setfont pop userdict/Idx 0 put EuroFont/Encoding get{EuroGlyphName eq{exit} {userdict/Idx Idx 1 add put}ifelse}forall userdict/Idx get}{dup dup Encoding exch get BaseFont/Encoding get 3 1 roll put BaseFont setfont}ifelse Char 0 3 -1 roll put Char stringwidth newpath 0 0 moveto Char true charpath flattenpath pathbbox setcachedevice 0 0 moveto Char show end}bind def currentdict end dup /FontName get exch definefont pop}bind def/AddEuroToT1Font{dup findfont dup length 10 add dict copy dup/FID undef begin/EuroFont 3 -1 roll findfont 1000 scalefont def CharStrings dup length 1 add dict copy begin/Euro{EuroFont setfont pop EuroGBBox aload pop setcachedevice 0 0 moveto EuroGName glyphshow} bind def currentdict end/CharStrings exch def GetNewXUID{/XUID exch def}if 3 1 roll/EuroGBBox exch def/EuroGName exch def currentdict end definefont pop}bind def/BuildNewFont{UseT3EuroFont{BuildT3EuroFont}{pop AddEuroToT1Font}ifelse}bind def/UseObliqueEuro{findfont/FontMatrix get dup 2 get 0 eq exch dup 0 get exch 3 get eq and UseT3EuroFont or}bind def %%EndResource end reinitialize 7500 VM? /Helvetica FontHasEuro not { /Euro.Helvetica [556 0 24 -19 541 703 ] AddEuroGlyph /Euro /Helvetica /Helvetica-Copy BuildNewFont } if F /F0 0 /256 T /Helvetica mF /F0S22 F0 [34.375 0 0 -34.375 0 0 ] mFS F0S22 Ji 0 66 M (I:\\NVO\\voql\\useCase1.xml)[9 9 9 25 23 26 9 17 18 18 7 9 19 17 18 25 18 17 18 19 9 16 27 0]xS 2918 66 M (0)S 2937 66 M (3)S 2956 66 M (/)S 2965 66 M (0)S 2984 66 M (5)S 3003 66 M (/)S 3012 66 M (0)S 3031 66 M (3)S 3050 66 M ( )S 3059 66 M (1)S 3078 66 M (1)S 3097 66 M (:)S 3106 66 M (5)S 3125 66 M (9)S 3144 66 M (:)S 3153 66 M (4)S 3172 66 M (7)S 0 2415 M (\2511998-2003 Altova GmbH http://www.xmlspy.com)[25 19 19 19 19 11 19 19 19 19 9 23 7 9 18 17 18 9 26 27 18 25 9 9 9 19 9 9 18 9 9 9 23 23 23 9 16 27 7 17 18 17 9 17 18 0]xS 3086 2415 M (P)S 3109 2415 M (a)S 3127 2415 M (g)S 3145 2415 M (e)S 3163 2415 M ( )S 3172 2415 M (1)S 1357 2415 M (Registered to Ed Shaya \(NASA\))[25 18 18 7 17 9 18 11 18 18 9 9 18 9 23 18 9 23 19 18 17 18 9 11 25 23 23 23 0]xS Pscript_WinNT_Incr begin %%BeginResource: file Pscript_Win_GdiObject 5.0 0 /SavedCTM null d/CTMsave{/SavedCTM SavedCTM currentmatrix d}b/CTMrestore {SavedCTM setmatrix}b/mp null d/ADO_mxRot null d/GDIHMatrix null d /GDIHPatternDict 22 dict d GDIHPatternDict `/PatternType 1 d/PaintType 2 d/Reps L2?{1}{5}? d/XStep 8 Reps mul d/YStep XStep d/BBox[0 0 XStep YStep]d/TilingType 1 d/PaintProc{` 1 Lw[]0 sd PaintData , exec E}b/FGnd null d/BGnd null d /HS_Horizontal{horiz}b/HS_Vertical{vert}b/HS_FDiagonal{fdiag}b/HS_BDiagonal {biag}b/HS_Cross{horiz vert}b/HS_DiagCross{fdiag biag}b/MaxXYStep XStep YStep gt{XStep}{YStep}? d/horiz{Reps{0 4 M XStep 0 - 0 8 +}repeat 0 -8 Reps mul + K}b /vert{Reps{4 0 M 0 YStep - 8 0 +}repeat 0 -8 Reps mul + K}b/biag{Reps{0 0 M MaxXYStep @ - 0 YStep neg M MaxXYStep @ - 0 8 +}repeat 0 -8 Reps mul + 0 YStep M 8 8 - K}b/fdiag{Reps{0 0 M MaxXYStep @ neg - 0 YStep M MaxXYStep @ neg - 0 8 +}repeat 0 -8 Reps mul + MaxXYStep @ M 8 -8 - K}b E/makehatch{4 -2 $/yOrg ~ d /xOrg ~ d GDIHPatternDict/PaintData 3 -1 $ put CTMsave GDIHMatrix setmatrix GDIHPatternDict matrix xOrg yOrg + mp CTMrestore ~ U ~ 2 ^ put}b/h0{/h0 /HS_Horizontal makehatch}b/h1{/h1/HS_Vertical makehatch}b/h2{/h2/HS_FDiagonal makehatch}b/h3{/h3/HS_BDiagonal makehatch}b/h4{/h4/HS_Cross makehatch}b/h5{/h5 /HS_DiagCross makehatch}b/GDIBWPatternMx null d/pfprep{save 8 1 $ /PatternOfTheDay 8 1 $ GDIBWPatternDict `/yOrg ~ d/xOrg ~ d/PaintData ~ d/yExt ~ d/Width ~ d/BGnd ~ d/FGnd ~ d/Height yExt RepsV mul d/mx[Width 0 0 Height 0 0]d E build_pattern ~ !}b/pfbf{/fEOFill ~ d pfprep hbf fEOFill{O}{L}? restore}b /GraphInit{GDIHMatrix null eq{/SavedCTM matrix d : ADO_mxRot concat 0 0 snap + : 0.48 @ GDIHPatternDict ` YStep mul ~ XStep mul ~ nonzero_dsnap YStep V ~ XStep V ~ E +S/GDIHMatrix matrix currentmatrix readonly d ; : 0.24 -0.24 +S GDIBWPatternDict ` Width Height E nonzero_dsnap +S/GDIBWPatternMx matrix currentmatrix readonly d ; ;}if}b %%EndResource %%BeginResource: file Pscript_Win_GdiObject_L2 5.0 0 /GDIBWPatternDict 25 dict @ `/PatternType 1 d/PaintType 1 d/RepsV 1 d/RepsH 1 d /BBox[0 0 RepsH 1]d/TilingType 1 d/XStep 1 d/YStep 1 d/Height 8 RepsV mul d /Width 8 d/mx[Width 0 0 Height neg 0 Height]d/FGnd null d/BGnd null d /SetBGndFGnd{BGnd null ne{BGnd aload ! scol BBox aload ! 2 ^ sub ~ 3 ^ sub ~ rf}if FGnd null ne{FGnd aload ! scol}if}b/PaintProc{` SetBGndFGnd RepsH{Width Height F mx PaintData imagemask Width 0 +}repeat E}b E d/mp/makepattern , d /build_pattern{CTMsave GDIBWPatternMx setmatrix/nupangle where{! nupangle -90 eq{nupangle R}if}if GDIBWPatternDict @ ` Width Height ne{Width Height gt{Width Height V 1}{1 Height Width V}? +S}if xOrg yOrg E matrix + mp CTMrestore}b/hbf {setpattern}b/hf{:/fEOFill ~ d ~ ! setpattern fEOFill{O}{L}? ;}b/pbf{: ! /fEOFill ~ d GDIBWPatternDict `/yOrg ~ d/xOrg ~ d/PaintData ~ d/OutputBPP ~ d /Height ~ d/Width ~ d/PaintType 1 d/PatternType 1 d/TilingType 1 d/BBox[0 0 Width Height]d/XStep Width d/YStep Height d/mx xOrg yOrg matrix + d 20 dict @ ` /ImageType 1 d/Width Width d/Height Height d/ImageMatrix[1 0 0 1 0 0]d /BitsPerComponent 8 d OutputBPP 24 eq{/Decode[0 1 0 1 0 1]d}{OutputBPP 8 eq{ /Decode[0 1]d}{/Decode[0 1 0 1 0 1 0 1]d}?}?/DataSource{PaintData}d E/ImageDict ~ d/PaintProc{` ImageDict image E}b & mx makepattern setpattern E fEOFill{O}{L} ? ;}b/mask_pbf{:/fEOFill ~ d 20 dict `/yOrg ~ d/xOrg ~ d/PaintData ~ d/Height ~ d/Width ~ d/PatternType 1 d/PaintType 2 d/TilingType 1 d/BBox[0 0 Width Height] d/XStep Width d/YStep Height d/mx xOrg yOrg matrix + d/PaintProc{` Width Height T 1 1 dtransform abs ~ abs ~ 0 0 3 -1 $ 0 0 6 array astore{PaintData}imagemask E}b & mx makepattern setpattern E fEOFill{O}{L}? ;}b %%EndResource end reinitialize N 0 81 M 1463 81 I K N 3191 81 M 1725 81 I K N 0 2375 M 3191 2375 I K 0.754 0 scol 1 Lj 1 Lc solid : 0 154 4 2161 rc N 0 157 M 0 2311 I : 2.969 2.969 +S K ; ; : 0 154 3170 7 rc N 0 157 M 3166 157 I : 2.969 2.969 +S K ; ; : N 15 169 27 146 rp C 0.91 0 scol L ; 1 0 scol N 15 315 M 15 169 I : 2.969 2.969 +S K ; N 15 169 M 42 169 I : 2.969 2.969 +S K ; 0.496 0 scol N 15 312 M 39 312 I : 2.969 2.969 +S K ; N 39 312 M 39 169 I : 2.969 2.969 +S K ; : N 12 166 33 3 rp C 0.91 0 scol L ; : N 12 315 33 3 rp C 0.91 0 scol L ; : N 12 169 3 146 rp C 0.91 0 scol L ; : N 42 169 3 146 rp C 0.91 0 scol L ; : N 3 160 9 164 rp C 1 0 scol L ; : N 45 160 5 164 rp C 1 0 scol L ; : N 3 160 47 6 rp C 1 0 scol L ; : N 3 318 47 6 rp C 1 0 scol L ; : N 27 178 M 27 181 I 24 181 I 24 184 I 21 184 I 21 187 I 18 187 I 18 190 I 39 190 I 39 187 I 36 187 I 36 184 I 33 184 I 33 181 I 30 181 I 30 178 I C eoclip : N 18 178 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 3 321 50 6 rc N 3 324 M 53 324 I : 2.969 2.969 +S K ; ; : N 50 160 3 164 rp C 1 0 scol L ; : N 53 160 3110 51 rp C 1 0 scol L ; 0 0 scol : 56 163 79 45 rc %%IncludeResource: font Helvetica-Oblique 7500 VM? /Helvetica-Oblique FontHasEuro not { /Euro.Helvetica-Oblique /Helvetica-Oblique UseObliqueEuro { [556 0 73 -19 674 703 ] } { [556 0 24 -19 541 703 ] } ifelse AddEuroGlyph /Euro /Helvetica-Oblique /Helvetica-Oblique-Copy BuildNewFont } if F /F1 0 /256 T /Helvetica-Oblique mF /F1S26 F1 [38.613 0 0 -38.613 0 0 ] mFS F1S26 Ji 56 199 M (XML)[26 31 0]xS ; 0.754 0 scol : 220 208 2946 6 rc N 223 211 M 3166 211 I : 2.969 2.969 +S K ; ; : 3160 160 6 54 rc N 3163 160 M 3163 214 I : 2.969 2.969 +S K ; ; 1 0 scol : 53 208 177 6 rc N 53 211 M 226 211 I : 2.969 2.969 +S K ; ; : N 53 214 173 53 rp C L ; : N 53 267 173 3 rp C L ; 0.754 0 scol : 223 214 6 56 rc N 226 214 M 226 270 I : 2.969 2.969 +S K ; ; : N 229 214 47 53 rp C 1 0 scol L ; : 232 217 44 38 rc : 16 13 8 16 47 38 232 217 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 264 50 6 rc N 229 267 M 279 267 I : 2.969 2.969 +S K ; ; : N 276 214 3 53 rp C 1 0 scol L ; : N 279 214 377 53 rp C 1 0 scol L ; 0 0 scol %%IncludeResource: font Helvetica-Bold 7500 VM? /Helvetica-Bold FontHasEuro not { /Euro.Helvetica-Bold [556 0 12 -19 563 710 ] <97F8C00DDBF7240378F70401F774EA01F803EA01F8EAF70401F8BBF9011571B141BE278B 08FB278B303173FB32085906642C05DB0676078B828C828B82086206632C05E506A8FB3A EC3EF71B8B08C18BC192B9A908F71407676C54754C8B083B8B6ED483C508F72C06B3EA05 FB5E06BB07F77106B3EA05FB91069AE5B2B9CC8B08C98BB26FA17408A07691828F830809 0E> AddEuroGlyph /Euro /Helvetica-Bold /Helvetica-Bold-Copy BuildNewFont } if F /F2 0 /256 T /Helvetica-Bold mF /F2S26 F2 [38.613 0 0 -38.613 0 0 ] mFS F2S26 Ji 282 253 M (version)[21 22 15 22 11 24 0]xS 0.754 0 scol : 279 264 380 6 rc N 279 267 M 659 267 I : 2.969 2.969 +S K ; ; : 653 214 6 56 rc N 656 214 M 656 270 I : 2.969 2.969 +S K ; ; : N 659 214 2504 53 rp C 1 0 scol L ; 0 0 scol /F0S26 F0 [38.613 0 0 -38.613 0 0 ] mFS F0S26 Ji 662 252 M (1.0)[22 11 0]xS 0.754 0 scol : 659 264 2507 6 rc N 659 267 M 3166 267 I : 2.969 2.969 +S K ; ; : 3160 214 6 56 rc N 3163 214 M 3163 270 I : 2.969 2.969 +S K ; ; : N 53 270 173 54 rp C 1 0 scol L ; : 53 321 176 6 rc N 53 324 M 229 324 I : 2.969 2.969 +S K ; ; : 223 270 6 57 rc N 226 270 M 226 327 I : 2.969 2.969 +S K ; ; : N 229 270 47 54 rp C 1 0 scol L ; : 232 273 44 39 rc : 16 13 8 16 47 39 232 273 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 321 50 6 rc N 229 324 M 279 324 I : 2.969 2.969 +S K ; ; : N 276 270 3 54 rp C 1 0 scol L ; : N 279 270 377 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 309 M (encoding)[22 24 22 24 24 11 24 0]xS 0.754 0 scol : 279 321 380 6 rc N 279 324 M 659 324 I : 2.969 2.969 +S K ; ; : 653 270 6 57 rc N 656 270 M 656 327 I : 2.969 2.969 +S K ; ; : N 659 270 2504 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 308 M (UTF-8)[28 23 24 13 0]xS 0.754 0 scol : 659 321 2507 6 rc N 659 324 M 3166 324 I : 2.969 2.969 +S K ; ; : 3160 270 6 57 rc N 3163 270 M 3163 327 I : 2.969 2.969 +S K ; ; : N 3 327 47 53 rp C 1 0 scol L ; : 6 330 44 38 rc : 16 13 8 16 47 38 6 330 F F 3 [ 0 ] F X doNimage nc/Ug!5SV-p](6ms%EC-q#CBo!5SV-!5SV-q>^Kps%EC-s%<@-qYpTr_#I%._#OF-!5SI2!<<'l s1eX7s%<@-s%<@ls%ECl!WTt89E+tk_#I%-_#I%._#OH7s% Z ; ; : 3 377 50 6 rc N 3 380 M 53 380 I : 2.969 2.969 +S K ; ; : N 50 327 3 53 rp C 1 0 scol L ; : N 53 327 173 53 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 56 366 M (Comm...)[28 22 33 33 11 11 0]xS 0.754 0 scol : 53 377 176 6 rc N 53 380 M 229 380 I : 2.969 2.969 +S K ; ; : 223 327 6 56 rc N 226 327 M 226 383 I : 2.969 2.969 +S K ; ; : N 229 327 2934 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 232 365 M ( edited with XMLSPY v5 rel. 3 U \(http://www.xmlspy.com\) by Ed Shaya \(NASA\) ) [11 22 22 9 11 22 22 11 29 9 11 22 11 25 33 22 26 26 25 11 19 22 11 13 22 9 11 11 22 11 28 11 13 22 11 11 22 11 11 11 29 29 29 11 18 33 9 19 22 19 11 20 22 33 13 11 22 19 11 26 22 11 26 22 22 19 22 11 13 28 26 26 26 13 0]xS 0.754 0 scol : 229 377 2937 6 rc N 229 380 M 3166 380 I : 2.969 2.969 +S K ; ; : 3160 327 6 56 rc N 3163 327 M 3163 383 I : 2.969 2.969 +S K ; ; : N 15 392 27 1922 rp C 0.91 0 scol L ; 1 0 scol : 12 389 7 1925 rc N 15 5771 M 15 392 I : 2.969 2.969 +S K ; ; N 15 392 M 42 392 I : 2.969 2.969 +S K ; 0.496 0 scol : 36 389 7 1925 rc N 39 5768 M 39 392 I : 2.969 2.969 +S K ; ; : N 12 389 33 3 rp C 0.91 0 scol L ; : N 12 392 3 1922 rp C 0.91 0 scol L ; : N 42 392 3 1922 rp C 0.91 0 scol L ; : N 3 383 9 1931 rp C 1 0 scol L ; : N 45 383 5 1931 rp C 1 0 scol L ; : N 3 383 47 6 rp C 1 0 scol L ; : N 27 401 M 27 404 I 24 404 I 24 407 I 21 407 I 21 410 I 18 410 I 18 413 I 39 413 I 39 410 I 36 410 I 36 407 I 33 407 I 33 404 I 30 404 I 30 401 I C eoclip : N 18 401 21 12 rp C 0 0 scol L ; ; : N 50 383 3 1931 rp C 1 0 scol L ; : N 53 383 3110 51 rp C 1 0 scol L ; 0 0 scol %%IncludeResource: font Helvetica-BoldOblique 7500 VM? /Helvetica-BoldOblique FontHasEuro not { /Euro.Helvetica-BoldOblique /Helvetica-BoldOblique UseObliqueEuro { [556 0 60 -19 695 710 ] } { [556 0 12 -19 563 710 ] <97F8C00DDBF7240378F70401F774EA01F803EA01F8EAF70401F8BBF9011571B141BE278B 08FB278B303173FB32085906642C05DB0676078B828C828B82086206632C05E506A8FB3A EC3EF71B8B08C18BC192B9A908F71407676C54754C8B083B8B6ED483C508F72C06B3EA05 FB5E06BB07F77106B3EA05FB91069AE5B2B9CC8B08C98BB26FA17408A07691828F830809 0E> } ifelse AddEuroGlyph /Euro /Helvetica-BoldOblique /Helvetica-BoldOblique-Copy BuildNewFont } if F /F3 0 /256 T /Helvetica-BoldOblique mF /F3S26 F3 [38.613 0 0 -38.613 0 0 ] mFS F3S26 Ji 56 421 M (ql:)[24 10 0]xS F2S26 Ji 104 422 M (request)[15 22 24 24 22 22 0]xS 0.754 0 scol : 220 431 2946 6 rc N 223 434 M 3166 434 I : 2.969 2.969 +S K ; ; : 3160 383 6 54 rc N 3163 383 M 3163 437 I : 2.969 2.969 +S K ; ; 1 0 scol : 53 431 177 6 rc N 53 434 M 226 434 I : 2.969 2.969 +S K ; ; : N 53 437 173 53 rp C L ; : N 53 490 173 3 rp C L ; 0.754 0 scol : 223 437 6 56 rc N 226 437 M 226 493 I : 2.969 2.969 +S K ; ; : N 229 437 47 53 rp C 1 0 scol L ; : 232 440 44 38 rc : 16 13 8 16 47 38 232 440 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 487 50 6 rc N 229 490 M 279 490 I : 2.969 2.969 +S K ; ; : N 276 437 3 53 rp C 1 0 scol L ; : N 279 437 377 53 rp C 1 0 scol L ; 0 0 scol 282 476 M (xmlns:)[22 35 11 24 22 0]xS F3S26 Ji 410 475 M (ql)[24 0]xS 0.754 0 scol : 279 487 380 6 rc N 279 490 M 659 490 I : 2.969 2.969 +S K ; ; : 653 437 6 56 rc N 656 437 M 656 493 I : 2.969 2.969 +S K ; ; : N 659 437 2504 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 475 M (http://www.us-vo.org/ql)[22 11 11 22 11 11 11 29 29 29 11 22 19 13 19 22 11 22 13 22 11 22 0]xS 0.754 0 scol : 659 487 2507 6 rc N 659 490 M 3166 490 I : 2.969 2.969 +S K ; ; : 3160 437 6 56 rc N 3163 437 M 3163 493 I : 2.969 2.969 +S K ; ; : N 53 493 173 54 rp C 1 0 scol L ; : N 53 547 173 3 rp C 1 0 scol L ; : 223 493 6 57 rc N 226 493 M 226 550 I : 2.969 2.969 +S K ; ; : N 229 493 47 54 rp C 1 0 scol L ; : 232 496 44 39 rc : 16 13 8 16 47 39 232 496 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 544 50 6 rc N 229 547 M 279 547 I : 2.969 2.969 +S K ; ; : N 276 493 3 54 rp C 1 0 scol L ; : N 279 493 377 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 532 M (xmlns:)[22 35 11 24 22 0]xS F3S26 Ji 410 531 M (c)S 0.754 0 scol : 279 544 380 6 rc N 279 547 M 659 547 I : 2.969 2.969 +S K ; ; : 653 493 6 57 rc N 656 493 M 656 550 I : 2.969 2.969 +S K ; ; : N 659 493 2504 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 531 M (http://www.us-vo.org/spaceTime)[22 11 11 22 11 11 11 29 29 29 11 22 19 13 19 22 11 22 13 22 11 19 22 22 20 22 23 9 33 0]xS 0.754 0 scol : 659 544 2507 6 rc N 659 547 M 3166 547 I : 2.969 2.969 +S K ; ; : 3160 493 6 57 rc N 3163 493 M 3163 550 I : 2.969 2.969 +S K ; ; : N 53 550 173 53 rp C 1 0 scol L ; : N 53 603 173 3 rp C 1 0 scol L ; : 223 550 6 56 rc N 226 550 M 226 606 I : 2.969 2.969 +S K ; ; : N 229 550 47 53 rp C 1 0 scol L ; : 232 552 44 39 rc : 16 13 8 16 47 39 232 552 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 600 50 6 rc N 229 603 M 279 603 I : 2.969 2.969 +S K ; ; : N 276 550 3 53 rp C 1 0 scol L ; : N 279 550 377 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 589 M (xmlns:)[22 35 11 24 22 0]xS F3S26 Ji 410 588 M (siap)[22 11 22 0]xS 0.754 0 scol : 279 600 380 6 rc N 279 603 M 659 603 I : 2.969 2.969 +S K ; ; : 653 550 6 56 rc N 656 550 M 656 606 I : 2.969 2.969 +S K ; ; : N 659 550 2504 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 588 M (http://www.us-vo.org/SIAP)[22 11 11 22 11 11 11 29 29 29 11 22 19 13 19 22 11 22 13 22 11 26 11 26 0]xS 0.754 0 scol : 659 600 2507 6 rc N 659 603 M 3166 603 I : 2.969 2.969 +S K ; ; : 3160 550 6 56 rc N 3163 550 M 3163 606 I : 2.969 2.969 +S K ; ; : N 53 606 173 53 rp C 1 0 scol L ; : N 53 659 173 3 rp C 1 0 scol L ; : 223 606 6 56 rc N 226 606 M 226 662 I : 2.969 2.969 +S K ; ; : N 229 606 47 53 rp C 1 0 scol L ; : 232 609 44 39 rc : 16 13 8 16 47 39 232 609 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 656 50 6 rc N 229 659 M 279 659 I : 2.969 2.969 +S K ; ; : N 276 606 3 53 rp C 1 0 scol L ; : N 279 606 377 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 645 M (xmlns:)[22 35 11 24 22 0]xS : 410 609 56 44 rc F3S26 Ji 410 644 M (xsi)[22 22 0]xS ; 0.754 0 scol : 279 656 380 6 rc N 279 659 M 659 659 I : 2.969 2.969 +S K ; ; : 653 606 6 56 rc N 656 606 M 656 662 I : 2.969 2.969 +S K ; ; : N 659 606 2504 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 644 M (http://www.w3.org/2001/XMLSchema-instance)[22 11 11 22 11 11 11 29 29 29 11 29 22 11 22 13 22 11 22 22 22 22 11 25 33 22 26 20 22 22 33 22 13 9 22 19 11 22 22 20 0]xS 0.754 0 scol : 659 656 2507 6 rc N 659 659 M 3166 659 I : 2.969 2.969 +S K ; ; : 3160 606 6 56 rc N 3163 606 M 3163 662 I : 2.969 2.969 +S K ; ; : N 53 662 173 101 rp C 1 0 scol L ; : N 53 763 173 3 rp C 1 0 scol L ; : 223 662 6 104 rc N 226 662 M 226 766 I : 2.969 2.969 +S K ; ; : N 229 662 47 101 rp C 1 0 scol L ; : 232 665 44 39 rc : 16 13 8 16 47 39 232 665 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 229 760 50 6 rc N 229 763 M 279 763 I : 2.969 2.969 +S K ; ; : N 276 662 3 101 rp C 1 0 scol L ; : N 279 662 377 101 rp C 1 0 scol L ; 0 0 scol : 282 665 68 44 rc F3S26 Ji 282 700 M (xsi:)[22 22 11 0]xS ; F2S26 Ji 351 701 M (schemaLocati...)[22 22 24 22 35 22 24 24 22 22 13 11 11 11 0]xS 0.754 0 scol : 279 760 380 6 rc N 279 763 M 659 763 I : 2.969 2.969 +S K ; ; : 653 662 6 104 rc N 656 662 M 656 766 I : 2.969 2.969 +S K ; ; : N 659 662 2504 101 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 662 700 M (http://www.us-vo.org/ql)[22 11 11 22 11 11 11 29 29 29 11 22 19 13 19 22 11 22 13 22 11 22 0]xS 662 745 M (voql.xsd)[19 22 22 9 11 18 19 0]xS 0.754 0 scol : 659 760 2507 6 rc N 659 763 M 3166 763 I : 2.969 2.969 +S K ; ; : 3160 662 6 104 rc N 3163 662 M 3163 766 I : 2.969 2.969 +S K ; ; : N 53 766 173 51 rp C 1 0 scol L ; : N 53 817 173 3 rp C 1 0 scol L ; : 223 766 6 54 rc N 226 766 M 226 820 I : 2.969 2.969 +S K ; ; : N 241 775 26 1539 rp C 0.91 0 scol L ; 1 0 scol : 238 772 7 1542 rc N 241 4337 M 241 775 I : 2.969 2.969 +S K ; ; N 241 775 M 267 775 I : 2.969 2.969 +S K ; 0.496 0 scol : 261 772 7 1542 rc N 264 4334 M 264 775 I : 2.969 2.969 +S K ; ; : N 238 772 32 3 rp C 0.91 0 scol L ; : N 238 775 3 1539 rp C 0.91 0 scol L ; : N 267 775 3 1539 rp C 0.91 0 scol L ; : N 229 766 9 1548 rp C 1 0 scol L ; : N 270 766 6 1548 rp C 1 0 scol L ; : N 229 766 47 6 rp C 1 0 scol L ; : N 253 784 M 253 787 I 250 787 I 250 790 I 247 790 I 247 793 I 244 793 I 244 796 I 264 796 I 264 793 I 261 793 I 261 790 I 258 790 I 258 787 I 255 787 I 255 784 I C eoclip : N 244 784 20 12 rp C 0 0 scol L ; ; : N 276 766 3 1548 rp C 1 0 scol L ; : N 279 766 2884 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 805 M (andConstraints)[22 24 24 28 24 24 22 13 15 22 11 24 13 0]xS 0.754 0 scol : 650 814 2516 6 rc N 653 817 M 3166 817 I : 2.969 2.969 +S K ; ; : 3160 766 6 54 rc N 3163 766 M 3163 820 I : 2.969 2.969 +S K ; ; 1 0 scol : 279 814 381 6 rc N 279 817 M 656 817 I : 2.969 2.969 +S K ; ; : N 53 820 173 50 rp C L ; : N 53 870 173 3 rp C L ; 0.754 0 scol : 223 820 6 53 rc N 226 820 M 226 873 I : 2.969 2.969 +S K ; ; : N 279 820 377 50 rp C 1 0 scol L ; : N 279 870 377 3 rp C 1 0 scol L ; : 653 820 6 53 rc N 656 820 M 656 873 I : 2.969 2.969 +S K ; ; : N 671 829 27 1485 rp C 0.91 0 scol L ; 1 0 scol : 668 826 7 1488 rc N 671 3737 M 671 829 I : 2.969 2.969 +S K ; ; N 671 829 M 698 829 I : 2.969 2.969 +S K ; 0.496 0 scol : 692 826 7 1488 rc N 695 3734 M 695 829 I : 2.969 2.969 +S K ; ; : N 668 826 33 3 rp C 0.91 0 scol L ; : N 668 829 3 1485 rp C 0.91 0 scol L ; : N 698 829 3 1485 rp C 0.91 0 scol L ; : N 659 820 9 1494 rp C 1 0 scol L ; : N 701 820 6 1494 rp C 1 0 scol L ; : N 659 820 48 6 rp C 1 0 scol L ; : N 683 838 M 683 841 I 680 841 I 680 844 I 677 844 I 677 847 I 674 847 I 674 850 I 695 850 I 695 847 I 692 847 I 692 844 I 689 844 I 689 841 I 686 841 I 686 838 I C eoclip : N 674 838 21 12 rp C 0 0 scol L ; ; : N 707 820 3 1494 rp C 1 0 scol L ; : N 710 820 2453 50 rp C 1 0 scol L ; 0 0 scol : 713 823 218 44 rc 713 859 M (astroObject)[22 22 13 15 24 30 24 11 22 22 0]xS ; 0.754 0 scol : 817 867 2349 6 rc N 820 870 M 3166 870 I : 2.969 2.969 +S K ; ; : 3160 820 6 53 rc N 3163 820 M 3163 873 I : 2.969 2.969 +S K ; ; 1 0 scol : 710 867 117 6 rc N 710 870 M 823 870 I : 2.969 2.969 +S K ; ; : N 53 873 173 54 rp C L ; : N 53 927 173 3 rp C L ; 0.754 0 scol : 223 873 6 57 rc N 226 873 M 226 930 I : 2.969 2.969 +S K ; ; : N 279 873 377 54 rp C 1 0 scol L ; : N 279 927 377 3 rp C 1 0 scol L ; : 653 873 6 57 rc N 656 873 M 656 930 I : 2.969 2.969 +S K ; ; : N 710 873 113 54 rp C 1 0 scol L ; : N 710 927 113 3 rp C 1 0 scol L ; : 820 873 6 57 rc N 823 873 M 823 930 I : 2.969 2.969 +S K ; ; : N 826 873 47 54 rp C 1 0 scol L ; : 829 876 44 39 rc : 16 13 8 16 47 39 829 876 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 826 924 50 6 rc N 826 927 M 876 927 I : 2.969 2.969 +S K ; ; : N 873 873 3 54 rp C 1 0 scol L ; : N 876 873 122 54 rp C 1 0 scol L ; 0 0 scol 879 912 M (class)[22 11 22 22 0]xS 0.754 0 scol : 876 924 125 6 rc N 876 927 M 1001 927 I : 2.969 2.969 +S K ; ; : 995 873 6 57 rc N 998 873 M 998 930 I : 2.969 2.969 +S K ; ; : N 1001 873 2162 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1004 911 M (clusterOfGalaxies)[20 9 22 19 11 22 13 30 12 30 22 9 22 18 9 22 0]xS 0.754 0 scol : 1001 924 2165 6 rc N 1001 927 M 3166 927 I : 2.969 2.969 +S K ; ; : 3160 873 6 57 rc N 3163 873 M 3163 930 I : 2.969 2.969 +S K ; ; : N 53 930 173 50 rp C 1 0 scol L ; : N 53 980 173 3 rp C 1 0 scol L ; : 223 930 6 53 rc N 226 930 M 226 983 I : 2.969 2.969 +S K ; ; : N 279 930 377 50 rp C 1 0 scol L ; : N 279 980 377 3 rp C 1 0 scol L ; : 653 930 6 53 rc N 656 930 M 656 983 I : 2.969 2.969 +S K ; ; : N 710 930 113 50 rp C 1 0 scol L ; : N 710 980 113 3 rp C 1 0 scol L ; : 820 930 6 53 rc N 823 930 M 823 983 I : 2.969 2.969 +S K ; ; : N 838 939 26 1375 rp C 0.91 0 scol L ; 1 0 scol : 835 936 7 1378 rc N 838 3737 M 838 939 I : 2.969 2.969 +S K ; ; N 838 939 M 864 939 I : 2.969 2.969 +S K ; 0.496 0 scol : 858 936 7 1378 rc N 861 3734 M 861 939 I : 2.969 2.969 +S K ; ; : N 835 936 32 3 rp C 0.91 0 scol L ; : N 835 939 3 1375 rp C 0.91 0 scol L ; : N 864 939 3 1375 rp C 0.91 0 scol L ; : N 826 930 9 1384 rp C 1 0 scol L ; : N 867 930 6 1384 rp C 1 0 scol L ; : N 826 930 47 6 rp C 1 0 scol L ; : N 850 948 M 850 951 I 847 951 I 847 953 I 844 953 I 844 956 I 841 956 I 841 959 I 861 959 I 861 956 I 858 956 I 858 953 I 855 953 I 855 951 I 853 951 I 853 948 I C eoclip : N 841 948 20 11 rp C 0 0 scol L ; ; : N 873 930 3 1384 rp C 1 0 scol L ; : N 876 930 2287 50 rp C 1 0 scol L ; 0 0 scol : 879 933 264 44 rc F2S26 Ji 879 969 M (andProperties)[22 24 24 26 15 24 24 22 15 13 11 22 0]xS ; 0.754 0 scol : 992 977 2174 6 rc N 995 980 M 3166 980 I : 2.969 2.969 +S K ; ; : 3160 930 6 53 rc N 3163 930 M 3163 983 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 977 126 6 rc N 876 980 M 998 980 I : 2.969 2.969 +S K ; ; : N 53 983 173 51 rp C L ; : N 53 1034 173 3 rp C L ; 0.754 0 scol : 223 983 6 54 rc N 226 983 M 226 1037 I : 2.969 2.969 +S K ; ; : N 279 983 377 51 rp C 1 0 scol L ; : N 279 1034 377 3 rp C 1 0 scol L ; : 653 983 6 54 rc N 656 983 M 656 1037 I : 2.969 2.969 +S K ; ; : N 710 983 113 51 rp C 1 0 scol L ; : N 710 1034 113 3 rp C 1 0 scol L ; : 820 983 6 54 rc N 823 983 M 823 1037 I : 2.969 2.969 +S K ; ; : N 876 983 122 51 rp C 1 0 scol L ; : N 876 1034 122 3 rp C 1 0 scol L ; : 995 983 6 54 rc N 998 983 M 998 1037 I : 2.969 2.969 +S K ; ; : N 1013 992 27 202 rp C 0.91 0 scol L ; 1 0 scol N 1013 1194 M 1013 992 I : 2.969 2.969 +S K ; N 1013 992 M 1040 992 I : 2.969 2.969 +S K ; 0.496 0 scol N 1013 1191 M 1037 1191 I : 2.969 2.969 +S K ; N 1037 1191 M 1037 992 I : 2.969 2.969 +S K ; : N 1010 989 33 3 rp C 0.91 0 scol L ; : N 1010 1194 33 3 rp C 0.91 0 scol L ; : N 1010 992 3 202 rp C 0.91 0 scol L ; : N 1040 992 3 202 rp C 0.91 0 scol L ; : N 1001 983 9 220 rp C 1 0 scol L ; : N 1043 983 6 220 rp C 1 0 scol L ; : N 1001 983 48 6 rp C 1 0 scol L ; : N 1001 1197 48 6 rp C 1 0 scol L ; : N 1025 1001 M 1025 1004 I 1022 1004 I 1022 1007 I 1019 1007 I 1019 1010 I 1016 1010 I 1016 1013 I 1037 1013 I 1037 1010 I 1034 1010 I 1034 1007 I 1031 1007 I 1031 1004 I 1028 1004 I 1028 1001 I C eoclip : N 1016 1001 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1001 1200 50 6 rc N 1001 1203 M 1052 1203 I : 2.969 2.969 +S K ; ; : N 1049 983 2 220 rp C 1 0 scol L ; : N 1051 983 2112 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1054 1022 M (measurement)[35 22 22 22 24 15 22 35 22 24 0]xS 0.754 0 scol : 1340 1031 1826 6 rc N 1343 1034 M 3166 1034 I : 2.969 2.969 +S K ; ; : 3160 983 6 54 rc N 3163 983 M 3163 1037 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1031 299 6 rc N 1052 1034 M 1346 1034 I : 2.969 2.969 +S K ; ; : N 53 1037 173 53 rp C L ; : N 53 1090 173 3 rp C L ; 0.754 0 scol : 223 1037 6 56 rc N 226 1037 M 226 1093 I : 2.969 2.969 +S K ; ; : N 279 1037 377 53 rp C 1 0 scol L ; : N 279 1090 377 3 rp C 1 0 scol L ; : 653 1037 6 56 rc N 656 1037 M 656 1093 I : 2.969 2.969 +S K ; ; : N 710 1037 113 53 rp C 1 0 scol L ; : N 710 1090 113 3 rp C 1 0 scol L ; : 820 1037 6 56 rc N 823 1037 M 823 1093 I : 2.969 2.969 +S K ; ; : N 876 1037 122 53 rp C 1 0 scol L ; : N 876 1090 122 3 rp C 1 0 scol L ; : 995 1037 6 56 rc N 998 1037 M 998 1093 I : 2.969 2.969 +S K ; ; : N 1051 1037 295 53 rp C 1 0 scol L ; : N 1051 1090 295 3 rp C 1 0 scol L ; : 1343 1037 6 56 rc N 1346 1037 M 1346 1093 I : 2.969 2.969 +S K ; ; : N 1349 1037 47 53 rp C 1 0 scol L ; : 1351 1040 45 38 rc : 16 13 8 16 48 38 1351 1040 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1087 50 6 rc N 1349 1090 M 1399 1090 I : 2.969 2.969 +S K ; ; : N 1396 1037 3 53 rp C 1 0 scol L ; : N 1399 1037 181 53 rp C 1 0 scol L ; 0 0 scol 1402 1076 M (name)[24 22 35 0]xS 0.754 0 scol : 1399 1087 184 6 rc N 1399 1090 M 1583 1090 I : 2.969 2.969 +S K ; ; : 1577 1037 6 56 rc N 1580 1037 M 1580 1093 I : 2.969 2.969 +S K ; ; : N 1583 1037 1580 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1075 M (X-ray_brightness)[25 13 13 22 19 22 22 13 9 22 22 11 22 22 19 0]xS 0.754 0 scol : 1583 1087 1583 6 rc N 1583 1090 M 3166 1090 I : 2.969 2.969 +S K ; ; : 3160 1037 6 56 rc N 3163 1037 M 3163 1093 I : 2.969 2.969 +S K ; ; : N 53 1093 173 54 rp C 1 0 scol L ; : N 53 1147 173 3 rp C 1 0 scol L ; : 223 1093 6 57 rc N 226 1093 M 226 1150 I : 2.969 2.969 +S K ; ; : N 279 1093 377 54 rp C 1 0 scol L ; : N 279 1147 377 3 rp C 1 0 scol L ; : 653 1093 6 57 rc N 656 1093 M 656 1150 I : 2.969 2.969 +S K ; ; : N 710 1093 113 54 rp C 1 0 scol L ; : N 710 1147 113 3 rp C 1 0 scol L ; : 820 1093 6 57 rc N 823 1093 M 823 1150 I : 2.969 2.969 +S K ; ; : N 876 1093 122 54 rp C 1 0 scol L ; : N 876 1147 122 3 rp C 1 0 scol L ; : 995 1093 6 57 rc N 998 1093 M 998 1150 I : 2.969 2.969 +S K ; ; : N 1051 1093 295 54 rp C 1 0 scol L ; : N 1051 1147 295 3 rp C 1 0 scol L ; : 1343 1093 6 57 rc N 1346 1093 M 1346 1150 I : 2.969 2.969 +S K ; ; : N 1349 1093 47 54 rp C 1 0 scol L ; : 1351 1096 45 39 rc : 16 13 8 16 48 39 1351 1096 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1144 50 6 rc N 1349 1147 M 1399 1147 I : 2.969 2.969 +S K ; ; : N 1396 1093 3 54 rp C 1 0 scol L ; : N 1399 1093 181 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1132 M (project)[24 15 24 11 22 22 0]xS 0.754 0 scol : 1399 1144 184 6 rc N 1399 1147 M 1583 1147 I : 2.969 2.969 +S K ; ; : 1577 1093 6 57 rc N 1580 1093 M 1580 1150 I : 2.969 2.969 +S K ; ; : N 1583 1093 1580 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1131 M (ROSAT)[28 30 26 26 0]xS 0.754 0 scol : 1583 1144 1583 6 rc N 1583 1147 M 3166 1147 I : 2.969 2.969 +S K ; ; : 3160 1093 6 57 rc N 3163 1093 M 3163 1150 I : 2.969 2.969 +S K ; ; : N 53 1150 173 53 rp C 1 0 scol L ; : N 53 1203 173 3 rp C 1 0 scol L ; : 223 1150 6 56 rc N 226 1150 M 226 1206 I : 2.969 2.969 +S K ; ; : N 279 1150 377 53 rp C 1 0 scol L ; : N 279 1203 377 3 rp C 1 0 scol L ; : 653 1150 6 56 rc N 656 1150 M 656 1206 I : 2.969 2.969 +S K ; ; : N 710 1150 113 53 rp C 1 0 scol L ; : N 710 1203 113 3 rp C 1 0 scol L ; : 820 1150 6 56 rc N 823 1150 M 823 1206 I : 2.969 2.969 +S K ; ; : N 876 1150 122 53 rp C 1 0 scol L ; : N 876 1203 122 3 rp C 1 0 scol L ; : 995 1150 6 56 rc N 998 1150 M 998 1206 I : 2.969 2.969 +S K ; ; : N 1051 1150 295 53 rp C 1 0 scol L ; : 1051 1200 298 6 rc N 1052 1203 M 1349 1203 I : 2.969 2.969 +S K ; ; : 1343 1150 6 56 rc N 1346 1150 M 1346 1206 I : 2.969 2.969 +S K ; ; : N 1349 1150 47 53 rp C 1 0 scol L ; : 1351 1152 45 39 rc : 16 13 8 16 48 39 1351 1152 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 1349 1200 50 6 rc N 1349 1203 M 1399 1203 I : 2.969 2.969 +S K ; ; : N 1396 1150 3 53 rp C 1 0 scol L ; : N 1399 1150 181 53 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 1402 1189 M (Text)[24 22 20 0]xS 0.754 0 scol : 1399 1200 184 6 rc N 1399 1203 M 1583 1203 I : 2.969 2.969 +S K ; ; : 1577 1150 6 56 rc N 1580 1150 M 1580 1206 I : 2.969 2.969 +S K ; ; : N 1583 1150 1580 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1188 M (@clusterXray)[40 20 9 22 19 11 22 13 25 13 22 0]xS 0.754 0 scol : 1583 1200 1583 6 rc N 1583 1203 M 3166 1203 I : 2.969 2.969 +S K ; ; : 3160 1150 6 56 rc N 3163 1150 M 3163 1206 I : 2.969 2.969 +S K ; ; : N 53 1206 173 50 rp C 1 0 scol L ; : N 53 1256 173 3 rp C 1 0 scol L ; : 223 1206 6 53 rc N 226 1206 M 226 1259 I : 2.969 2.969 +S K ; ; : N 279 1206 377 50 rp C 1 0 scol L ; : N 279 1256 377 3 rp C 1 0 scol L ; : 653 1206 6 53 rc N 656 1206 M 656 1259 I : 2.969 2.969 +S K ; ; : N 710 1206 113 50 rp C 1 0 scol L ; : N 710 1256 113 3 rp C 1 0 scol L ; : 820 1206 6 53 rc N 823 1206 M 823 1259 I : 2.969 2.969 +S K ; ; : N 876 1206 122 50 rp C 1 0 scol L ; : N 876 1256 122 3 rp C 1 0 scol L ; : 995 1206 6 53 rc N 998 1206 M 998 1259 I : 2.969 2.969 +S K ; ; : N 1013 1215 27 258 rp C 0.91 0 scol L ; 1 0 scol N 1013 1473 M 1013 1215 I : 2.969 2.969 +S K ; N 1013 1215 M 1040 1215 I : 2.969 2.969 +S K ; 0.496 0 scol N 1013 1470 M 1037 1470 I : 2.969 2.969 +S K ; N 1037 1470 M 1037 1215 I : 2.969 2.969 +S K ; : N 1010 1212 33 3 rp C 0.91 0 scol L ; : N 1010 1473 33 3 rp C 0.91 0 scol L ; : N 1010 1215 3 258 rp C 0.91 0 scol L ; : N 1040 1215 3 258 rp C 0.91 0 scol L ; : N 1001 1206 9 276 rp C 1 0 scol L ; : N 1043 1206 6 276 rp C 1 0 scol L ; : N 1001 1206 48 6 rp C 1 0 scol L ; : N 1001 1476 48 6 rp C 1 0 scol L ; : N 1025 1224 M 1025 1227 I 1022 1227 I 1022 1230 I 1019 1230 I 1019 1233 I 1016 1233 I 1016 1236 I 1037 1236 I 1037 1233 I 1034 1233 I 1034 1230 I 1031 1230 I 1031 1227 I 1028 1227 I 1028 1224 I C eoclip : N 1016 1224 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1001 1479 50 6 rc N 1001 1482 M 1052 1482 I : 2.969 2.969 +S K ; ; : N 1049 1206 2 276 rp C 1 0 scol L ; : N 1051 1206 2112 50 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 1054 1244 M (siap:)[22 11 22 24 0]xS : 1147 1209 114 44 rc F2S26 Ji 1147 1245 M (image)[11 35 22 24 0]xS ; 0.754 0 scol : 1340 1253 1826 6 rc N 1343 1256 M 3166 1256 I : 2.969 2.969 +S K ; ; : 3160 1206 6 53 rc N 3163 1206 M 3163 1259 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1253 299 6 rc N 1052 1256 M 1346 1256 I : 2.969 2.969 +S K ; ; : N 53 1259 173 54 rp C L ; : N 53 1313 173 3 rp C L ; 0.754 0 scol : 223 1259 6 57 rc N 226 1259 M 226 1316 I : 2.969 2.969 +S K ; ; : N 279 1259 377 54 rp C 1 0 scol L ; : N 279 1313 377 3 rp C 1 0 scol L ; : 653 1259 6 57 rc N 656 1259 M 656 1316 I : 2.969 2.969 +S K ; ; : N 710 1259 113 54 rp C 1 0 scol L ; : N 710 1313 113 3 rp C 1 0 scol L ; : 820 1259 6 57 rc N 823 1259 M 823 1316 I : 2.969 2.969 +S K ; ; : N 876 1259 122 54 rp C 1 0 scol L ; : N 876 1313 122 3 rp C 1 0 scol L ; : 995 1259 6 57 rc N 998 1259 M 998 1316 I : 2.969 2.969 +S K ; ; : N 1051 1259 295 54 rp C 1 0 scol L ; : N 1051 1313 295 3 rp C 1 0 scol L ; : 1343 1259 6 57 rc N 1346 1259 M 1346 1316 I : 2.969 2.969 +S K ; ; : N 1349 1259 47 54 rp C 1 0 scol L ; : 1351 1262 45 39 rc : 16 13 8 16 48 39 1351 1262 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1310 50 6 rc N 1349 1313 M 1399 1313 I : 2.969 2.969 +S K ; ; : N 1396 1259 3 54 rp C 1 0 scol L ; : N 1399 1259 181 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1298 M (band)[24 22 24 0]xS 0.754 0 scol : 1399 1310 184 6 rc N 1399 1313 M 1583 1313 I : 2.969 2.969 +S K ; ; : 1577 1259 6 57 rc N 1580 1259 M 1580 1316 I : 2.969 2.969 +S K ; ; : N 1583 1259 1580 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1297 M (Xray)[25 13 22 0]xS 0.754 0 scol : 1583 1310 1583 6 rc N 1583 1313 M 3166 1313 I : 2.969 2.969 +S K ; ; : 3160 1259 6 57 rc N 3163 1259 M 3163 1316 I : 2.969 2.969 +S K ; ; : N 53 1316 173 53 rp C 1 0 scol L ; : N 53 1369 173 3 rp C 1 0 scol L ; : 223 1316 6 56 rc N 226 1316 M 226 1372 I : 2.969 2.969 +S K ; ; : N 279 1316 377 53 rp C 1 0 scol L ; : N 279 1369 377 3 rp C 1 0 scol L ; : 653 1316 6 56 rc N 656 1316 M 656 1372 I : 2.969 2.969 +S K ; ; : N 710 1316 113 53 rp C 1 0 scol L ; : N 710 1369 113 3 rp C 1 0 scol L ; : 820 1316 6 56 rc N 823 1316 M 823 1372 I : 2.969 2.969 +S K ; ; : N 876 1316 122 53 rp C 1 0 scol L ; : N 876 1369 122 3 rp C 1 0 scol L ; : 995 1316 6 56 rc N 998 1316 M 998 1372 I : 2.969 2.969 +S K ; ; : N 1051 1316 295 53 rp C 1 0 scol L ; : N 1051 1369 295 3 rp C 1 0 scol L ; : 1343 1316 6 56 rc N 1346 1316 M 1346 1372 I : 2.969 2.969 +S K ; ; : N 1349 1316 47 53 rp C 1 0 scol L ; : 1351 1319 45 38 rc : 16 13 8 16 48 38 1351 1319 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1366 50 6 rc N 1349 1369 M 1399 1369 I : 2.969 2.969 +S K ; ; : N 1396 1316 3 53 rp C 1 0 scol L ; : N 1399 1316 181 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1355 M (INST_ID)[11 28 26 23 22 11 0]xS 0.754 0 scol : 1399 1366 184 6 rc N 1399 1369 M 1583 1369 I : 2.969 2.969 +S K ; ; : 1577 1316 6 56 rc N 1580 1316 M 1580 1372 I : 2.969 2.969 +S K ; ; : N 1583 1316 1580 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1354 M (ROSAT)[28 30 26 26 0]xS 0.754 0 scol : 1583 1366 1583 6 rc N 1583 1369 M 3166 1369 I : 2.969 2.969 +S K ; ; : 3160 1316 6 56 rc N 3163 1316 M 3163 1372 I : 2.969 2.969 +S K ; ; : N 53 1372 173 54 rp C 1 0 scol L ; : N 53 1426 173 3 rp C 1 0 scol L ; : 223 1372 6 57 rc N 226 1372 M 226 1429 I : 2.969 2.969 +S K ; ; : N 279 1372 377 54 rp C 1 0 scol L ; : N 279 1426 377 3 rp C 1 0 scol L ; : 653 1372 6 57 rc N 656 1372 M 656 1429 I : 2.969 2.969 +S K ; ; : N 710 1372 113 54 rp C 1 0 scol L ; : N 710 1426 113 3 rp C 1 0 scol L ; : 820 1372 6 57 rc N 823 1372 M 823 1429 I : 2.969 2.969 +S K ; ; : N 876 1372 122 54 rp C 1 0 scol L ; : N 876 1426 122 3 rp C 1 0 scol L ; : 995 1372 6 57 rc N 998 1372 M 998 1429 I : 2.969 2.969 +S K ; ; : N 1051 1372 295 54 rp C 1 0 scol L ; : N 1051 1426 295 3 rp C 1 0 scol L ; : 1343 1372 6 57 rc N 1346 1372 M 1346 1429 I : 2.969 2.969 +S K ; ; : N 1349 1372 47 54 rp C 1 0 scol L ; : 1351 1375 45 39 rc : 16 13 8 16 48 39 1351 1375 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1423 50 6 rc N 1349 1426 M 1399 1426 I : 2.969 2.969 +S K ; ; : N 1396 1372 3 54 rp C 1 0 scol L ; : N 1399 1372 181 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1411 M (quality)[24 24 22 11 11 13 0]xS 0.754 0 scol : 1399 1423 184 6 rc N 1399 1426 M 1583 1426 I : 2.969 2.969 +S K ; ; : 1577 1372 6 57 rc N 1580 1372 M 1580 1429 I : 2.969 2.969 +S K ; ; : N 1583 1372 1580 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1410 M (@q)[40 0]xS 0.754 0 scol : 1583 1423 1583 6 rc N 1583 1426 M 3166 1426 I : 2.969 2.969 +S K ; ; : 3160 1372 6 57 rc N 3163 1372 M 3163 1429 I : 2.969 2.969 +S K ; ; : N 53 1429 173 53 rp C 1 0 scol L ; : N 53 1482 173 3 rp C 1 0 scol L ; : 223 1429 6 56 rc N 226 1429 M 226 1485 I : 2.969 2.969 +S K ; ; : N 279 1429 377 53 rp C 1 0 scol L ; : N 279 1482 377 3 rp C 1 0 scol L ; : 653 1429 6 56 rc N 656 1429 M 656 1485 I : 2.969 2.969 +S K ; ; : N 710 1429 113 53 rp C 1 0 scol L ; : N 710 1482 113 3 rp C 1 0 scol L ; : 820 1429 6 56 rc N 823 1429 M 823 1485 I : 2.969 2.969 +S K ; ; : N 876 1429 122 53 rp C 1 0 scol L ; : N 876 1482 122 3 rp C 1 0 scol L ; : 995 1429 6 56 rc N 998 1429 M 998 1485 I : 2.969 2.969 +S K ; ; : N 1051 1429 295 53 rp C 1 0 scol L ; : 1051 1479 298 6 rc N 1052 1482 M 1349 1482 I : 2.969 2.969 +S K ; ; : 1343 1429 6 56 rc N 1346 1429 M 1346 1485 I : 2.969 2.969 +S K ; ; : N 1349 1429 47 53 rp C 1 0 scol L ; : 1351 1432 45 38 rc : 16 13 8 16 48 38 1351 1432 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 1349 1479 50 6 rc N 1349 1482 M 1399 1482 I : 2.969 2.969 +S K ; ; : N 1396 1429 3 53 rp C 1 0 scol L ; : N 1399 1429 181 53 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 1402 1467 M (siap:)[22 11 22 24 0]xS F2S26 Ji 1494 1468 M (URL)[28 28 0]xS 0.754 0 scol : 1399 1479 184 6 rc N 1399 1482 M 1583 1482 I : 2.969 2.969 +S K ; ; : 1577 1429 6 56 rc N 1580 1429 M 1580 1485 I : 2.969 2.969 +S K ; ; : N 1583 1429 1580 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1467 M (@image)[40 9 33 22 22 0]xS 0.754 0 scol : 1583 1479 1583 6 rc N 1583 1482 M 3166 1482 I : 2.969 2.969 +S K ; ; : 3160 1429 6 56 rc N 3163 1429 M 3163 1485 I : 2.969 2.969 +S K ; ; : N 53 1485 173 54 rp C 1 0 scol L ; : N 53 1539 173 3 rp C 1 0 scol L ; : 223 1485 6 57 rc N 226 1485 M 226 1542 I : 2.969 2.969 +S K ; ; : N 279 1485 377 54 rp C 1 0 scol L ; : N 279 1539 377 3 rp C 1 0 scol L ; : 653 1485 6 57 rc N 656 1485 M 656 1542 I : 2.969 2.969 +S K ; ; : N 710 1485 113 54 rp C 1 0 scol L ; : N 710 1539 113 3 rp C 1 0 scol L ; : 820 1485 6 57 rc N 823 1485 M 823 1542 I : 2.969 2.969 +S K ; ; : N 876 1485 122 54 rp C 1 0 scol L ; : N 876 1539 122 3 rp C 1 0 scol L ; : 995 1485 6 57 rc N 998 1485 M 998 1542 I : 2.969 2.969 +S K ; ; : N 1001 1485 48 54 rp C 1 0 scol L ; : 1004 1488 45 39 rc : 16 13 8 16 47 39 1004 1488 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 1001 1536 50 6 rc N 1001 1539 M 1052 1539 I : 2.969 2.969 +S K ; ; : N 1049 1485 2 54 rp C 1 0 scol L ; : N 1051 1485 295 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1054 1524 M (name)[24 22 35 0]xS 0.754 0 scol : 1051 1536 298 6 rc N 1052 1539 M 1349 1539 I : 2.969 2.969 +S K ; ; : 1343 1485 6 57 rc N 1346 1485 M 1346 1542 I : 2.969 2.969 +S K ; ; : N 1349 1485 1814 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1352 1523 M (@clusterName)[40 20 9 22 19 11 22 13 28 22 33 0]xS 0.754 0 scol : 1349 1536 1817 6 rc N 1349 1539 M 3166 1539 I : 2.969 2.969 +S K ; ; : 3160 1485 6 57 rc N 3163 1485 M 3163 1542 I : 2.969 2.969 +S K ; ; : N 53 1542 173 50 rp C 1 0 scol L ; : N 53 1592 173 3 rp C 1 0 scol L ; : 223 1542 6 53 rc N 226 1542 M 226 1595 I : 2.969 2.969 +S K ; ; : N 279 1542 377 50 rp C 1 0 scol L ; : N 279 1592 377 3 rp C 1 0 scol L ; : 653 1542 6 53 rc N 656 1542 M 656 1595 I : 2.969 2.969 +S K ; ; : N 710 1542 113 50 rp C 1 0 scol L ; : N 710 1592 113 3 rp C 1 0 scol L ; : 820 1542 6 53 rc N 823 1542 M 823 1595 I : 2.969 2.969 +S K ; ; : N 876 1542 122 50 rp C 1 0 scol L ; : N 876 1592 122 3 rp C 1 0 scol L ; : 995 1542 6 53 rc N 998 1542 M 998 1595 I : 2.969 2.969 +S K ; ; : N 1013 1550 27 422 rp C 0.91 0 scol L ; 1 0 scol N 1013 1972 M 1013 1551 I : 2.969 2.969 +S K ; N 1013 1551 M 1040 1551 I : 2.969 2.969 +S K ; 0.496 0 scol N 1013 1969 M 1037 1969 I : 2.969 2.969 +S K ; N 1037 1969 M 1037 1551 I : 2.969 2.969 +S K ; : N 1010 1548 33 2 rp C 0.91 0 scol L ; : N 1010 1972 33 3 rp C 0.91 0 scol L ; : N 1010 1550 3 422 rp C 0.91 0 scol L ; : N 1040 1550 3 422 rp C 0.91 0 scol L ; : N 1001 1542 9 439 rp C 1 0 scol L ; : N 1043 1542 6 439 rp C 1 0 scol L ; : N 1001 1542 48 6 rp C 1 0 scol L ; : N 1001 1975 48 6 rp C 1 0 scol L ; : N 1025 1559 M 1025 1562 I 1022 1562 I 1022 1565 I 1019 1565 I 1019 1568 I 1016 1568 I 1016 1571 I 1037 1571 I 1037 1568 I 1034 1568 I 1034 1565 I 1031 1565 I 1031 1562 I 1028 1562 I 1028 1559 I C eoclip : N 1016 1559 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1001 1978 50 6 rc N 1001 1981 M 1052 1981 I : 2.969 2.969 +S K ; ; : N 1049 1542 2 439 rp C 1 0 scol L ; : N 1051 1542 2112 50 rp C 1 0 scol L ; 0 0 scol : 1054 1545 256 44 rc F2S26 Ji 1054 1581 M (measurement)[35 22 22 22 24 15 22 35 22 24 0]xS ; 0.754 0 scol : 1340 1589 1826 6 rc N 1343 1592 M 3166 1592 I : 2.969 2.969 +S K ; ; : 3160 1542 6 53 rc N 3163 1542 M 3163 1595 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1589 299 6 rc N 1052 1592 M 1346 1592 I : 2.969 2.969 +S K ; ; : N 53 1595 173 54 rp C L ; : N 53 1649 173 2 rp C L ; 0.754 0 scol : 223 1595 6 56 rc N 226 1595 M 226 1652 I : 2.969 2.969 +S K ; ; : N 279 1595 377 54 rp C 1 0 scol L ; : N 279 1649 377 2 rp C 1 0 scol L ; : 653 1595 6 56 rc N 656 1595 M 656 1652 I : 2.969 2.969 +S K ; ; : N 710 1595 113 54 rp C 1 0 scol L ; : N 710 1649 113 2 rp C 1 0 scol L ; : 820 1595 6 56 rc N 823 1595 M 823 1652 I : 2.969 2.969 +S K ; ; : N 876 1595 122 54 rp C 1 0 scol L ; : N 876 1649 122 2 rp C 1 0 scol L ; : 995 1595 6 56 rc N 998 1595 M 998 1652 I : 2.969 2.969 +S K ; ; : N 1051 1595 295 54 rp C 1 0 scol L ; : N 1051 1649 295 2 rp C 1 0 scol L ; : 1343 1595 6 56 rc N 1346 1595 M 1346 1652 I : 2.969 2.969 +S K ; ; : N 1349 1595 47 54 rp C 1 0 scol L ; : 1351 1598 45 39 rc : 16 13 8 16 48 39 1351 1598 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1646 50 5 rc N 1349 1649 M 1399 1649 I : 2.969 2.969 +S K ; ; : N 1396 1595 3 54 rp C 1 0 scol L ; : N 1399 1595 181 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1634 M (name)[24 22 35 0]xS 0.754 0 scol : 1399 1646 184 5 rc N 1399 1649 M 1583 1649 I : 2.969 2.969 +S K ; ; : 1577 1595 6 56 rc N 1580 1595 M 1580 1652 I : 2.969 2.969 +S K ; ; : N 1583 1595 1580 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1633 M (redshift)[13 22 22 19 22 9 12 0]xS 0.754 0 scol : 1583 1646 1583 5 rc N 1583 1649 M 3166 1649 I : 2.969 2.969 +S K ; ; : 3160 1595 6 56 rc N 3163 1595 M 3163 1652 I : 2.969 2.969 +S K ; ; : N 53 1651 173 54 rp C 1 0 scol L ; : N 53 1705 173 3 rp C 1 0 scol L ; : 223 1651 6 57 rc N 226 1652 M 226 1708 I : 2.969 2.969 +S K ; ; : N 279 1651 377 54 rp C 1 0 scol L ; : N 279 1705 377 3 rp C 1 0 scol L ; : 653 1651 6 57 rc N 656 1652 M 656 1708 I : 2.969 2.969 +S K ; ; : N 710 1651 113 54 rp C 1 0 scol L ; : N 710 1705 113 3 rp C 1 0 scol L ; : 820 1651 6 57 rc N 823 1652 M 823 1708 I : 2.969 2.969 +S K ; ; : N 876 1651 122 54 rp C 1 0 scol L ; : N 876 1705 122 3 rp C 1 0 scol L ; : 995 1651 6 57 rc N 998 1652 M 998 1708 I : 2.969 2.969 +S K ; ; : N 1051 1651 295 54 rp C 1 0 scol L ; : N 1051 1705 295 3 rp C 1 0 scol L ; : 1343 1651 6 57 rc N 1346 1652 M 1346 1708 I : 2.969 2.969 +S K ; ; : N 1349 1651 47 54 rp C 1 0 scol L ; : 1351 1654 45 39 rc : 16 13 8 16 48 39 1351 1654 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1349 1702 50 6 rc N 1349 1705 M 1399 1705 I : 2.969 2.969 +S K ; ; : N 1396 1651 3 54 rp C 1 0 scol L ; : N 1399 1651 181 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1402 1690 M (units)[24 24 11 13 0]xS 0.754 0 scol : 1399 1702 184 6 rc N 1399 1705 M 1583 1705 I : 2.969 2.969 +S K ; ; : 1577 1651 6 57 rc N 1580 1652 M 1580 1708 I : 2.969 2.969 +S K ; ; : N 1583 1651 1580 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1689 M (@czunits)[40 20 19 22 22 9 11 0]xS 0.754 0 scol : 1583 1702 1583 6 rc N 1583 1705 M 3166 1705 I : 2.969 2.969 +S K ; ; : 3160 1651 6 57 rc N 3163 1652 M 3163 1708 I : 2.969 2.969 +S K ; ; : N 53 1708 173 50 rp C 1 0 scol L ; : N 53 1758 173 3 rp C 1 0 scol L ; : 223 1708 6 53 rc N 226 1708 M 226 1761 I : 2.969 2.969 +S K ; ; : N 279 1708 377 50 rp C 1 0 scol L ; : N 279 1758 377 3 rp C 1 0 scol L ; : 653 1708 6 53 rc N 656 1708 M 656 1761 I : 2.969 2.969 +S K ; ; : N 710 1708 113 50 rp C 1 0 scol L ; : N 710 1758 113 3 rp C 1 0 scol L ; : 820 1708 6 53 rc N 823 1708 M 823 1761 I : 2.969 2.969 +S K ; ; : N 876 1708 122 50 rp C 1 0 scol L ; : N 876 1758 122 3 rp C 1 0 scol L ; : 995 1708 6 53 rc N 998 1708 M 998 1761 I : 2.969 2.969 +S K ; ; : N 1051 1708 295 50 rp C 1 0 scol L ; : N 1051 1758 295 3 rp C 1 0 scol L ; : 1343 1708 6 53 rc N 1346 1708 M 1346 1761 I : 2.969 2.969 +S K ; ; : N 1360 1717 27 199 rp C 0.91 0 scol L ; 1 0 scol N 1360 1916 M 1360 1717 I : 2.969 2.969 +S K ; N 1360 1717 M 1387 1717 I : 2.969 2.969 +S K ; 0.496 0 scol N 1360 1913 M 1384 1913 I : 2.969 2.969 +S K ; N 1384 1913 M 1384 1717 I : 2.969 2.969 +S K ; : N 1357 1714 33 3 rp C 0.91 0 scol L ; : N 1357 1916 33 3 rp C 0.91 0 scol L ; : N 1357 1717 3 199 rp C 0.91 0 scol L ; : N 1387 1717 3 199 rp C 0.91 0 scol L ; : N 1349 1708 8 217 rp C 1 0 scol L ; : N 1390 1708 6 217 rp C 1 0 scol L ; : N 1349 1708 47 6 rp C 1 0 scol L ; : N 1349 1919 47 6 rp C 1 0 scol L ; : N 1372 1726 M 1372 1729 I 1369 1729 I 1369 1732 I 1366 1732 I 1366 1735 I 1363 1735 I 1363 1738 I 1384 1738 I 1384 1735 I 1381 1735 I 1381 1732 I 1378 1732 I 1378 1729 I 1375 1729 I 1375 1726 I C eoclip : N 1363 1726 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1349 1922 50 6 rc N 1349 1925 M 1399 1925 I : 2.969 2.969 +S K ; ; : N 1396 1708 3 217 rp C 1 0 scol L ; : N 1399 1708 1764 50 rp C 1 0 scol L ; 0 0 scol : 1402 1711 107 44 rc F2S26 Ji 1402 1747 M (range)[15 22 24 24 0]xS ; 0.754 0 scol : 1574 1755 1592 6 rc N 1577 1758 M 3166 1758 I : 2.969 2.969 +S K ; ; : 3160 1708 6 53 rc N 3163 1708 M 3163 1761 I : 2.969 2.969 +S K ; ; 1 0 scol : 1399 1755 185 6 rc N 1399 1758 M 1580 1758 I : 2.969 2.969 +S K ; ; : N 53 1761 173 51 rp C L ; : N 53 1812 173 3 rp C L ; 0.754 0 scol : 223 1761 6 54 rc N 226 1761 M 226 1815 I : 2.969 2.969 +S K ; ; : N 279 1761 377 51 rp C 1 0 scol L ; : N 279 1812 377 3 rp C 1 0 scol L ; : 653 1761 6 54 rc N 656 1761 M 656 1815 I : 2.969 2.969 +S K ; ; : N 710 1761 113 51 rp C 1 0 scol L ; : N 710 1812 113 3 rp C 1 0 scol L ; : 820 1761 6 54 rc N 823 1761 M 823 1815 I : 2.969 2.969 +S K ; ; : N 876 1761 122 51 rp C 1 0 scol L ; : N 876 1812 122 3 rp C 1 0 scol L ; : 995 1761 6 54 rc N 998 1761 M 998 1815 I : 2.969 2.969 +S K ; ; : N 1051 1761 295 51 rp C 1 0 scol L ; : N 1051 1812 295 3 rp C 1 0 scol L ; : 1343 1761 6 54 rc N 1346 1761 M 1346 1815 I : 2.969 2.969 +S K ; ; : N 1399 1761 181 51 rp C 1 0 scol L ; : N 1399 1812 181 3 rp C 1 0 scol L ; : 1577 1761 6 54 rc N 1580 1761 M 1580 1815 I : 2.969 2.969 +S K ; ; : N 1595 1770 27 146 rp C 0.91 0 scol L ; 1 0 scol N 1595 1916 M 1595 1770 I : 2.969 2.969 +S K ; N 1595 1770 M 1622 1770 I : 2.969 2.969 +S K ; 0.496 0 scol N 1595 1913 M 1619 1913 I : 2.969 2.969 +S K ; N 1619 1913 M 1619 1770 I : 2.969 2.969 +S K ; : N 1592 1767 33 3 rp C 0.91 0 scol L ; : N 1592 1916 33 3 rp C 0.91 0 scol L ; : N 1592 1770 3 146 rp C 0.91 0 scol L ; : N 1622 1770 3 146 rp C 0.91 0 scol L ; : N 1583 1761 9 164 rp C 1 0 scol L ; : N 1625 1761 6 164 rp C 1 0 scol L ; : N 1583 1761 48 6 rp C 1 0 scol L ; : N 1583 1919 48 6 rp C 1 0 scol L ; : N 1607 1779 M 1607 1782 I 1604 1782 I 1604 1785 I 1601 1785 I 1601 1788 I 1598 1788 I 1598 1791 I 1619 1791 I 1619 1788 I 1616 1788 I 1616 1785 I 1613 1785 I 1613 1782 I 1610 1782 I 1610 1779 I C eoclip : N 1598 1779 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1583 1922 51 6 rc N 1583 1925 M 1634 1925 I : 2.969 2.969 +S K ; ; : N 1631 1761 3 164 rp C 1 0 scol L ; : N 1634 1761 1529 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1637 1800 M (lo)[11 0]xS 0.754 0 scol : 1839 1809 1327 6 rc N 1842 1812 M 3166 1812 I : 2.969 2.969 +S K ; ; : 3160 1761 6 54 rc N 3163 1761 M 3163 1815 I : 2.969 2.969 +S K ; ; 1 0 scol : 1634 1809 215 6 rc N 1634 1812 M 1845 1812 I : 2.969 2.969 +S K ; ; : N 53 1815 173 53 rp C L ; : N 53 1868 173 3 rp C L ; 0.754 0 scol : 223 1815 6 56 rc N 226 1815 M 226 1871 I : 2.969 2.969 +S K ; ; : N 279 1815 377 53 rp C 1 0 scol L ; : N 279 1868 377 3 rp C 1 0 scol L ; : 653 1815 6 56 rc N 656 1815 M 656 1871 I : 2.969 2.969 +S K ; ; : N 710 1815 113 53 rp C 1 0 scol L ; : N 710 1868 113 3 rp C 1 0 scol L ; : 820 1815 6 56 rc N 823 1815 M 823 1871 I : 2.969 2.969 +S K ; ; : N 876 1815 122 53 rp C 1 0 scol L ; : N 876 1868 122 3 rp C 1 0 scol L ; : 995 1815 6 56 rc N 998 1815 M 998 1871 I : 2.969 2.969 +S K ; ; : N 1051 1815 295 53 rp C 1 0 scol L ; : N 1051 1868 295 3 rp C 1 0 scol L ; : 1343 1815 6 56 rc N 1346 1815 M 1346 1871 I : 2.969 2.969 +S K ; ; : N 1399 1815 181 53 rp C 1 0 scol L ; : N 1399 1868 181 3 rp C 1 0 scol L ; : 1577 1815 6 56 rc N 1580 1815 M 1580 1871 I : 2.969 2.969 +S K ; ; : N 1634 1815 211 53 rp C 1 0 scol L ; : N 1634 1868 211 3 rp C 1 0 scol L ; : 1842 1815 6 56 rc N 1845 1815 M 1845 1871 I : 2.969 2.969 +S K ; ; : N 1848 1815 47 53 rp C 1 0 scol L ; : 1850 1818 45 38 rc : 16 13 8 16 48 38 1850 1818 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1848 1865 50 6 rc N 1848 1868 M 1898 1868 I : 2.969 2.969 +S K ; ; : N 1895 1815 3 53 rp C 1 0 scol L ; : N 1898 1815 208 53 rp C 1 0 scol L ; 0 0 scol 1901 1854 M (inclusive)[11 24 22 11 24 22 11 21 0]xS 0.754 0 scol : 1898 1865 211 6 rc N 1898 1868 M 2109 1868 I : 2.969 2.969 +S K ; ; : 2103 1815 6 56 rc N 2106 1815 M 2106 1871 I : 2.969 2.969 +S K ; ; : N 2109 1815 1054 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2112 1853 M (yes)[19 22 0]xS 0.754 0 scol : 2109 1865 1057 6 rc N 2109 1868 M 3166 1868 I : 2.969 2.969 +S K ; ; : 3160 1815 6 56 rc N 3163 1815 M 3163 1871 I : 2.969 2.969 +S K ; ; : N 53 1871 173 54 rp C 1 0 scol L ; : N 53 1925 173 3 rp C 1 0 scol L ; : 223 1871 6 57 rc N 226 1871 M 226 1928 I : 2.969 2.969 +S K ; ; : N 279 1871 377 54 rp C 1 0 scol L ; : N 279 1925 377 3 rp C 1 0 scol L ; : 653 1871 6 57 rc N 656 1871 M 656 1928 I : 2.969 2.969 +S K ; ; : N 710 1871 113 54 rp C 1 0 scol L ; : N 710 1925 113 3 rp C 1 0 scol L ; : 820 1871 6 57 rc N 823 1871 M 823 1928 I : 2.969 2.969 +S K ; ; : N 876 1871 122 54 rp C 1 0 scol L ; : N 876 1925 122 3 rp C 1 0 scol L ; : 995 1871 6 57 rc N 998 1871 M 998 1928 I : 2.969 2.969 +S K ; ; : N 1051 1871 295 54 rp C 1 0 scol L ; : N 1051 1925 295 3 rp C 1 0 scol L ; : 1343 1871 6 57 rc N 1346 1871 M 1346 1928 I : 2.969 2.969 +S K ; ; : N 1399 1871 181 54 rp C 1 0 scol L ; : 1399 1922 184 6 rc N 1399 1925 M 1583 1925 I : 2.969 2.969 +S K ; ; : 1577 1871 6 57 rc N 1580 1871 M 1580 1928 I : 2.969 2.969 +S K ; ; : N 1634 1871 211 54 rp C 1 0 scol L ; : 1634 1922 214 6 rc N 1634 1925 M 1848 1925 I : 2.969 2.969 +S K ; ; : 1842 1871 6 57 rc N 1845 1871 M 1845 1928 I : 2.969 2.969 +S K ; ; : N 1848 1871 47 54 rp C 1 0 scol L ; : 1850 1874 45 39 rc : 16 13 8 16 48 39 1850 1874 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 1848 1922 50 6 rc N 1848 1925 M 1898 1925 I : 2.969 2.969 +S K ; ; : N 1895 1871 3 54 rp C 1 0 scol L ; : N 1898 1871 208 54 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 1901 1910 M (Text)[24 22 20 0]xS 0.754 0 scol : 1898 1922 211 6 rc N 1898 1925 M 2109 1925 I : 2.969 2.969 +S K ; ; : 2103 1871 6 57 rc N 2106 1871 M 2106 1928 I : 2.969 2.969 +S K ; ; : N 2109 1871 1054 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2112 1909 M (0.6)[22 11 0]xS 0.754 0 scol : 2109 1922 1057 6 rc N 2109 1925 M 3166 1925 I : 2.969 2.969 +S K ; ; : 3160 1871 6 57 rc N 3163 1871 M 3163 1928 I : 2.969 2.969 +S K ; ; : N 53 1928 173 53 rp C 1 0 scol L ; : N 53 1981 173 3 rp C 1 0 scol L ; : 223 1928 6 56 rc N 226 1928 M 226 1984 I : 2.969 2.969 +S K ; ; : N 279 1928 377 53 rp C 1 0 scol L ; : N 279 1981 377 3 rp C 1 0 scol L ; : 653 1928 6 56 rc N 656 1928 M 656 1984 I : 2.969 2.969 +S K ; ; : N 710 1928 113 53 rp C 1 0 scol L ; : N 710 1981 113 3 rp C 1 0 scol L ; : 820 1928 6 56 rc N 823 1928 M 823 1984 I : 2.969 2.969 +S K ; ; : N 876 1928 122 53 rp C 1 0 scol L ; : N 876 1981 122 3 rp C 1 0 scol L ; : 995 1928 6 56 rc N 998 1928 M 998 1984 I : 2.969 2.969 +S K ; ; : N 1051 1928 295 53 rp C 1 0 scol L ; : 1051 1978 298 6 rc N 1052 1981 M 1349 1981 I : 2.969 2.969 +S K ; ; : 1343 1928 6 56 rc N 1346 1928 M 1346 1984 I : 2.969 2.969 +S K ; ; : N 1349 1928 47 53 rp C 1 0 scol L ; : 1351 1931 45 38 rc : 16 13 8 16 48 38 1351 1931 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 1349 1978 50 6 rc N 1349 1981 M 1399 1981 I : 2.969 2.969 +S K ; ; : N 1396 1928 3 53 rp C 1 0 scol L ; : N 1399 1928 181 53 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 1402 1967 M (Text)[24 22 20 0]xS 0.754 0 scol : 1399 1978 184 6 rc N 1399 1981 M 1583 1981 I : 2.969 2.969 +S K ; ; : 1577 1928 6 56 rc N 1580 1928 M 1580 1984 I : 2.969 2.969 +S K ; ; : N 1583 1928 1580 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1586 1966 M (@cz)[40 20 0]xS 0.754 0 scol : 1583 1978 1583 6 rc N 1583 1981 M 3166 1981 I : 2.969 2.969 +S K ; ; : 3160 1928 6 56 rc N 3163 1928 M 3163 1984 I : 2.969 2.969 +S K ; ; : N 53 1984 173 51 rp C 1 0 scol L ; : N 53 2035 173 3 rp C 1 0 scol L ; : 223 1984 6 54 rc N 226 1984 M 226 2038 I : 2.969 2.969 +S K ; ; : N 279 1984 377 51 rp C 1 0 scol L ; : N 279 2035 377 3 rp C 1 0 scol L ; : 653 1984 6 54 rc N 656 1984 M 656 2038 I : 2.969 2.969 +S K ; ; : N 710 1984 113 51 rp C 1 0 scol L ; : N 710 2035 113 3 rp C 1 0 scol L ; : 820 1984 6 54 rc N 823 1984 M 823 2038 I : 2.969 2.969 +S K ; ; : N 876 1984 122 51 rp C 1 0 scol L ; : N 876 2035 122 3 rp C 1 0 scol L ; : 995 1984 6 54 rc N 998 1984 M 998 2038 I : 2.969 2.969 +S K ; ; : N 1013 1993 27 321 rp C 0.91 0 scol L ; 1 0 scol : 1010 1990 7 324 rc N 1013 3737 M 1013 1993 I : 2.969 2.969 +S K ; ; N 1013 1993 M 1040 1993 I : 2.969 2.969 +S K ; 0.496 0 scol : 1034 1990 7 324 rc N 1037 3734 M 1037 1993 I : 2.969 2.969 +S K ; ; : N 1010 1990 33 3 rp C 0.91 0 scol L ; : N 1010 1993 3 321 rp C 0.91 0 scol L ; : N 1040 1993 3 321 rp C 0.91 0 scol L ; : N 1001 1984 9 330 rp C 1 0 scol L ; : N 1043 1984 6 330 rp C 1 0 scol L ; : N 1001 1984 48 6 rp C 1 0 scol L ; : N 1025 2002 M 1025 2005 I 1022 2005 I 1022 2008 I 1019 2008 I 1019 2011 I 1016 2011 I 1016 2014 I 1037 2014 I 1037 2011 I 1034 2011 I 1034 2008 I 1031 2008 I 1031 2005 I 1028 2005 I 1028 2002 I C eoclip : N 1016 2002 21 12 rp C 0 0 scol L ; ; : N 1049 1984 2 330 rp C 1 0 scol L ; : N 1051 1984 2112 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1054 2023 M (hasMember)[24 22 22 33 22 35 24 22 0]xS 0.754 0 scol : 1340 2032 1826 6 rc N 1343 2035 M 3166 2035 I : 2.969 2.969 +S K ; ; : 3160 1984 6 54 rc N 3163 1984 M 3163 2038 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 2032 299 6 rc N 1052 2035 M 1346 2035 I : 2.969 2.969 +S K ; ; : N 53 2038 173 50 rp C L ; : N 53 2088 173 3 rp C L ; 0.754 0 scol : 223 2038 6 53 rc N 226 2038 M 226 2091 I : 2.969 2.969 +S K ; ; : N 279 2038 377 50 rp C 1 0 scol L ; : N 279 2088 377 3 rp C 1 0 scol L ; : 653 2038 6 53 rc N 656 2038 M 656 2091 I : 2.969 2.969 +S K ; ; : N 710 2038 113 50 rp C 1 0 scol L ; : N 710 2088 113 3 rp C 1 0 scol L ; : 820 2038 6 53 rc N 823 2038 M 823 2091 I : 2.969 2.969 +S K ; ; : N 876 2038 122 50 rp C 1 0 scol L ; : N 876 2088 122 3 rp C 1 0 scol L ; : 995 2038 6 53 rc N 998 2038 M 998 2091 I : 2.969 2.969 +S K ; ; : N 1051 2038 295 50 rp C 1 0 scol L ; : N 1051 2088 295 3 rp C 1 0 scol L ; : 1343 2038 6 53 rc N 1346 2038 M 1346 2091 I : 2.969 2.969 +S K ; ; : N 1360 2047 27 267 rp C 0.91 0 scol L ; 1 0 scol : 1357 2044 7 270 rc N 1360 3737 M 1360 2047 I : 2.969 2.969 +S K ; ; N 1360 2047 M 1387 2047 I : 2.969 2.969 +S K ; 0.496 0 scol : 1381 2044 7 270 rc N 1384 3734 M 1384 2047 I : 2.969 2.969 +S K ; ; : N 1357 2044 33 3 rp C 0.91 0 scol L ; : N 1357 2047 3 267 rp C 0.91 0 scol L ; : N 1387 2047 3 267 rp C 0.91 0 scol L ; : N 1349 2038 8 276 rp C 1 0 scol L ; : N 1390 2038 6 276 rp C 1 0 scol L ; : N 1349 2038 47 6 rp C 1 0 scol L ; : N 1372 2055 M 1372 2058 I 1369 2058 I 1369 2061 I 1366 2061 I 1366 2064 I 1363 2064 I 1363 2067 I 1384 2067 I 1384 2064 I 1381 2064 I 1381 2061 I 1378 2061 I 1378 2058 I 1375 2058 I 1375 2055 I C eoclip : N 1363 2055 21 12 rp C 0 0 scol L ; ; : N 1396 2038 3 276 rp C 1 0 scol L ; : N 1399 2038 1764 50 rp C 1 0 scol L ; 0 0 scol : 1402 2041 218 44 rc 1402 2077 M (astroObject)[22 22 13 15 24 30 24 11 22 22 0]xS ; 0.754 0 scol : 1574 2085 1592 6 rc N 1577 2088 M 3166 2088 I : 2.969 2.969 +S K ; ; : 3160 2038 6 53 rc N 3163 2038 M 3163 2091 I : 2.969 2.969 +S K ; ; 1 0 scol : 1399 2085 185 6 rc N 1399 2088 M 1580 2088 I : 2.969 2.969 +S K ; ; : N 53 2091 173 54 rp C L ; : N 53 2145 173 3 rp C L ; 0.754 0 scol : 223 2091 6 57 rc N 226 2091 M 226 2148 I : 2.969 2.969 +S K ; ; : N 279 2091 377 54 rp C 1 0 scol L ; : N 279 2145 377 3 rp C 1 0 scol L ; : 653 2091 6 57 rc N 656 2091 M 656 2148 I : 2.969 2.969 +S K ; ; : N 710 2091 113 54 rp C 1 0 scol L ; : N 710 2145 113 3 rp C 1 0 scol L ; : 820 2091 6 57 rc N 823 2091 M 823 2148 I : 2.969 2.969 +S K ; ; : N 876 2091 122 54 rp C 1 0 scol L ; : N 876 2145 122 3 rp C 1 0 scol L ; : 995 2091 6 57 rc N 998 2091 M 998 2148 I : 2.969 2.969 +S K ; ; : N 1051 2091 295 54 rp C 1 0 scol L ; : N 1051 2145 295 3 rp C 1 0 scol L ; : 1343 2091 6 57 rc N 1346 2091 M 1346 2148 I : 2.969 2.969 +S K ; ; : N 1399 2091 181 54 rp C 1 0 scol L ; : N 1399 2145 181 3 rp C 1 0 scol L ; : 1577 2091 6 57 rc N 1580 2091 M 1580 2148 I : 2.969 2.969 +S K ; ; : N 1583 2091 48 54 rp C 1 0 scol L ; : 1586 2094 45 39 rc : 16 13 8 16 48 39 1586 2094 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1583 2142 51 6 rc N 1583 2145 M 1634 2145 I : 2.969 2.969 +S K ; ; : N 1631 2091 3 54 rp C 1 0 scol L ; : N 1634 2091 211 54 rp C 1 0 scol L ; 0 0 scol 1637 2130 M (class)[22 11 22 22 0]xS 0.754 0 scol : 1634 2142 214 6 rc N 1634 2145 M 1848 2145 I : 2.969 2.969 +S K ; ; : 1842 2091 6 57 rc N 1845 2091 M 1845 2148 I : 2.969 2.969 +S K ; ; : N 1848 2091 1315 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1851 2129 M (galaxy)[22 22 9 22 18 0]xS 0.754 0 scol : 1848 2142 1318 6 rc N 1848 2145 M 3166 2145 I : 2.969 2.969 +S K ; ; : 3160 2091 6 57 rc N 3163 2091 M 3163 2148 I : 2.969 2.969 +S K ; ; : N 53 2148 173 50 rp C 1 0 scol L ; : N 53 2198 173 3 rp C 1 0 scol L ; : 223 2148 6 53 rc N 226 2148 M 226 2201 I : 2.969 2.969 +S K ; ; : N 279 2148 377 50 rp C 1 0 scol L ; : N 279 2198 377 3 rp C 1 0 scol L ; : 653 2148 6 53 rc N 656 2148 M 656 2201 I : 2.969 2.969 +S K ; ; : N 710 2148 113 50 rp C 1 0 scol L ; : N 710 2198 113 3 rp C 1 0 scol L ; : 820 2148 6 53 rc N 823 2148 M 823 2201 I : 2.969 2.969 +S K ; ; : N 876 2148 122 50 rp C 1 0 scol L ; : N 876 2198 122 3 rp C 1 0 scol L ; : 995 2148 6 53 rc N 998 2148 M 998 2201 I : 2.969 2.969 +S K ; ; : N 1051 2148 295 50 rp C 1 0 scol L ; : N 1051 2198 295 3 rp C 1 0 scol L ; : 1343 2148 6 53 rc N 1346 2148 M 1346 2201 I : 2.969 2.969 +S K ; ; : N 1399 2148 181 50 rp C 1 0 scol L ; : N 1399 2198 181 3 rp C 1 0 scol L ; : 1577 2148 6 53 rc N 1580 2148 M 1580 2201 I : 2.969 2.969 +S K ; ; : N 1595 2156 27 158 rp C 0.91 0 scol L ; 1 0 scol : 1592 2153 7 161 rc N 1595 3737 M 1595 2156 I : 2.969 2.969 +S K ; ; N 1595 2156 M 1622 2156 I : 2.969 2.969 +S K ; 0.496 0 scol : 1616 2153 7 161 rc N 1619 3734 M 1619 2156 I : 2.969 2.969 +S K ; ; : N 1592 2153 33 3 rp C 0.91 0 scol L ; : N 1592 2156 3 158 rp C 0.91 0 scol L ; : N 1622 2156 3 158 rp C 0.91 0 scol L ; : N 1583 2148 9 166 rp C 1 0 scol L ; : N 1625 2148 6 166 rp C 1 0 scol L ; : N 1583 2148 48 5 rp C 1 0 scol L ; : N 1607 2165 M 1607 2168 I 1604 2168 I 1604 2171 I 1601 2171 I 1601 2174 I 1598 2174 I 1598 2177 I 1619 2177 I 1619 2174 I 1616 2174 I 1616 2171 I 1613 2171 I 1613 2168 I 1610 2168 I 1610 2165 I C eoclip : N 1598 2165 21 12 rp C 0 0 scol L ; ; : N 1631 2148 3 166 rp C 1 0 scol L ; : N 1634 2148 1529 50 rp C 1 0 scol L ; 0 0 scol : 1637 2151 264 44 rc F2S26 Ji 1637 2187 M (andProperties)[22 24 24 26 15 24 24 22 15 13 11 22 0]xS ; 0.754 0 scol : 1839 2195 1327 6 rc N 1842 2198 M 3166 2198 I : 2.969 2.969 +S K ; ; : 3160 2148 6 53 rc N 3163 2148 M 3163 2201 I : 2.969 2.969 +S K ; ; 1 0 scol : 1634 2195 215 6 rc N 1634 2198 M 1845 2198 I : 2.969 2.969 +S K ; ; : N 53 2201 173 53 rp C L ; : N 53 2254 173 3 rp C L ; 0.754 0 scol : 223 2201 6 56 rc N 226 2201 M 226 2257 I : 2.969 2.969 +S K ; ; : N 279 2201 377 53 rp C 1 0 scol L ; : N 279 2254 377 3 rp C 1 0 scol L ; : 653 2201 6 56 rc N 656 2201 M 656 2257 I : 2.969 2.969 +S K ; ; : N 710 2201 113 53 rp C 1 0 scol L ; : N 710 2254 113 3 rp C 1 0 scol L ; : 820 2201 6 56 rc N 823 2201 M 823 2257 I : 2.969 2.969 +S K ; ; : N 876 2201 122 53 rp C 1 0 scol L ; : N 876 2254 122 3 rp C 1 0 scol L ; : 995 2201 6 56 rc N 998 2201 M 998 2257 I : 2.969 2.969 +S K ; ; : N 1051 2201 295 53 rp C 1 0 scol L ; : N 1051 2254 295 3 rp C 1 0 scol L ; : 1343 2201 6 56 rc N 1346 2201 M 1346 2257 I : 2.969 2.969 +S K ; ; : N 1399 2201 181 53 rp C 1 0 scol L ; : N 1399 2254 181 3 rp C 1 0 scol L ; : 1577 2201 6 56 rc N 1580 2201 M 1580 2257 I : 2.969 2.969 +S K ; ; : N 1634 2201 211 53 rp C 1 0 scol L ; : N 1634 2254 211 3 rp C 1 0 scol L ; : 1842 2201 6 56 rc N 1845 2201 M 1845 2257 I : 2.969 2.969 +S K ; ; : N 1848 2201 47 53 rp C 1 0 scol L ; : 1850 2204 45 39 rc : 16 13 8 16 48 39 1850 2204 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 1848 2251 50 6 rc N 1848 2254 M 1898 2254 I : 2.969 2.969 +S K ; ; : N 1895 2201 3 53 rp C 1 0 scol L ; : N 1898 2201 208 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1901 2240 M (name)[24 22 35 0]xS 0.754 0 scol : 1898 2251 211 6 rc N 1898 2254 M 2109 2254 I : 2.969 2.969 +S K ; ; : 2103 2201 6 56 rc N 2106 2201 M 2106 2257 I : 2.969 2.969 +S K ; ; : N 2109 2201 1054 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2112 2239 M (@galaxyName)[40 22 22 9 22 18 19 28 22 33 0]xS 0.754 0 scol : 2109 2251 1057 6 rc N 2109 2254 M 3166 2254 I : 2.969 2.969 +S K ; ; : 3160 2201 6 56 rc N 3163 2201 M 3163 2257 I : 2.969 2.969 +S K ; ; : N 53 2257 173 51 rp C 1 0 scol L ; : N 53 2308 173 3 rp C 1 0 scol L ; : 223 2257 6 54 rc N 226 2257 M 226 2311 I : 2.969 2.969 +S K ; ; : N 279 2257 377 51 rp C 1 0 scol L ; : N 279 2308 377 3 rp C 1 0 scol L ; : 653 2257 6 54 rc N 656 2257 M 656 2311 I : 2.969 2.969 +S K ; ; : N 710 2257 113 51 rp C 1 0 scol L ; : N 710 2308 113 3 rp C 1 0 scol L ; : 820 2257 6 54 rc N 823 2257 M 823 2311 I : 2.969 2.969 +S K ; ; : N 876 2257 122 51 rp C 1 0 scol L ; : N 876 2308 122 3 rp C 1 0 scol L ; : 995 2257 6 54 rc N 998 2257 M 998 2311 I : 2.969 2.969 +S K ; ; : N 1051 2257 295 51 rp C 1 0 scol L ; : N 1051 2308 295 3 rp C 1 0 scol L ; : 1343 2257 6 54 rc N 1346 2257 M 1346 2311 I : 2.969 2.969 +S K ; ; : N 1399 2257 181 51 rp C 1 0 scol L ; : N 1399 2308 181 3 rp C 1 0 scol L ; : 1577 2257 6 54 rc N 1580 2257 M 1580 2311 I : 2.969 2.969 +S K ; ; : N 1634 2257 211 51 rp C 1 0 scol L ; : N 1634 2308 211 3 rp C 1 0 scol L ; : 1842 2257 6 54 rc N 1845 2257 M 1845 2311 I : 2.969 2.969 +S K ; ; : N 1859 2266 27 48 rp C 0.91 0 scol L ; 1 0 scol : 1856 2263 7 51 rc N 1859 2519 M 1859 2266 I : 2.969 2.969 +S K ; ; N 1859 2266 M 1886 2266 I : 2.969 2.969 +S K ; 0.496 0 scol : 1880 2263 7 51 rc N 1883 2516 M 1883 2266 I : 2.969 2.969 +S K ; ; : N 1856 2263 33 3 rp C 0.91 0 scol L ; : N 1856 2266 3 48 rp C 0.91 0 scol L ; : N 1886 2266 3 48 rp C 0.91 0 scol L ; : N 1848 2257 8 57 rp C 1 0 scol L ; : N 1889 2257 6 57 rp C 1 0 scol L ; : N 1848 2257 47 6 rp C 1 0 scol L ; : N 1871 2275 M 1871 2278 I 1868 2278 I 1868 2281 I 1865 2281 I 1865 2284 I 1862 2284 I 1862 2287 I 1883 2287 I 1883 2284 I 1880 2284 I 1880 2281 I 1877 2281 I 1877 2278 I 1874 2278 I 1874 2275 I C eoclip : N 1862 2275 21 12 rp C 0 0 scol L ; ; : N 1895 2257 3 57 rp C 1 0 scol L ; : N 1898 2257 1265 51 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 1901 2295 M (c:)[22 0]xS F2S26 Ji 1937 2296 M (Coords)[28 24 24 15 24 0]xS 0.754 0 scol : 2100 2305 1066 6 rc N 2103 2308 M 3166 2308 I : 2.969 2.969 +S K ; ; : 3160 2257 6 54 rc N 3163 2257 M 3163 2311 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 2305 212 6 rc N 1898 2308 M 2106 2308 I : 2.969 2.969 +S K ; ; LH (%%[Page: 1]%%) = %%PageTrailer %%Page: 2 2 %%PageBoundingBox: 15 13 597 780 %%EndPageComments %%BeginPageSetup /DeviceRGB dup setcolorspace /colspABC exch def mysetup concat colspRefresh %%EndPageSetup /DeviceGray dup setcolorspace /colspABC exch def : 550 348 8 550 172 109 1509 0 F F 3 [ 0 ] F X doNimage JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$qZ#aZJcC<$qu;6IK)aI' JcCB&JcCN*c2`FqM#W&+MuUcsJcC]/JcCf2^&W`aOT0n3PQ/&kJcCu7JcD&9YQ07SQiDX:R/a5f JcD/V>u2ISH"0?T)YG`JcDABJcDDCS,e-?U&T]DUApS\JcDMFJcDPGPQ6:7V>l,HVZ2_X JcDYJJcD\KMu\G/WW.PLWrIkTJcDeNJcDhOKE-T'XoEtPXoEtQJcDnQJcDqRJH5ZLJcDtSJcE"T JH5NHJcE%UJcE%UJH5HFJcE(VJcE+WJH5CCX8qqnec::$d/S[sd/Vc!mJjNnmJki>JcF-tJcF*s gApI;\cCsogAlg)dJndtdJqu%jSupojT"!8JcF0uJcF0uh#QF6^]bCn h>c=3JcF7"JcF4!hZ2F2`W4cnhZ/6-eGk+"eGnD+g&K+ng&Kq0JcF:#JcF:#hZ2:.aoL&nhZ/6- f)L=$ec4P-ec3hnec4P-JcF=$JcF=$huM7+c2c>nhuJ?.fDgF%fDjb/dJqPndJr,)JcFC&JcF@% huM.(dK%Vni;eH/f`-O&f`0k0cMuAoli6b\m/PuDJcFF'JcFC&i;h+%ec>+;o)S4Yi;eH/g&HX' g&Kt1bQ$2pmf2_UnGhDHJcFI(JcFI(huLn!g&UUAlN$JThuJ?.g])j)gAg(2aT(#qn,MVPo)IVJ JcFL)JcFL)huLdsh>m$Ek5b)QhuJ?.h#Ds*g]-13`W+irn,MJLoDd_KJcFO*JcFO*hZ1UpiW/HI j8efOhZ/6-h>`'+h#H:4_Z/Zsn,MAIoDd_KJcFR+JcFR+hZ1LmjoFlMi;iKLhZ/6-hZ&0,h>c@4 _#NTun,M8Fo`*eKJcFU,JcFU,h>k=jl2^;Qh>m3Jh>i-,huA9-hZ)F4^AmO"n,M2DoDd\JJcFX- JcFX-h>k4gmJu_UgApmGh>i-,i;\B.huDO5]Dq@#n,M)Ao`*bJJcF[.JcF[.h#P%dnc8.Yf`:[E h#N$+iW"K/i;_U5\c;:%n,M#?o`*_IJcF^/JcF^/g]4kap&OR]f)YICg]2p*ir=T0iW%[5\,Z4' n,Lr=o`*\HJcFa0JcF^/g]4e_q>g!aeH#7Ag]2p*ir=T0ir@^4[f?7*n,Ll;o`*YGJcFd1JcFa0 g&SP\rW)Eee,].@g&Q^(j8X]1j8[d4[/U++n,Li:o`*SEJcFg2JcFd1f`7cHdK&q>f`6U'jSsf2 j8[d4U]8aBoDdJDJcFg2JcFg2f)VZId/`h=f)UC%jo9o3jT!g3VZ5$DoDdDBJcFj3JcFg2f)V`K d/`b;f)UC%jo9o3jo JcFm4JcFj3e,ZWNciEV9e,Y("k5U#4k5Wj0YQ)rLnc.#;JcFp5JcFm4dK$NOciES8dK"jukPp,5 k5Wg/ZN&8OnGgl9JcFp5JcFm4ciCHQciES8ciAXskPp,5kPrg-[f=\SnGgc6JcFs6JcFp5blG9R ciES8blE=pkl656kPra+])U+WnGg]4JcFs6JcFp5b5f3Td/`Y8b5d+nkl656kl8a)^AlR\n,LK0 JcG!7JcFs6a8j$Ud/`Y8a8gekl2Q>7kl8['_Z/!`n,LE.JcG!7JcFs6`W3sWd/`Y8`W1Sil2Q>7 kl8U%`rFEdn,L?,JcG!7JcG!7_Z7dXd/`Y8_Z58flMlG8l2SU#b5]ihn,L6)JcG$8JcG!7_#V^Z d/`Y8_#T&dlMlG8l2SO!cMu8ln,L0'JcG$8JcG!7^AuX\d/`Y8^AriblMlG8l2SHtdf7\pn,L*% JcG$8JcG!7]`?R^d/`Y8]`bn'n,KisJcG'9JcG$8[K,4b dK&b9[K(mYli2P9lMn6li;_7+n,KcqJcG'9JcG$8ZiK(be,\t;ZiG[Wli2P9lMn0jj8[U/n,K]o JcG'9JcG$8Z2itceH#(YQ07Sli2P9 lMn$fkPs07n,KQkJcG'9JcG$8YQ3hcfDt@>YQ07Sli2P9lMn*hjo.ln,L0' JcG$8JcG!7_#Va[ciEP7_#T&dlMlG8l2SU#bQ#ohn,L6)JcG$8JcG!7_Z7gYciEP7_Z58flMlG8 kl8U%a8aKdn,L?,JcG!7JcFs6`W4!XciEP7`W1Sil2Q>7kl8['_uJ'`n,LE.JcG!7JcFs6a8j'V ciEP7a8gekl2Q>7kl8a)^]2X\n,LK0JcG!7JcFs6aoK-TciEP7aoI"ml2Q>7kPra+]Dp4Xn,LT3 JcFs6JcFp5blG@Bg]2p*ir=T0i;_U5\Gu7&n,Lu>o`*_I JcF^/JcF[.h#P"coDn@[fDtRDh#N$+iW"K/i;_U5])V=$n,M&@o`*_IJcF^/JcFX-h>k1fn,VqW g&UdFh>i-,i;\B.huDO5]`7C"n,M,Bo`*bJJcF[.JcFU,h>k:ili?MSh#R*Ih>i-,huA9-hZ)F4 ^]3R!n,M5Eo`*bJJcFX-JcFR+hZ1IlkQ()OhZ3c@4_>iWtn,M>HoDd\JJcFU, JcFO*huLXoj8eZKiW/TMhuJ?.h>`'+h#H73`;efsn,MGKoDd\JJcFR+JcFL)huLarhuN6GjoFuP huJ?.h#Ds*g]-13`rFlqn,MPNo)IVJJcFO*JcFI(huLjug]6gCklC;ShuJ?.g])j)g&L"2aoC&p mf2YSnGhGIJcFI(JcFF'huLt#fDt@>mf;kWhuJ?.gAca(f`0n1bl?5omJlbXmf25GJcFF'JcFC& huM(&e,\h7q#Kd]huJ?.g&HX'fDjb/d/VMod/W#(JcFC&JcF=$huM4*ciDMohuJ?.fDgF%f)OY. e,R\ne,S>+JcF@%JcF:#huM=-bQ-2nhuJ?.f)L=$eGnG,fDitnfDjb/JcF:#JcF7"hZ2@0a8jon hZ/6-ec14#e,S8)h#G@oh#H42JcF7"JcF0uh>lI5_>rKnh>i-,e,P"!df8)&ir?doir@d6JcF4! JcF-tg]6I9]E%'ng]2p*df4mud/Vf"lMn?olMoQJcE4ZJcE.XJH56@JcE1Y JcE(VJH5BDJcE+WJcE%UJH5HFJcE(VJcDtSJH5TJJcE"TJcDnQJH,ZMJcDqRJcDkPJcLB%Y5a(Q X8dnSJcDhOJcD_LM?&5-WrIYMVuMbWJcD\KJcDSHOoU(5VZ25IU]6V[JcDPGJcDGDRK.p=UAofE TDtJ_JcDDCJcD;@U&]cET)XBARfB;dJcD5>JcD):XoO%QR/_a;PlJ)jJcD#8JcCl4\c@<]P5g+5 NrQlpJcCf2JcCW-a8gekMuSA.L&]R$JcCK)JcC<$s8UpUJcC<$!<7WMJcGECnc47@JcGHDJcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)Q2gLWJcC<$e,P"!Q2gLWJcFs6i;ei:JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6i;ei: JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!G o`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'mMoDnC\o`4jg blI54o`4R_i;iWPirJNIp&OU^p&OpgkQ$>:MuWDLoDeF_q>\S;o)J@_p&EkKp]'.Onc/:_nGi1^ q>]LUM>rJ5oDnRaoDn[da8kl4o`4^ch#R3Lh>m0Ip&OU^p&OpgiW+o:M?!2Jp]'jcp]&86p&F[b p]'"Kp]'"Kp&F^cnGi1^q>]CRN;n_6oDn^eoDnUb`W5`4o`4degAq!JgApsIp&OU^p&O.Qp&L*P L]?uHqu?9gp&E#3pAadcq#B(Kp]&qIp]'penGi1^iW&ZQNW4b5oDnjioDnO`p&Oabo`4^coDnXc o`4gfoDm_Io`4U`o)SRcp&OU^p&O%Np]-?SK`C]Fs8V]koDeLao`+Rap&F[bp]'mdq>^*fh#I$I nc/4]q>^-gnGi1^i;`QPNrOb3kQ(2Rp&Oabo`4Xap&Ojeo`4gfo`3eIo`4L]o`4gfp&OU^p&O%N p]-?SK)b*9nc/:_o`+Rao`+Ubp]'mdq>^*fh#I$In,N%\qZ$6hnGi1^iW&ZQNW4S0li?PTp&Oab o`4Xao`4deo`4gfo)RYIo`4I\o`4jgp&OU^p&O+PpAg3QJc>`Mmf;eUp&Oabo`4Xao`4deo`4gf hZ36Io`4F[p&Oshp&OU^p&Opgi;ei:JcGcMnGqtVp&Oabo`4Xao`4deo`4deh#R-Jo`4F[p&Osh p&OU^p&OpgiW+o:JcG`Lo)S.Wp&Oabo`4Xao`4deo`4adg]7*Ko`4F[p&Oshp&OU^p&OpgirFu: JcG`Lo)S.Wp&Oabo`4Xao`4deo`4^cg]7-Lo`4F[p&Oshp&OU^p&OpgjoC2:JcGcMnGqtVp&Oab o`4Xao`4deo`4Xah>m?No`4F[p&Oshp&OU^p&K[DjSsf2!<;Kfmf2t\o`+Rao`+Raq#C!emf2;I q>^*fn,N%\qZ$6hnGi1^JcFg2JcG*;n,N(]o`+Rao`+Raq#C!eh#I$Iq>^*fn,N%\qZ$6hnGi1^ JcFg2K)b-:nGi1^o`+Rao`+Raq#C!eg]-sIq>^*fn,N%\qZ$6hnGi1^JcFg2K`C38o)JC`o`+Ra o`+Raq#C!eg]-sIq>^*fnGi.]q>^-gnGi1^JcFg2L&^cFs8V]koDeLao`+Rao`+Raq#C!eg]-sI q>^*fo)J:]q>^*fnc/:_JcFg2LB$lGrVuKio`+Ubo`+Rao`+Raq#C!eh#I$Iq>^*fo`+I^p]'jc oDeLaJcFg2L]?uHqu?9gp&F^co`+Rao`+Raq#C!eq#B"Iq>].KpA`kIJcFg2M#[)Iq>^'epAagd o`+Rao`+Raq#C!eq#B%Jq#B(Ko`*\HJcFg2M?!2Jp]'jcp]'peo`+Rao`+Raq#C!eq#B(Kp]'"K o)IMGJcFg2MZ<;Kp&FXaq#C$fo`+Rao`+Raq#C!eq#B+LpA`tLn,M5EJcFg2MuWDLoDeF_q>^-g o`+Rao`+Raq#C!eq#B.Mp&EqMli5lCJcFg2N;rMMnc/4]qZ$6ho`+Rao`+Raq#C!eq#B7Po)IbN j8\0?JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j3/JcFd1JcC<$ d/Wb=_Z09/JcFd1JcC<$d/Wb=`W,K/JcFd1JcC<$d/Wb=g]-(0JcFa0JcC<$d/Wb=g]-+1JcF^/ JcC<$d/Wb=g]-.2JcF[.JcC<$d/Wb=g]-44JcFU,JcC<$d/Wb=g]-:6JcFO*JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)~> Z ; 0 0 scol F0S22 Ji 0 66 M (I:\\NVO\\voql\\useCase1.xml)[9 9 9 25 23 26 9 17 18 18 7 9 19 17 18 25 18 17 18 19 9 16 27 0]xS 2918 66 M (0)S 2937 66 M (3)S 2956 66 M (/)S 2965 66 M (0)S 2984 66 M (5)S 3003 66 M (/)S 3012 66 M (0)S 3031 66 M (3)S 3050 66 M ( )S 3059 66 M (1)S 3078 66 M (1)S 3097 66 M (:)S 3106 66 M (5)S 3125 66 M (9)S 3144 66 M (:)S 3153 66 M (4)S 3172 66 M (7)S 0 2415 M (\2511998-2003 Altova GmbH http://www.xmlspy.com)[25 19 19 19 19 11 19 19 19 19 9 23 7 9 18 17 18 9 26 27 18 25 9 9 9 19 9 9 18 9 9 9 23 23 23 9 16 27 7 17 18 17 9 17 18 0]xS 3086 2415 M (P)S 3109 2415 M (a)S 3127 2415 M (g)S 3145 2415 M (e)S 3163 2415 M ( )S 3172 2415 M (2)S 1357 2415 M (Registered to Ed Shaya \(NASA\))[25 18 18 7 17 9 18 11 18 18 9 9 18 9 23 18 9 23 19 18 17 18 9 11 25 23 23 23 0]xS solid N 0 81 M 1463 81 I K N 3191 81 M 1725 81 I K N 0 2375 M 3191 2375 I K 0.754 0 scol 1 Lj 1 Lc solid : 0 154 4 2158 rc N 0 157 M 0 2308 I : 2.969 2.969 +S K ; ; : N 15 160 27 2148 rp C 0.91 0 scol L ; 1 0 scol : 12 160 7 2148 rc N 15 3621 M 15 -1758 I : 2.969 2.969 +S K ; ; 0.496 0 scol : 36 160 7 2148 rc N 39 3618 M 39 -1758 I : 2.969 2.969 +S K ; ; : N 12 160 3 2148 rp C 0.91 0 scol L ; : N 42 160 3 2148 rp C 0.91 0 scol L ; : N 3 160 9 2148 rp C 1 0 scol L ; : N 45 160 5 2148 rp C 1 0 scol L ; : N 50 160 3 2148 rp C 1 0 scol L ; : N 53 160 173 54 rp C 1 0 scol L ; : N 53 214 173 3 rp C 1 0 scol L ; 0.754 0 scol : 223 160 6 57 rc N 226 160 M 226 217 I : 2.969 2.969 +S K ; ; : N 241 160 26 2026 rp C 0.91 0 scol L ; 1 0 scol : 238 160 7 2030 rc N 241 2186 M 241 -1375 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 241 2183 M 264 2183 I : 2.969 2.969 +S K ; : 261 160 7 2027 rc N 264 2183 M 264 -1375 I : 2.969 2.969 +S K ; ; : N 238 2186 32 3 rp C 0.91 0 scol L ; : N 238 160 3 2026 rp C 0.91 0 scol L ; : N 267 160 3 2026 rp C 0.91 0 scol L ; : N 229 160 9 2035 rp C 1 0 scol L ; : N 270 160 6 2035 rp C 1 0 scol L ; : N 229 2189 47 6 rp C 1 0 scol L ; 0.754 0 scol : 229 2192 50 6 rc N 229 2195 M 279 2195 I : 2.969 2.969 +S K ; ; : N 276 160 3 2035 rp C 1 0 scol L ; : N 279 160 377 54 rp C 1 0 scol L ; : N 279 214 377 3 rp C 1 0 scol L ; : 653 160 6 57 rc N 656 160 M 656 217 I : 2.969 2.969 +S K ; ; : N 671 160 27 1426 rp C 0.91 0 scol L ; 1 0 scol : 668 160 7 1430 rc N 671 1586 M 671 -1322 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 671 1583 M 695 1583 I : 2.969 2.969 +S K ; : 692 160 7 1427 rc N 695 1583 M 695 -1322 I : 2.969 2.969 +S K ; ; : N 668 1586 33 3 rp C 0.91 0 scol L ; : N 668 160 3 1426 rp C 0.91 0 scol L ; : N 698 160 3 1426 rp C 0.91 0 scol L ; : N 659 160 9 1435 rp C 1 0 scol L ; : N 701 160 6 1435 rp C 1 0 scol L ; : N 659 1589 48 6 rp C 1 0 scol L ; 0.754 0 scol : 659 1592 51 6 rc N 659 1595 M 710 1595 I : 2.969 2.969 +S K ; ; : N 707 160 3 1435 rp C 1 0 scol L ; : N 710 160 113 54 rp C 1 0 scol L ; : N 710 214 113 3 rp C 1 0 scol L ; : 820 160 6 57 rc N 823 160 M 823 217 I : 2.969 2.969 +S K ; ; : N 838 160 26 1426 rp C 0.91 0 scol L ; 1 0 scol : 835 160 7 1430 rc N 838 1586 M 838 -1212 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 838 1583 M 861 1583 I : 2.969 2.969 +S K ; : 858 160 7 1427 rc N 861 1583 M 861 -1212 I : 2.969 2.969 +S K ; ; : N 835 1586 32 3 rp C 0.91 0 scol L ; : N 835 160 3 1426 rp C 0.91 0 scol L ; : N 864 160 3 1426 rp C 0.91 0 scol L ; : N 826 160 9 1435 rp C 1 0 scol L ; : N 867 160 6 1435 rp C 1 0 scol L ; : N 826 1589 47 6 rp C 1 0 scol L ; 0.754 0 scol : 826 1592 50 6 rc N 826 1595 M 876 1595 I : 2.969 2.969 +S K ; ; : N 873 160 3 1435 rp C 1 0 scol L ; : N 876 160 122 54 rp C 1 0 scol L ; : N 876 214 122 3 rp C 1 0 scol L ; : 995 160 6 57 rc N 998 160 M 998 217 I : 2.969 2.969 +S K ; ; : N 1013 160 27 1426 rp C 0.91 0 scol L ; 1 0 scol : 1010 160 7 1430 rc N 1013 1586 M 1013 -157 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 1013 1583 M 1037 1583 I : 2.969 2.969 +S K ; : 1034 160 7 1427 rc N 1037 1583 M 1037 -157 I : 2.969 2.969 +S K ; ; : N 1010 1586 33 3 rp C 0.91 0 scol L ; : N 1010 160 3 1426 rp C 0.91 0 scol L ; : N 1040 160 3 1426 rp C 0.91 0 scol L ; : N 1001 160 9 1435 rp C 1 0 scol L ; : N 1043 160 6 1435 rp C 1 0 scol L ; : N 1001 1589 48 6 rp C 1 0 scol L ; 0.754 0 scol : 1001 1592 50 6 rc N 1001 1595 M 1052 1595 I : 2.969 2.969 +S K ; ; : N 1049 160 2 1435 rp C 1 0 scol L ; : N 1051 160 295 54 rp C 1 0 scol L ; : N 1051 214 295 3 rp C 1 0 scol L ; : 1343 160 6 57 rc N 1346 160 M 1346 217 I : 2.969 2.969 +S K ; ; : N 1360 160 27 1426 rp C 0.91 0 scol L ; 1 0 scol : 1357 160 7 1430 rc N 1360 1586 M 1360 -104 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 1360 1583 M 1384 1583 I : 2.969 2.969 +S K ; : 1381 160 7 1427 rc N 1384 1583 M 1384 -104 I : 2.969 2.969 +S K ; ; : N 1357 1586 33 3 rp C 0.91 0 scol L ; : N 1357 160 3 1426 rp C 0.91 0 scol L ; : N 1387 160 3 1426 rp C 0.91 0 scol L ; : N 1349 160 8 1435 rp C 1 0 scol L ; : N 1390 160 6 1435 rp C 1 0 scol L ; : N 1349 1589 47 6 rp C 1 0 scol L ; 0.754 0 scol : 1349 1592 50 6 rc N 1349 1595 M 1399 1595 I : 2.969 2.969 +S K ; ; : N 1396 160 3 1435 rp C 1 0 scol L ; : N 1399 160 181 54 rp C 1 0 scol L ; : N 1399 214 181 3 rp C 1 0 scol L ; : 1577 160 6 57 rc N 1580 160 M 1580 217 I : 2.969 2.969 +S K ; ; : N 1595 160 27 1426 rp C 0.91 0 scol L ; 1 0 scol : 1592 160 7 1430 rc N 1595 1586 M 1595 6 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 1595 1583 M 1619 1583 I : 2.969 2.969 +S K ; : 1616 160 7 1427 rc N 1619 1583 M 1619 6 I : 2.969 2.969 +S K ; ; : N 1592 1586 33 3 rp C 0.91 0 scol L ; : N 1592 160 3 1426 rp C 0.91 0 scol L ; : N 1622 160 3 1426 rp C 0.91 0 scol L ; : N 1583 160 9 1435 rp C 1 0 scol L ; : N 1625 160 6 1435 rp C 1 0 scol L ; : N 1583 1589 48 6 rp C 1 0 scol L ; 0.754 0 scol : 1583 1592 51 6 rc N 1583 1595 M 1634 1595 I : 2.969 2.969 +S K ; ; : N 1631 160 3 1435 rp C 1 0 scol L ; : N 1634 160 211 54 rp C 1 0 scol L ; : N 1634 214 211 3 rp C 1 0 scol L ; : 1842 160 6 57 rc N 1845 160 M 1845 217 I : 2.969 2.969 +S K ; ; : N 1859 160 27 208 rp C 0.91 0 scol L ; 1 0 scol : 1856 160 7 212 rc N 1859 368 M 1859 116 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 1859 365 M 1883 365 I : 2.969 2.969 +S K ; : 1880 160 7 209 rc N 1883 365 M 1883 116 I : 2.969 2.969 +S K ; ; : N 1856 368 33 3 rp C 0.91 0 scol L ; : N 1856 160 3 208 rp C 0.91 0 scol L ; : N 1886 160 3 208 rp C 0.91 0 scol L ; : N 1848 160 8 217 rp C 1 0 scol L ; : N 1889 160 6 217 rp C 1 0 scol L ; : N 1848 371 47 6 rp C 1 0 scol L ; 0.754 0 scol : 1848 374 50 6 rc N 1848 377 M 1898 377 I : 2.969 2.969 +S K ; ; : N 1895 160 3 217 rp C 1 0 scol L ; : N 1898 160 208 54 rp C 1 0 scol L ; : N 1898 214 208 3 rp C 1 0 scol L ; : 2103 160 6 57 rc N 2106 160 M 2106 217 I : 2.969 2.969 +S K ; ; : N 2109 160 47 54 rp C 1 0 scol L ; : 2112 163 44 39 rc : 16 13 8 16 47 39 2112 163 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 211 50 6 rc N 2109 214 M 2159 214 I : 2.969 2.969 +S K ; ; : N 2156 160 3 54 rp C 1 0 scol L ; : N 2159 160 318 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2162 199 M (coord_system...)[22 24 24 15 24 22 22 21 22 13 22 35 11 11 0]xS 0.754 0 scol : 2159 211 321 6 rc N 2159 214 M 2480 214 I : 2.969 2.969 +S K ; ; : 2474 160 6 57 rc N 2477 160 M 2477 217 I : 2.969 2.969 +S K ; ; : N 2480 160 683 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 198 M (equatorial)[22 22 22 22 11 22 13 9 22 0]xS 0.754 0 scol : 2480 211 686 6 rc N 2480 214 M 3166 214 I : 2.969 2.969 +S K ; ; : 3160 160 6 57 rc N 3163 160 M 3163 217 I : 2.969 2.969 +S K ; ; : N 53 217 173 50 rp C 1 0 scol L ; : N 53 267 173 3 rp C 1 0 scol L ; : 223 217 6 53 rc N 226 217 M 226 270 I : 2.969 2.969 +S K ; ; : N 279 217 377 50 rp C 1 0 scol L ; : N 279 267 377 3 rp C 1 0 scol L ; : 653 217 6 53 rc N 656 217 M 656 270 I : 2.969 2.969 +S K ; ; : N 710 217 113 50 rp C 1 0 scol L ; : N 710 267 113 3 rp C 1 0 scol L ; : 820 217 6 53 rc N 823 217 M 823 270 I : 2.969 2.969 +S K ; ; : N 876 217 122 50 rp C 1 0 scol L ; : N 876 267 122 3 rp C 1 0 scol L ; : 995 217 6 53 rc N 998 217 M 998 270 I : 2.969 2.969 +S K ; ; : N 1051 217 295 50 rp C 1 0 scol L ; : N 1051 267 295 3 rp C 1 0 scol L ; : 1343 217 6 53 rc N 1346 217 M 1346 270 I : 2.969 2.969 +S K ; ; : N 1399 217 181 50 rp C 1 0 scol L ; : N 1399 267 181 3 rp C 1 0 scol L ; : 1577 217 6 53 rc N 1580 217 M 1580 270 I : 2.969 2.969 +S K ; ; : N 1634 217 211 50 rp C 1 0 scol L ; : N 1634 267 211 3 rp C 1 0 scol L ; : 1842 217 6 53 rc N 1845 217 M 1845 270 I : 2.969 2.969 +S K ; ; : N 1898 217 208 50 rp C 1 0 scol L ; : N 1898 267 208 3 rp C 1 0 scol L ; : 2103 217 6 53 rc N 2106 217 M 2106 270 I : 2.969 2.969 +S K ; ; : N 2121 226 27 142 rp C 0.91 0 scol L ; 1 0 scol N 2121 368 M 2121 226 I : 2.969 2.969 +S K ; N 2121 226 M 2148 226 I : 2.969 2.969 +S K ; 0.496 0 scol N 2121 365 M 2145 365 I : 2.969 2.969 +S K ; N 2145 365 M 2145 226 I : 2.969 2.969 +S K ; : N 2118 223 32 3 rp C 0.91 0 scol L ; : N 2118 368 32 3 rp C 0.91 0 scol L ; : N 2118 226 3 142 rp C 0.91 0 scol L ; : N 2148 226 2 142 rp C 0.91 0 scol L ; : N 2109 217 9 160 rp C 1 0 scol L ; : N 2150 217 6 160 rp C 1 0 scol L ; : N 2109 217 47 6 rp C 1 0 scol L ; : N 2109 371 47 6 rp C 1 0 scol L ; : N 2133 235 M 2133 238 I 2130 238 I 2130 241 I 2127 241 I 2127 244 I 2124 244 I 2124 247 I 2145 247 I 2145 244 I 2142 244 I 2142 241 I 2139 241 I 2139 238 I 2136 238 I 2136 235 I C eoclip : N 2124 235 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2109 374 50 6 rc N 2109 377 M 2159 377 I : 2.969 2.969 +S K ; ; : N 2156 217 3 160 rp C 1 0 scol L ; : N 2159 217 1004 50 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2162 255 M (c:)[22 0]xS : 2198 220 305 44 rc F2S26 Ji 2198 256 M (CoordLongitude)[28 24 24 15 24 24 24 24 24 11 13 24 24 0]xS ; 0.754 0 scol : 2471 264 695 6 rc N 2474 267 M 3166 267 I : 2.969 2.969 +S K ; ; : 3160 217 6 53 rc N 3163 217 M 3163 270 I : 2.969 2.969 +S K ; ; 1 0 scol : 2159 264 322 6 rc N 2159 267 M 2477 267 I : 2.969 2.969 +S K ; ; : N 53 270 173 51 rp C L ; : N 53 321 173 3 rp C L ; 0.754 0 scol : 223 270 6 54 rc N 226 270 M 226 324 I : 2.969 2.969 +S K ; ; : N 279 270 377 51 rp C 1 0 scol L ; : N 279 321 377 3 rp C 1 0 scol L ; : 653 270 6 54 rc N 656 270 M 656 324 I : 2.969 2.969 +S K ; ; : N 710 270 113 51 rp C 1 0 scol L ; : N 710 321 113 3 rp C 1 0 scol L ; : 820 270 6 54 rc N 823 270 M 823 324 I : 2.969 2.969 +S K ; ; : N 876 270 122 51 rp C 1 0 scol L ; : N 876 321 122 3 rp C 1 0 scol L ; : 995 270 6 54 rc N 998 270 M 998 324 I : 2.969 2.969 +S K ; ; : N 1051 270 295 51 rp C 1 0 scol L ; : N 1051 321 295 3 rp C 1 0 scol L ; : 1343 270 6 54 rc N 1346 270 M 1346 324 I : 2.969 2.969 +S K ; ; : N 1399 270 181 51 rp C 1 0 scol L ; : N 1399 321 181 3 rp C 1 0 scol L ; : 1577 270 6 54 rc N 1580 270 M 1580 324 I : 2.969 2.969 +S K ; ; : N 1634 270 211 51 rp C 1 0 scol L ; : N 1634 321 211 3 rp C 1 0 scol L ; : 1842 270 6 54 rc N 1845 270 M 1845 324 I : 2.969 2.969 +S K ; ; : N 1898 270 208 51 rp C 1 0 scol L ; : N 1898 321 208 3 rp C 1 0 scol L ; : 2103 270 6 54 rc N 2106 270 M 2106 324 I : 2.969 2.969 +S K ; ; : N 2159 270 318 51 rp C 1 0 scol L ; : N 2159 321 318 3 rp C 1 0 scol L ; : 2474 270 6 54 rc N 2477 270 M 2477 324 I : 2.969 2.969 +S K ; ; : N 2492 279 27 89 rp C 0.91 0 scol L ; 1 0 scol N 2492 368 M 2492 279 I : 2.969 2.969 +S K ; N 2492 279 M 2519 279 I : 2.969 2.969 +S K ; 0.496 0 scol N 2492 365 M 2516 365 I : 2.969 2.969 +S K ; N 2516 365 M 2516 279 I : 2.969 2.969 +S K ; : N 2489 276 33 3 rp C 0.91 0 scol L ; : N 2489 368 33 3 rp C 0.91 0 scol L ; : N 2489 279 3 89 rp C 0.91 0 scol L ; : N 2519 279 3 89 rp C 0.91 0 scol L ; : N 2480 270 9 107 rp C 1 0 scol L ; : N 2522 270 6 107 rp C 1 0 scol L ; : N 2480 270 48 6 rp C 1 0 scol L ; : N 2480 371 48 6 rp C 1 0 scol L ; : N 2504 288 M 2504 291 I 2501 291 I 2501 294 I 2498 294 I 2498 297 I 2495 297 I 2495 300 I 2516 300 I 2516 297 I 2513 297 I 2513 294 I 2510 294 I 2510 291 I 2507 291 I 2507 288 I C eoclip : N 2495 288 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2480 374 51 6 rc N 2480 377 M 2531 377 I : 2.969 2.969 +S K ; ; : N 2528 270 3 107 rp C 1 0 scol L ; : N 2531 270 632 51 rp C 1 0 scol L ; 0 0 scol 2534 308 M (c:)[22 0]xS F2S26 Ji 2569 309 M (CoordValue)[28 24 24 15 24 26 22 11 24 0]xS 0.754 0 scol : 2783 318 383 6 rc N 2786 321 M 3166 321 I : 2.969 2.969 +S K ; ; : 3160 270 6 54 rc N 3163 270 M 3163 324 I : 2.969 2.969 +S K ; ; 1 0 scol : 2531 318 262 6 rc N 2531 321 M 2789 321 I : 2.969 2.969 +S K ; ; : N 53 324 173 53 rp C L ; : N 53 377 173 3 rp C L ; 0.754 0 scol : 223 324 6 56 rc N 226 324 M 226 380 I : 2.969 2.969 +S K ; ; : N 279 324 377 53 rp C 1 0 scol L ; : N 279 377 377 3 rp C 1 0 scol L ; : 653 324 6 56 rc N 656 324 M 656 380 I : 2.969 2.969 +S K ; ; : N 710 324 113 53 rp C 1 0 scol L ; : N 710 377 113 3 rp C 1 0 scol L ; : 820 324 6 56 rc N 823 324 M 823 380 I : 2.969 2.969 +S K ; ; : N 876 324 122 53 rp C 1 0 scol L ; : N 876 377 122 3 rp C 1 0 scol L ; : 995 324 6 56 rc N 998 324 M 998 380 I : 2.969 2.969 +S K ; ; : N 1051 324 295 53 rp C 1 0 scol L ; : N 1051 377 295 3 rp C 1 0 scol L ; : 1343 324 6 56 rc N 1346 324 M 1346 380 I : 2.969 2.969 +S K ; ; : N 1399 324 181 53 rp C 1 0 scol L ; : N 1399 377 181 3 rp C 1 0 scol L ; : 1577 324 6 56 rc N 1580 324 M 1580 380 I : 2.969 2.969 +S K ; ; : N 1634 324 211 53 rp C 1 0 scol L ; : N 1634 377 211 3 rp C 1 0 scol L ; : 1842 324 6 56 rc N 1845 324 M 1845 380 I : 2.969 2.969 +S K ; ; : N 1898 324 208 53 rp C 1 0 scol L ; : 1898 374 211 6 rc N 1898 377 M 2109 377 I : 2.969 2.969 +S K ; ; : 2103 324 6 56 rc N 2106 324 M 2106 380 I : 2.969 2.969 +S K ; ; : N 2159 324 318 53 rp C 1 0 scol L ; : 2159 374 321 6 rc N 2159 377 M 2480 377 I : 2.969 2.969 +S K ; ; : 2474 324 6 56 rc N 2477 324 M 2477 380 I : 2.969 2.969 +S K ; ; : N 2531 324 258 53 rp C 1 0 scol L ; : 2531 374 261 6 rc N 2531 377 M 2792 377 I : 2.969 2.969 +S K ; ; : 2786 324 6 56 rc N 2789 324 M 2789 380 I : 2.969 2.969 +S K ; ; : N 2792 324 48 53 rp C 1 0 scol L ; : 2795 327 45 38 rc : 16 13 8 16 48 38 2795 327 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 2792 374 51 6 rc N 2792 377 M 2843 377 I : 2.969 2.969 +S K ; ; : N 2840 324 3 53 rp C 1 0 scol L ; : N 2843 324 199 53 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2846 362 M (c:)[22 0]xS F2S26 Ji 2881 363 M (Query)[30 24 22 15 0]xS 0.754 0 scol : 2843 374 202 6 rc N 2843 377 M 3045 377 I : 2.969 2.969 +S K ; ; : 3039 324 6 56 rc N 3042 324 M 3042 380 I : 2.969 2.969 +S K ; ; : N 3045 324 118 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 3048 362 M (@)S 3088 362 M (g)S 3110 362 M (.)S 3121 362 M (.)S 3132 362 M (.)S 0.754 0 scol : 3045 374 121 6 rc N 3045 377 M 3166 377 I : 2.969 2.969 +S K ; ; : 3160 324 6 56 rc N 3163 324 M 3163 380 I : 2.969 2.969 +S K ; ; : N 53 380 173 51 rp C 1 0 scol L ; : N 53 431 173 3 rp C 1 0 scol L ; : 223 380 6 54 rc N 226 380 M 226 434 I : 2.969 2.969 +S K ; ; : N 279 380 377 51 rp C 1 0 scol L ; : N 279 431 377 3 rp C 1 0 scol L ; : 653 380 6 54 rc N 656 380 M 656 434 I : 2.969 2.969 +S K ; ; : N 710 380 113 51 rp C 1 0 scol L ; : N 710 431 113 3 rp C 1 0 scol L ; : 820 380 6 54 rc N 823 380 M 823 434 I : 2.969 2.969 +S K ; ; : N 876 380 122 51 rp C 1 0 scol L ; : N 876 431 122 3 rp C 1 0 scol L ; : 995 380 6 54 rc N 998 380 M 998 434 I : 2.969 2.969 +S K ; ; : N 1051 380 295 51 rp C 1 0 scol L ; : N 1051 431 295 3 rp C 1 0 scol L ; : 1343 380 6 54 rc N 1346 380 M 1346 434 I : 2.969 2.969 +S K ; ; : N 1399 380 181 51 rp C 1 0 scol L ; : N 1399 431 181 3 rp C 1 0 scol L ; : 1577 380 6 54 rc N 1580 380 M 1580 434 I : 2.969 2.969 +S K ; ; : N 1634 380 211 51 rp C 1 0 scol L ; : N 1634 431 211 3 rp C 1 0 scol L ; : 1842 380 6 54 rc N 1845 380 M 1845 434 I : 2.969 2.969 +S K ; ; : N 1859 389 27 202 rp C 0.91 0 scol L ; 1 0 scol N 1859 591 M 1859 389 I : 2.969 2.969 +S K ; N 1859 389 M 1886 389 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 588 M 1883 588 I : 2.969 2.969 +S K ; N 1883 588 M 1883 389 I : 2.969 2.969 +S K ; : N 1856 386 33 3 rp C 0.91 0 scol L ; : N 1856 591 33 3 rp C 0.91 0 scol L ; : N 1856 389 3 202 rp C 0.91 0 scol L ; : N 1886 389 3 202 rp C 0.91 0 scol L ; : N 1848 380 8 220 rp C 1 0 scol L ; : N 1889 380 6 220 rp C 1 0 scol L ; : N 1848 380 47 6 rp C 1 0 scol L ; : N 1848 594 47 6 rp C 1 0 scol L ; : N 1871 398 M 1871 401 I 1868 401 I 1868 404 I 1865 404 I 1865 407 I 1862 407 I 1862 410 I 1883 410 I 1883 407 I 1880 407 I 1880 404 I 1877 404 I 1877 401 I 1874 401 I 1874 398 I C eoclip : N 1862 398 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 597 50 6 rc N 1848 600 M 1898 600 I : 2.969 2.969 +S K ; ; : N 1895 380 3 220 rp C 1 0 scol L ; : N 1898 380 1265 51 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 1901 418 M (c:)[22 0]xS F2S26 Ji 1937 419 M (CoordSystem)[28 24 24 15 24 26 21 22 13 22 0]xS 0.754 0 scol : 2100 428 1066 6 rc N 2103 431 M 3166 431 I : 2.969 2.969 +S K ; ; : 3160 380 6 54 rc N 3163 380 M 3163 434 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 428 212 6 rc N 1898 431 M 2106 431 I : 2.969 2.969 +S K ; ; : N 53 434 173 53 rp C L ; : N 53 487 173 3 rp C L ; 0.754 0 scol : 223 434 6 56 rc N 226 434 M 226 490 I : 2.969 2.969 +S K ; ; : N 279 434 377 53 rp C 1 0 scol L ; : N 279 487 377 3 rp C 1 0 scol L ; : 653 434 6 56 rc N 656 434 M 656 490 I : 2.969 2.969 +S K ; ; : N 710 434 113 53 rp C 1 0 scol L ; : N 710 487 113 3 rp C 1 0 scol L ; : 820 434 6 56 rc N 823 434 M 823 490 I : 2.969 2.969 +S K ; ; : N 876 434 122 53 rp C 1 0 scol L ; : N 876 487 122 3 rp C 1 0 scol L ; : 995 434 6 56 rc N 998 434 M 998 490 I : 2.969 2.969 +S K ; ; : N 1051 434 295 53 rp C 1 0 scol L ; : N 1051 487 295 3 rp C 1 0 scol L ; : 1343 434 6 56 rc N 1346 434 M 1346 490 I : 2.969 2.969 +S K ; ; : N 1399 434 181 53 rp C 1 0 scol L ; : N 1399 487 181 3 rp C 1 0 scol L ; : 1577 434 6 56 rc N 1580 434 M 1580 490 I : 2.969 2.969 +S K ; ; : N 1634 434 211 53 rp C 1 0 scol L ; : N 1634 487 211 3 rp C 1 0 scol L ; : 1842 434 6 56 rc N 1845 434 M 1845 490 I : 2.969 2.969 +S K ; ; : N 1898 434 208 53 rp C 1 0 scol L ; : N 1898 487 208 3 rp C 1 0 scol L ; : 2103 434 6 56 rc N 2106 434 M 2106 490 I : 2.969 2.969 +S K ; ; : N 2109 434 47 53 rp C 1 0 scol L ; : 2112 437 44 38 rc : 16 13 8 16 47 38 2112 437 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 484 50 6 rc N 2109 487 M 2159 487 I : 2.969 2.969 +S K ; ; : N 2156 434 3 53 rp C 1 0 scol L ; : N 2159 434 318 53 rp C 1 0 scol L ; 0 0 scol 2162 473 M (coord_system...)[22 24 24 15 24 22 22 21 22 13 22 35 11 11 0]xS 0.754 0 scol : 2159 484 321 6 rc N 2159 487 M 2480 487 I : 2.969 2.969 +S K ; ; : 2474 434 6 56 rc N 2477 434 M 2477 490 I : 2.969 2.969 +S K ; ; : N 2480 434 683 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 472 M (equatorial)[22 22 22 22 11 22 13 9 22 0]xS 0.754 0 scol : 2480 484 686 6 rc N 2480 487 M 3166 487 I : 2.969 2.969 +S K ; ; : 3160 434 6 56 rc N 3163 434 M 3163 490 I : 2.969 2.969 +S K ; ; : N 53 490 173 54 rp C 1 0 scol L ; : N 53 544 173 3 rp C 1 0 scol L ; : 223 490 6 57 rc N 226 490 M 226 547 I : 2.969 2.969 +S K ; ; : N 279 490 377 54 rp C 1 0 scol L ; : N 279 544 377 3 rp C 1 0 scol L ; : 653 490 6 57 rc N 656 490 M 656 547 I : 2.969 2.969 +S K ; ; : N 710 490 113 54 rp C 1 0 scol L ; : N 710 544 113 3 rp C 1 0 scol L ; : 820 490 6 57 rc N 823 490 M 823 547 I : 2.969 2.969 +S K ; ; : N 876 490 122 54 rp C 1 0 scol L ; : N 876 544 122 3 rp C 1 0 scol L ; : 995 490 6 57 rc N 998 490 M 998 547 I : 2.969 2.969 +S K ; ; : N 1051 490 295 54 rp C 1 0 scol L ; : N 1051 544 295 3 rp C 1 0 scol L ; : 1343 490 6 57 rc N 1346 490 M 1346 547 I : 2.969 2.969 +S K ; ; : N 1399 490 181 54 rp C 1 0 scol L ; : N 1399 544 181 3 rp C 1 0 scol L ; : 1577 490 6 57 rc N 1580 490 M 1580 547 I : 2.969 2.969 +S K ; ; : N 1634 490 211 54 rp C 1 0 scol L ; : N 1634 544 211 3 rp C 1 0 scol L ; : 1842 490 6 57 rc N 1845 490 M 1845 547 I : 2.969 2.969 +S K ; ; : N 1898 490 208 54 rp C 1 0 scol L ; : N 1898 544 208 3 rp C 1 0 scol L ; : 2103 490 6 57 rc N 2106 490 M 2106 547 I : 2.969 2.969 +S K ; ; : N 2109 490 47 54 rp C 1 0 scol L ; : 2112 493 44 39 rc : 16 13 8 16 47 39 2112 493 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 541 50 6 rc N 2109 544 M 2159 544 I : 2.969 2.969 +S K ; ; : N 2156 490 3 54 rp C 1 0 scol L ; : N 2159 490 318 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2162 529 M (coord_epoch)[22 24 24 15 24 22 22 24 24 22 0]xS 0.754 0 scol : 2159 541 321 6 rc N 2159 544 M 2480 544 I : 2.969 2.969 +S K ; ; : 2474 490 6 57 rc N 2477 490 M 2477 547 I : 2.969 2.969 +S K ; ; : N 2480 490 683 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 528 M (@epoch)[40 22 22 22 20 0]xS 0.754 0 scol : 2480 541 686 6 rc N 2480 544 M 3166 544 I : 2.969 2.969 +S K ; ; : 3160 490 6 57 rc N 3163 490 M 3163 547 I : 2.969 2.969 +S K ; ; : N 53 547 173 53 rp C 1 0 scol L ; : N 53 600 173 3 rp C 1 0 scol L ; : 223 547 6 56 rc N 226 547 M 226 603 I : 2.969 2.969 +S K ; ; : N 279 547 377 53 rp C 1 0 scol L ; : N 279 600 377 3 rp C 1 0 scol L ; : 653 547 6 56 rc N 656 547 M 656 603 I : 2.969 2.969 +S K ; ; : N 710 547 113 53 rp C 1 0 scol L ; : N 710 600 113 3 rp C 1 0 scol L ; : 820 547 6 56 rc N 823 547 M 823 603 I : 2.969 2.969 +S K ; ; : N 876 547 122 53 rp C 1 0 scol L ; : N 876 600 122 3 rp C 1 0 scol L ; : 995 547 6 56 rc N 998 547 M 998 603 I : 2.969 2.969 +S K ; ; : N 1051 547 295 53 rp C 1 0 scol L ; : N 1051 600 295 3 rp C 1 0 scol L ; : 1343 547 6 56 rc N 1346 547 M 1346 603 I : 2.969 2.969 +S K ; ; : N 1399 547 181 53 rp C 1 0 scol L ; : N 1399 600 181 3 rp C 1 0 scol L ; : 1577 547 6 56 rc N 1580 547 M 1580 603 I : 2.969 2.969 +S K ; ; : N 1634 547 211 53 rp C 1 0 scol L ; : N 1634 600 211 3 rp C 1 0 scol L ; : 1842 547 6 56 rc N 1845 547 M 1845 603 I : 2.969 2.969 +S K ; ; : N 1898 547 208 53 rp C 1 0 scol L ; : 1898 597 211 6 rc N 1898 600 M 2109 600 I : 2.969 2.969 +S K ; ; : 2103 547 6 56 rc N 2106 547 M 2106 603 I : 2.969 2.969 +S K ; ; : N 2109 547 47 53 rp C 1 0 scol L ; : 2112 550 44 38 rc : 16 13 8 16 47 38 2112 550 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 597 50 6 rc N 2109 600 M 2159 600 I : 2.969 2.969 +S K ; ; : N 2156 547 3 53 rp C 1 0 scol L ; : N 2159 547 318 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2162 586 M (coord_ref_frame)[22 24 24 15 24 22 15 22 13 22 13 15 22 35 0]xS 0.754 0 scol : 2159 597 321 6 rc N 2159 600 M 2480 600 I : 2.969 2.969 +S K ; ; : 2474 547 6 56 rc N 2477 547 M 2477 603 I : 2.969 2.969 +S K ; ; : N 2480 547 683 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 585 M (FK5)[24 26 0]xS 0.754 0 scol : 2480 597 686 6 rc N 2480 600 M 3166 600 I : 2.969 2.969 +S K ; ; : 3160 547 6 56 rc N 3163 547 M 3163 603 I : 2.969 2.969 +S K ; ; : N 53 603 173 50 rp C 1 0 scol L ; : N 53 653 173 3 rp C 1 0 scol L ; : 223 603 6 53 rc N 226 603 M 226 656 I : 2.969 2.969 +S K ; ; : N 279 603 377 50 rp C 1 0 scol L ; : N 279 653 377 3 rp C 1 0 scol L ; : 653 603 6 53 rc N 656 603 M 656 656 I : 2.969 2.969 +S K ; ; : N 710 603 113 50 rp C 1 0 scol L ; : N 710 653 113 3 rp C 1 0 scol L ; : 820 603 6 53 rc N 823 603 M 823 656 I : 2.969 2.969 +S K ; ; : N 876 603 122 50 rp C 1 0 scol L ; : N 876 653 122 3 rp C 1 0 scol L ; : 995 603 6 53 rc N 998 603 M 998 656 I : 2.969 2.969 +S K ; ; : N 1051 603 295 50 rp C 1 0 scol L ; : N 1051 653 295 3 rp C 1 0 scol L ; : 1343 603 6 53 rc N 1346 603 M 1346 656 I : 2.969 2.969 +S K ; ; : N 1399 603 181 50 rp C 1 0 scol L ; : N 1399 653 181 3 rp C 1 0 scol L ; : 1577 603 6 53 rc N 1580 603 M 1580 656 I : 2.969 2.969 +S K ; ; : N 1634 603 211 50 rp C 1 0 scol L ; : N 1634 653 211 3 rp C 1 0 scol L ; : 1842 603 6 53 rc N 1845 603 M 1845 656 I : 2.969 2.969 +S K ; ; : N 1859 612 27 252 rp C 0.91 0 scol L ; 1 0 scol N 1859 864 M 1859 612 I : 2.969 2.969 +S K ; N 1859 612 M 1886 612 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 861 M 1883 861 I : 2.969 2.969 +S K ; N 1883 861 M 1883 612 I : 2.969 2.969 +S K ; : N 1856 609 33 3 rp C 0.91 0 scol L ; : N 1856 864 33 3 rp C 0.91 0 scol L ; : N 1856 612 3 252 rp C 0.91 0 scol L ; : N 1886 612 3 252 rp C 0.91 0 scol L ; : N 1848 603 8 270 rp C 1 0 scol L ; : N 1889 603 6 270 rp C 1 0 scol L ; : N 1848 603 47 6 rp C 1 0 scol L ; : N 1848 867 47 6 rp C 1 0 scol L ; : N 1871 621 M 1871 624 I 1868 624 I 1868 627 I 1865 627 I 1865 630 I 1862 630 I 1862 633 I 1883 633 I 1883 630 I 1880 630 I 1880 627 I 1877 627 I 1877 624 I 1874 624 I 1874 621 I C eoclip : N 1862 621 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 870 50 6 rc N 1848 873 M 1898 873 I : 2.969 2.969 +S K ; ; : N 1895 603 3 270 rp C 1 0 scol L ; : N 1898 603 1265 50 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 1901 641 M (c:)[22 0]xS : 1937 606 137 44 rc F2S26 Ji 1937 642 M (Coords)[28 24 24 15 24 0]xS ; 0.754 0 scol : 2100 650 1066 6 rc N 2103 653 M 3166 653 I : 2.969 2.969 +S K ; ; : 3160 603 6 53 rc N 3163 603 M 3163 656 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 650 212 6 rc N 1898 653 M 2106 653 I : 2.969 2.969 +S K ; ; : N 53 656 173 54 rp C L ; : N 53 710 173 3 rp C L ; 0.754 0 scol : 223 656 6 57 rc N 226 656 M 226 713 I : 2.969 2.969 +S K ; ; : N 279 656 377 54 rp C 1 0 scol L ; : N 279 710 377 3 rp C 1 0 scol L ; : 653 656 6 57 rc N 656 656 M 656 713 I : 2.969 2.969 +S K ; ; : N 710 656 113 54 rp C 1 0 scol L ; : N 710 710 113 3 rp C 1 0 scol L ; : 820 656 6 57 rc N 823 656 M 823 713 I : 2.969 2.969 +S K ; ; : N 876 656 122 54 rp C 1 0 scol L ; : N 876 710 122 3 rp C 1 0 scol L ; : 995 656 6 57 rc N 998 656 M 998 713 I : 2.969 2.969 +S K ; ; : N 1051 656 295 54 rp C 1 0 scol L ; : N 1051 710 295 3 rp C 1 0 scol L ; : 1343 656 6 57 rc N 1346 656 M 1346 713 I : 2.969 2.969 +S K ; ; : N 1399 656 181 54 rp C 1 0 scol L ; : N 1399 710 181 3 rp C 1 0 scol L ; : 1577 656 6 57 rc N 1580 656 M 1580 713 I : 2.969 2.969 +S K ; ; : N 1634 656 211 54 rp C 1 0 scol L ; : N 1634 710 211 3 rp C 1 0 scol L ; : 1842 656 6 57 rc N 1845 656 M 1845 713 I : 2.969 2.969 +S K ; ; : N 1898 656 208 54 rp C 1 0 scol L ; : N 1898 710 208 3 rp C 1 0 scol L ; : 2103 656 6 57 rc N 2106 656 M 2106 713 I : 2.969 2.969 +S K ; ; : N 2109 656 47 54 rp C 1 0 scol L ; : 2112 659 44 39 rc : 16 13 8 16 47 39 2112 659 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 707 50 6 rc N 2109 710 M 2159 710 I : 2.969 2.969 +S K ; ; : N 2156 656 3 54 rp C 1 0 scol L ; : N 2159 656 318 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2162 695 M (coord_system...)[22 24 24 15 24 22 22 21 22 13 22 35 11 11 0]xS 0.754 0 scol : 2159 707 321 6 rc N 2159 710 M 2480 710 I : 2.969 2.969 +S K ; ; : 2474 656 6 57 rc N 2477 656 M 2477 713 I : 2.969 2.969 +S K ; ; : N 2480 656 683 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 694 M (equatorial)[22 22 22 22 11 22 13 9 22 0]xS 0.754 0 scol : 2480 707 686 6 rc N 2480 710 M 3166 710 I : 2.969 2.969 +S K ; ; : 3160 656 6 57 rc N 3163 656 M 3163 713 I : 2.969 2.969 +S K ; ; : N 53 713 173 50 rp C 1 0 scol L ; : N 53 763 173 3 rp C 1 0 scol L ; : 223 713 6 53 rc N 226 713 M 226 766 I : 2.969 2.969 +S K ; ; : N 279 713 377 50 rp C 1 0 scol L ; : N 279 763 377 3 rp C 1 0 scol L ; : 653 713 6 53 rc N 656 713 M 656 766 I : 2.969 2.969 +S K ; ; : N 710 713 113 50 rp C 1 0 scol L ; : N 710 763 113 3 rp C 1 0 scol L ; : 820 713 6 53 rc N 823 713 M 823 766 I : 2.969 2.969 +S K ; ; : N 876 713 122 50 rp C 1 0 scol L ; : N 876 763 122 3 rp C 1 0 scol L ; : 995 713 6 53 rc N 998 713 M 998 766 I : 2.969 2.969 +S K ; ; : N 1051 713 295 50 rp C 1 0 scol L ; : N 1051 763 295 3 rp C 1 0 scol L ; : 1343 713 6 53 rc N 1346 713 M 1346 766 I : 2.969 2.969 +S K ; ; : N 1399 713 181 50 rp C 1 0 scol L ; : N 1399 763 181 3 rp C 1 0 scol L ; : 1577 713 6 53 rc N 1580 713 M 1580 766 I : 2.969 2.969 +S K ; ; : N 1634 713 211 50 rp C 1 0 scol L ; : N 1634 763 211 3 rp C 1 0 scol L ; : 1842 713 6 53 rc N 1845 713 M 1845 766 I : 2.969 2.969 +S K ; ; : N 1898 713 208 50 rp C 1 0 scol L ; : N 1898 763 208 3 rp C 1 0 scol L ; : 2103 713 6 53 rc N 2106 713 M 2106 766 I : 2.969 2.969 +S K ; ; : N 2121 722 27 142 rp C 0.91 0 scol L ; 1 0 scol N 2121 864 M 2121 722 I : 2.969 2.969 +S K ; N 2121 722 M 2148 722 I : 2.969 2.969 +S K ; 0.496 0 scol N 2121 861 M 2145 861 I : 2.969 2.969 +S K ; N 2145 861 M 2145 722 I : 2.969 2.969 +S K ; : N 2118 719 32 3 rp C 0.91 0 scol L ; : N 2118 864 32 3 rp C 0.91 0 scol L ; : N 2118 722 3 142 rp C 0.91 0 scol L ; : N 2148 722 2 142 rp C 0.91 0 scol L ; : N 2109 713 9 160 rp C 1 0 scol L ; : N 2150 713 6 160 rp C 1 0 scol L ; : N 2109 713 47 6 rp C 1 0 scol L ; : N 2109 867 47 6 rp C 1 0 scol L ; : N 2133 731 M 2133 734 I 2130 734 I 2130 737 I 2127 737 I 2127 740 I 2124 740 I 2124 743 I 2145 743 I 2145 740 I 2142 740 I 2142 737 I 2139 737 I 2139 734 I 2136 734 I 2136 731 I C eoclip : N 2124 731 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2109 870 50 6 rc N 2109 873 M 2159 873 I : 2.969 2.969 +S K ; ; : N 2156 713 3 160 rp C 1 0 scol L ; : N 2159 713 1004 50 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2162 751 M (c:)[22 0]xS : 2198 716 268 44 rc F2S26 Ji 2198 752 M (CoordLatitude)[28 24 24 15 24 24 22 13 11 13 24 24 0]xS ; 0.754 0 scol : 2471 760 695 6 rc N 2474 763 M 3166 763 I : 2.969 2.969 +S K ; ; : 3160 713 6 53 rc N 3163 713 M 3163 766 I : 2.969 2.969 +S K ; ; 1 0 scol : 2159 760 322 6 rc N 2159 763 M 2477 763 I : 2.969 2.969 +S K ; ; : N 53 766 173 51 rp C L ; : N 53 817 173 3 rp C L ; 0.754 0 scol : 223 766 6 54 rc N 226 766 M 226 820 I : 2.969 2.969 +S K ; ; : N 279 766 377 51 rp C 1 0 scol L ; : N 279 817 377 3 rp C 1 0 scol L ; : 653 766 6 54 rc N 656 766 M 656 820 I : 2.969 2.969 +S K ; ; : N 710 766 113 51 rp C 1 0 scol L ; : N 710 817 113 3 rp C 1 0 scol L ; : 820 766 6 54 rc N 823 766 M 823 820 I : 2.969 2.969 +S K ; ; : N 876 766 122 51 rp C 1 0 scol L ; : N 876 817 122 3 rp C 1 0 scol L ; : 995 766 6 54 rc N 998 766 M 998 820 I : 2.969 2.969 +S K ; ; : N 1051 766 295 51 rp C 1 0 scol L ; : N 1051 817 295 3 rp C 1 0 scol L ; : 1343 766 6 54 rc N 1346 766 M 1346 820 I : 2.969 2.969 +S K ; ; : N 1399 766 181 51 rp C 1 0 scol L ; : N 1399 817 181 3 rp C 1 0 scol L ; : 1577 766 6 54 rc N 1580 766 M 1580 820 I : 2.969 2.969 +S K ; ; : N 1634 766 211 51 rp C 1 0 scol L ; : N 1634 817 211 3 rp C 1 0 scol L ; : 1842 766 6 54 rc N 1845 766 M 1845 820 I : 2.969 2.969 +S K ; ; : N 1898 766 208 51 rp C 1 0 scol L ; : N 1898 817 208 3 rp C 1 0 scol L ; : 2103 766 6 54 rc N 2106 766 M 2106 820 I : 2.969 2.969 +S K ; ; : N 2159 766 318 51 rp C 1 0 scol L ; : N 2159 817 318 3 rp C 1 0 scol L ; : 2474 766 6 54 rc N 2477 766 M 2477 820 I : 2.969 2.969 +S K ; ; : N 2492 775 27 89 rp C 0.91 0 scol L ; 1 0 scol N 2492 864 M 2492 775 I : 2.969 2.969 +S K ; N 2492 775 M 2519 775 I : 2.969 2.969 +S K ; 0.496 0 scol N 2492 861 M 2516 861 I : 2.969 2.969 +S K ; N 2516 861 M 2516 775 I : 2.969 2.969 +S K ; : N 2489 772 33 3 rp C 0.91 0 scol L ; : N 2489 864 33 3 rp C 0.91 0 scol L ; : N 2489 775 3 89 rp C 0.91 0 scol L ; : N 2519 775 3 89 rp C 0.91 0 scol L ; : N 2480 766 9 107 rp C 1 0 scol L ; : N 2522 766 6 107 rp C 1 0 scol L ; : N 2480 766 48 6 rp C 1 0 scol L ; : N 2480 867 48 6 rp C 1 0 scol L ; : N 2504 784 M 2504 787 I 2501 787 I 2501 790 I 2498 790 I 2498 793 I 2495 793 I 2495 796 I 2516 796 I 2516 793 I 2513 793 I 2513 790 I 2510 790 I 2510 787 I 2507 787 I 2507 784 I C eoclip : N 2495 784 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2480 870 51 6 rc N 2480 873 M 2531 873 I : 2.969 2.969 +S K ; ; : N 2528 766 3 107 rp C 1 0 scol L ; : N 2531 766 632 51 rp C 1 0 scol L ; 0 0 scol 2534 804 M (c:)[22 0]xS F2S26 Ji 2569 805 M (CoordValue)[28 24 24 15 24 26 22 11 24 0]xS 0.754 0 scol : 2783 814 383 6 rc N 2786 817 M 3166 817 I : 2.969 2.969 +S K ; ; : 3160 766 6 54 rc N 3163 766 M 3163 820 I : 2.969 2.969 +S K ; ; 1 0 scol : 2531 814 262 6 rc N 2531 817 M 2789 817 I : 2.969 2.969 +S K ; ; : N 53 820 173 53 rp C L ; : N 53 873 173 3 rp C L ; 0.754 0 scol : 223 820 6 56 rc N 226 820 M 226 876 I : 2.969 2.969 +S K ; ; : N 279 820 377 53 rp C 1 0 scol L ; : N 279 873 377 3 rp C 1 0 scol L ; : 653 820 6 56 rc N 656 820 M 656 876 I : 2.969 2.969 +S K ; ; : N 710 820 113 53 rp C 1 0 scol L ; : N 710 873 113 3 rp C 1 0 scol L ; : 820 820 6 56 rc N 823 820 M 823 876 I : 2.969 2.969 +S K ; ; : N 876 820 122 53 rp C 1 0 scol L ; : N 876 873 122 3 rp C 1 0 scol L ; : 995 820 6 56 rc N 998 820 M 998 876 I : 2.969 2.969 +S K ; ; : N 1051 820 295 53 rp C 1 0 scol L ; : N 1051 873 295 3 rp C 1 0 scol L ; : 1343 820 6 56 rc N 1346 820 M 1346 876 I : 2.969 2.969 +S K ; ; : N 1399 820 181 53 rp C 1 0 scol L ; : N 1399 873 181 3 rp C 1 0 scol L ; : 1577 820 6 56 rc N 1580 820 M 1580 876 I : 2.969 2.969 +S K ; ; : N 1634 820 211 53 rp C 1 0 scol L ; : N 1634 873 211 3 rp C 1 0 scol L ; : 1842 820 6 56 rc N 1845 820 M 1845 876 I : 2.969 2.969 +S K ; ; : N 1898 820 208 53 rp C 1 0 scol L ; : 1898 870 211 6 rc N 1898 873 M 2109 873 I : 2.969 2.969 +S K ; ; : 2103 820 6 56 rc N 2106 820 M 2106 876 I : 2.969 2.969 +S K ; ; : N 2159 820 318 53 rp C 1 0 scol L ; : 2159 870 321 6 rc N 2159 873 M 2480 873 I : 2.969 2.969 +S K ; ; : 2474 820 6 56 rc N 2477 820 M 2477 876 I : 2.969 2.969 +S K ; ; : N 2531 820 258 53 rp C 1 0 scol L ; : 2531 870 261 6 rc N 2531 873 M 2792 873 I : 2.969 2.969 +S K ; ; : 2786 820 6 56 rc N 2789 820 M 2789 876 I : 2.969 2.969 +S K ; ; : N 2792 820 48 53 rp C 1 0 scol L ; : 2795 823 45 38 rc : 16 13 8 16 48 38 2795 823 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 2792 870 51 6 rc N 2792 873 M 2843 873 I : 2.969 2.969 +S K ; ; : N 2840 820 3 53 rp C 1 0 scol L ; : N 2843 820 199 53 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2846 858 M (c:)[22 0]xS F2S26 Ji 2881 859 M (Query)[30 24 22 15 0]xS 0.754 0 scol : 2843 870 202 6 rc N 2843 873 M 3045 873 I : 2.969 2.969 +S K ; ; : 3039 820 6 56 rc N 3042 820 M 3042 876 I : 2.969 2.969 +S K ; ; : N 3045 820 118 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 3048 858 M (@)S 3088 858 M (g)S 3110 858 M (.)S 3121 858 M (.)S 3132 858 M (.)S 0.754 0 scol : 3045 870 121 6 rc N 3045 873 M 3166 873 I : 2.969 2.969 +S K ; ; : 3160 820 6 56 rc N 3163 820 M 3163 876 I : 2.969 2.969 +S K ; ; : N 53 876 173 51 rp C 1 0 scol L ; : N 53 927 173 3 rp C 1 0 scol L ; : 223 876 6 54 rc N 226 876 M 226 930 I : 2.969 2.969 +S K ; ; : N 279 876 377 51 rp C 1 0 scol L ; : N 279 927 377 3 rp C 1 0 scol L ; : 653 876 6 54 rc N 656 876 M 656 930 I : 2.969 2.969 +S K ; ; : N 710 876 113 51 rp C 1 0 scol L ; : N 710 927 113 3 rp C 1 0 scol L ; : 820 876 6 54 rc N 823 876 M 823 930 I : 2.969 2.969 +S K ; ; : N 876 876 122 51 rp C 1 0 scol L ; : N 876 927 122 3 rp C 1 0 scol L ; : 995 876 6 54 rc N 998 876 M 998 930 I : 2.969 2.969 +S K ; ; : N 1051 876 295 51 rp C 1 0 scol L ; : N 1051 927 295 3 rp C 1 0 scol L ; : 1343 876 6 54 rc N 1346 876 M 1346 930 I : 2.969 2.969 +S K ; ; : N 1399 876 181 51 rp C 1 0 scol L ; : N 1399 927 181 3 rp C 1 0 scol L ; : 1577 876 6 54 rc N 1580 876 M 1580 930 I : 2.969 2.969 +S K ; ; : N 1634 876 211 51 rp C 1 0 scol L ; : N 1634 927 211 3 rp C 1 0 scol L ; : 1842 876 6 54 rc N 1845 876 M 1845 930 I : 2.969 2.969 +S K ; ; : N 1859 885 27 146 rp C 0.91 0 scol L ; 1 0 scol N 1859 1031 M 1859 885 I : 2.969 2.969 +S K ; N 1859 885 M 1886 885 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 1028 M 1883 1028 I : 2.969 2.969 +S K ; N 1883 1028 M 1883 885 I : 2.969 2.969 +S K ; : N 1856 882 33 3 rp C 0.91 0 scol L ; : N 1856 1031 33 3 rp C 0.91 0 scol L ; : N 1856 885 3 146 rp C 0.91 0 scol L ; : N 1886 885 3 146 rp C 0.91 0 scol L ; : N 1848 876 8 164 rp C 1 0 scol L ; : N 1889 876 6 164 rp C 1 0 scol L ; : N 1848 876 47 6 rp C 1 0 scol L ; : N 1848 1034 47 6 rp C 1 0 scol L ; : N 1871 894 M 1871 897 I 1868 897 I 1868 900 I 1865 900 I 1865 903 I 1862 903 I 1862 906 I 1883 906 I 1883 903 I 1880 903 I 1880 900 I 1877 900 I 1877 897 I 1874 897 I 1874 894 I C eoclip : N 1862 894 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 1037 50 6 rc N 1848 1040 M 1898 1040 I : 2.969 2.969 +S K ; ; : N 1895 876 3 164 rp C 1 0 scol L ; : N 1898 876 1265 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1901 915 M (measurement)[35 22 22 22 24 15 22 35 22 24 0]xS 0.754 0 scol : 2100 924 1066 6 rc N 2103 927 M 3166 927 I : 2.969 2.969 +S K ; ; : 3160 876 6 54 rc N 3163 876 M 3163 930 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 924 212 6 rc N 1898 927 M 2106 927 I : 2.969 2.969 +S K ; ; : N 53 930 173 53 rp C L ; : N 53 983 173 3 rp C L ; 0.754 0 scol : 223 930 6 56 rc N 226 930 M 226 986 I : 2.969 2.969 +S K ; ; : N 279 930 377 53 rp C 1 0 scol L ; : N 279 983 377 3 rp C 1 0 scol L ; : 653 930 6 56 rc N 656 930 M 656 986 I : 2.969 2.969 +S K ; ; : N 710 930 113 53 rp C 1 0 scol L ; : N 710 983 113 3 rp C 1 0 scol L ; : 820 930 6 56 rc N 823 930 M 823 986 I : 2.969 2.969 +S K ; ; : N 876 930 122 53 rp C 1 0 scol L ; : N 876 983 122 3 rp C 1 0 scol L ; : 995 930 6 56 rc N 998 930 M 998 986 I : 2.969 2.969 +S K ; ; : N 1051 930 295 53 rp C 1 0 scol L ; : N 1051 983 295 3 rp C 1 0 scol L ; : 1343 930 6 56 rc N 1346 930 M 1346 986 I : 2.969 2.969 +S K ; ; : N 1399 930 181 53 rp C 1 0 scol L ; : N 1399 983 181 3 rp C 1 0 scol L ; : 1577 930 6 56 rc N 1580 930 M 1580 986 I : 2.969 2.969 +S K ; ; : N 1634 930 211 53 rp C 1 0 scol L ; : N 1634 983 211 3 rp C 1 0 scol L ; : 1842 930 6 56 rc N 1845 930 M 1845 986 I : 2.969 2.969 +S K ; ; : N 1898 930 208 53 rp C 1 0 scol L ; : N 1898 983 208 3 rp C 1 0 scol L ; : 2103 930 6 56 rc N 2106 930 M 2106 986 I : 2.969 2.969 +S K ; ; : N 2109 930 47 53 rp C 1 0 scol L ; : 2112 933 44 38 rc : 16 13 8 16 47 38 2112 933 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2109 980 50 6 rc N 2109 983 M 2159 983 I : 2.969 2.969 +S K ; ; : N 2156 930 3 53 rp C 1 0 scol L ; : N 2159 930 318 53 rp C 1 0 scol L ; 0 0 scol 2162 969 M (name)[24 22 35 0]xS 0.754 0 scol : 2159 980 321 6 rc N 2159 983 M 2480 983 I : 2.969 2.969 +S K ; ; : 2474 930 6 56 rc N 2477 930 M 2477 986 I : 2.969 2.969 +S K ; ; : N 2480 930 683 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 968 M (mType)[33 23 19 22 0]xS 0.754 0 scol : 2480 980 686 6 rc N 2480 983 M 3166 983 I : 2.969 2.969 +S K ; ; : 3160 930 6 56 rc N 3163 930 M 3163 986 I : 2.969 2.969 +S K ; ; : N 53 986 173 54 rp C 1 0 scol L ; : N 53 1040 173 3 rp C 1 0 scol L ; : 223 986 6 57 rc N 226 986 M 226 1043 I : 2.969 2.969 +S K ; ; : N 279 986 377 54 rp C 1 0 scol L ; : N 279 1040 377 3 rp C 1 0 scol L ; : 653 986 6 57 rc N 656 986 M 656 1043 I : 2.969 2.969 +S K ; ; : N 710 986 113 54 rp C 1 0 scol L ; : N 710 1040 113 3 rp C 1 0 scol L ; : 820 986 6 57 rc N 823 986 M 823 1043 I : 2.969 2.969 +S K ; ; : N 876 986 122 54 rp C 1 0 scol L ; : N 876 1040 122 3 rp C 1 0 scol L ; : 995 986 6 57 rc N 998 986 M 998 1043 I : 2.969 2.969 +S K ; ; : N 1051 986 295 54 rp C 1 0 scol L ; : N 1051 1040 295 3 rp C 1 0 scol L ; : 1343 986 6 57 rc N 1346 986 M 1346 1043 I : 2.969 2.969 +S K ; ; : N 1399 986 181 54 rp C 1 0 scol L ; : N 1399 1040 181 3 rp C 1 0 scol L ; : 1577 986 6 57 rc N 1580 986 M 1580 1043 I : 2.969 2.969 +S K ; ; : N 1634 986 211 54 rp C 1 0 scol L ; : N 1634 1040 211 3 rp C 1 0 scol L ; : 1842 986 6 57 rc N 1845 986 M 1845 1043 I : 2.969 2.969 +S K ; ; : N 1898 986 208 54 rp C 1 0 scol L ; : 1898 1037 211 6 rc N 1898 1040 M 2109 1040 I : 2.969 2.969 +S K ; ; : 2103 986 6 57 rc N 2106 986 M 2106 1043 I : 2.969 2.969 +S K ; ; : N 2109 986 47 54 rp C 1 0 scol L ; : 2112 989 44 39 rc : 16 13 8 16 47 39 2112 989 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 2109 1037 50 6 rc N 2109 1040 M 2159 1040 I : 2.969 2.969 +S K ; ; : N 2156 986 3 54 rp C 1 0 scol L ; : N 2159 986 318 54 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 2162 1025 M (Text)[24 22 20 0]xS 0.754 0 scol : 2159 1037 321 6 rc N 2159 1040 M 2480 1040 I : 2.969 2.969 +S K ; ; : 2474 986 6 57 rc N 2477 986 M 2477 1043 I : 2.969 2.969 +S K ; ; : N 2480 986 683 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 1024 M (@mType)[40 33 23 19 22 0]xS 0.754 0 scol : 2480 1037 686 6 rc N 2480 1040 M 3166 1040 I : 2.969 2.969 +S K ; ; : 3160 986 6 57 rc N 3163 986 M 3163 1043 I : 2.969 2.969 +S K ; ; : N 53 1043 173 50 rp C 1 0 scol L ; : N 53 1093 173 3 rp C 1 0 scol L ; : 223 1043 6 53 rc N 226 1043 M 226 1096 I : 2.969 2.969 +S K ; ; : N 279 1043 377 50 rp C 1 0 scol L ; : N 279 1093 377 3 rp C 1 0 scol L ; : 653 1043 6 53 rc N 656 1043 M 656 1096 I : 2.969 2.969 +S K ; ; : N 710 1043 113 50 rp C 1 0 scol L ; : N 710 1093 113 3 rp C 1 0 scol L ; : 820 1043 6 53 rc N 823 1043 M 823 1096 I : 2.969 2.969 +S K ; ; : N 876 1043 122 50 rp C 1 0 scol L ; : N 876 1093 122 3 rp C 1 0 scol L ; : 995 1043 6 53 rc N 998 1043 M 998 1096 I : 2.969 2.969 +S K ; ; : N 1051 1043 295 50 rp C 1 0 scol L ; : N 1051 1093 295 3 rp C 1 0 scol L ; : 1343 1043 6 53 rc N 1346 1043 M 1346 1096 I : 2.969 2.969 +S K ; ; : N 1399 1043 181 50 rp C 1 0 scol L ; : N 1399 1093 181 3 rp C 1 0 scol L ; : 1577 1043 6 53 rc N 1580 1043 M 1580 1096 I : 2.969 2.969 +S K ; ; : N 1634 1043 211 50 rp C 1 0 scol L ; : N 1634 1093 211 3 rp C 1 0 scol L ; : 1842 1043 6 53 rc N 1845 1043 M 1845 1096 I : 2.969 2.969 +S K ; ; : N 1859 1051 27 535 rp C 0.91 0 scol L ; 1 0 scol N 1859 1586 M 1859 1052 I : 2.969 2.969 +S K ; N 1859 1052 M 1886 1052 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 1583 M 1883 1583 I : 2.969 2.969 +S K ; N 1883 1583 M 1883 1052 I : 2.969 2.969 +S K ; : N 1856 1049 33 2 rp C 0.91 0 scol L ; : N 1856 1586 33 3 rp C 0.91 0 scol L ; : N 1856 1051 3 535 rp C 0.91 0 scol L ; : N 1886 1051 3 535 rp C 0.91 0 scol L ; : N 1848 1043 8 552 rp C 1 0 scol L ; : N 1889 1043 6 552 rp C 1 0 scol L ; : N 1848 1043 47 6 rp C 1 0 scol L ; : N 1848 1589 47 6 rp C 1 0 scol L ; : N 1871 1060 M 1871 1063 I 1868 1063 I 1868 1066 I 1865 1066 I 1865 1069 I 1862 1069 I 1862 1072 I 1883 1072 I 1883 1069 I 1880 1069 I 1880 1066 I 1877 1066 I 1877 1063 I 1874 1063 I 1874 1060 I C eoclip : N 1862 1060 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 1592 50 6 rc N 1848 1595 M 1898 1595 I : 2.969 2.969 +S K ; ; : N 1895 1043 3 552 rp C 1 0 scol L ; : N 1898 1043 1265 50 rp C 1 0 scol L ; 0 0 scol : 1901 1046 233 44 rc F2S26 Ji 1901 1082 M (orProperties)[24 15 26 15 24 24 22 15 13 11 22 0]xS ; 0.754 0 scol : 2100 1090 1066 6 rc N 2103 1093 M 3166 1093 I : 2.969 2.969 +S K ; ; : 3160 1043 6 53 rc N 3163 1043 M 3163 1096 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 1090 212 6 rc N 1898 1093 M 2106 1093 I : 2.969 2.969 +S K ; ; : N 53 1096 173 51 rp C L ; : N 53 1147 173 3 rp C L ; 0.754 0 scol : 223 1096 6 54 rc N 226 1096 M 226 1150 I : 2.969 2.969 +S K ; ; : N 279 1096 377 51 rp C 1 0 scol L ; : N 279 1147 377 3 rp C 1 0 scol L ; : 653 1096 6 54 rc N 656 1096 M 656 1150 I : 2.969 2.969 +S K ; ; : N 710 1096 113 51 rp C 1 0 scol L ; : N 710 1147 113 3 rp C 1 0 scol L ; : 820 1096 6 54 rc N 823 1096 M 823 1150 I : 2.969 2.969 +S K ; ; : N 876 1096 122 51 rp C 1 0 scol L ; : N 876 1147 122 3 rp C 1 0 scol L ; : 995 1096 6 54 rc N 998 1096 M 998 1150 I : 2.969 2.969 +S K ; ; : N 1051 1096 295 51 rp C 1 0 scol L ; : N 1051 1147 295 3 rp C 1 0 scol L ; : 1343 1096 6 54 rc N 1346 1096 M 1346 1150 I : 2.969 2.969 +S K ; ; : N 1399 1096 181 51 rp C 1 0 scol L ; : N 1399 1147 181 3 rp C 1 0 scol L ; : 1577 1096 6 54 rc N 1580 1096 M 1580 1150 I : 2.969 2.969 +S K ; ; : N 1634 1096 211 51 rp C 1 0 scol L ; : N 1634 1147 211 3 rp C 1 0 scol L ; : 1842 1096 6 54 rc N 1845 1096 M 1845 1150 I : 2.969 2.969 +S K ; ; : N 1898 1096 208 51 rp C 1 0 scol L ; : N 1898 1147 208 3 rp C 1 0 scol L ; : 2103 1096 6 54 rc N 2106 1096 M 2106 1150 I : 2.969 2.969 +S K ; ; : N 2121 1105 27 258 rp C 0.91 0 scol L ; 1 0 scol N 2121 1363 M 2121 1105 I : 2.969 2.969 +S K ; N 2121 1105 M 2148 1105 I : 2.969 2.969 +S K ; 0.496 0 scol N 2121 1360 M 2145 1360 I : 2.969 2.969 +S K ; N 2145 1360 M 2145 1105 I : 2.969 2.969 +S K ; : N 2118 1102 32 3 rp C 0.91 0 scol L ; : N 2118 1363 32 3 rp C 0.91 0 scol L ; : N 2118 1105 3 258 rp C 0.91 0 scol L ; : N 2148 1105 2 258 rp C 0.91 0 scol L ; : N 2109 1096 9 276 rp C 1 0 scol L ; : N 2150 1096 6 276 rp C 1 0 scol L ; : N 2109 1096 47 6 rp C 1 0 scol L ; : N 2109 1366 47 6 rp C 1 0 scol L ; : N 2133 1114 M 2133 1117 I 2130 1117 I 2130 1120 I 2127 1120 I 2127 1123 I 2124 1123 I 2124 1126 I 2145 1126 I 2145 1123 I 2142 1123 I 2142 1120 I 2139 1120 I 2139 1117 I 2136 1117 I 2136 1114 I C eoclip : N 2124 1114 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2109 1369 50 6 rc N 2109 1372 M 2159 1372 I : 2.969 2.969 +S K ; ; : N 2156 1096 3 276 rp C 1 0 scol L ; : N 2159 1096 1004 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2162 1135 M (measurement)[35 22 22 22 24 15 22 35 22 24 0]xS 0.754 0 scol : 2471 1144 695 6 rc N 2474 1147 M 3166 1147 I : 2.969 2.969 +S K ; ; : 3160 1096 6 54 rc N 3163 1096 M 3163 1150 I : 2.969 2.969 +S K ; ; 1 0 scol : 2159 1144 322 6 rc N 2159 1147 M 2477 1147 I : 2.969 2.969 +S K ; ; : N 53 1150 173 53 rp C L ; : N 53 1203 173 3 rp C L ; 0.754 0 scol : 223 1150 6 56 rc N 226 1150 M 226 1206 I : 2.969 2.969 +S K ; ; : N 279 1150 377 53 rp C 1 0 scol L ; : N 279 1203 377 3 rp C 1 0 scol L ; : 653 1150 6 56 rc N 656 1150 M 656 1206 I : 2.969 2.969 +S K ; ; : N 710 1150 113 53 rp C 1 0 scol L ; : N 710 1203 113 3 rp C 1 0 scol L ; : 820 1150 6 56 rc N 823 1150 M 823 1206 I : 2.969 2.969 +S K ; ; : N 876 1150 122 53 rp C 1 0 scol L ; : N 876 1203 122 3 rp C 1 0 scol L ; : 995 1150 6 56 rc N 998 1150 M 998 1206 I : 2.969 2.969 +S K ; ; : N 1051 1150 295 53 rp C 1 0 scol L ; : N 1051 1203 295 3 rp C 1 0 scol L ; : 1343 1150 6 56 rc N 1346 1150 M 1346 1206 I : 2.969 2.969 +S K ; ; : N 1399 1150 181 53 rp C 1 0 scol L ; : N 1399 1203 181 3 rp C 1 0 scol L ; : 1577 1150 6 56 rc N 1580 1150 M 1580 1206 I : 2.969 2.969 +S K ; ; : N 1634 1150 211 53 rp C 1 0 scol L ; : N 1634 1203 211 3 rp C 1 0 scol L ; : 1842 1150 6 56 rc N 1845 1150 M 1845 1206 I : 2.969 2.969 +S K ; ; : N 1898 1150 208 53 rp C 1 0 scol L ; : N 1898 1203 208 3 rp C 1 0 scol L ; : 2103 1150 6 56 rc N 2106 1150 M 2106 1206 I : 2.969 2.969 +S K ; ; : N 2159 1150 318 53 rp C 1 0 scol L ; : N 2159 1203 318 3 rp C 1 0 scol L ; : 2474 1150 6 56 rc N 2477 1150 M 2477 1206 I : 2.969 2.969 +S K ; ; : N 2480 1150 48 53 rp C 1 0 scol L ; : 2483 1152 45 39 rc : 16 13 8 16 48 39 2483 1152 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2480 1200 51 6 rc N 2480 1203 M 2531 1203 I : 2.969 2.969 +S K ; ; : N 2528 1150 3 53 rp C 1 0 scol L ; : N 2531 1150 258 53 rp C 1 0 scol L ; 0 0 scol 2534 1189 M (project)[24 15 24 11 22 22 0]xS 0.754 0 scol : 2531 1200 261 6 rc N 2531 1203 M 2792 1203 I : 2.969 2.969 +S K ; ; : 2786 1150 6 56 rc N 2789 1150 M 2789 1206 I : 2.969 2.969 +S K ; ; : N 2792 1150 371 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1188 M (ROSAT)[28 30 26 26 0]xS 0.754 0 scol : 2792 1200 374 6 rc N 2792 1203 M 3166 1203 I : 2.969 2.969 +S K ; ; : 3160 1150 6 56 rc N 3163 1150 M 3163 1206 I : 2.969 2.969 +S K ; ; : N 53 1206 173 53 rp C 1 0 scol L ; : N 53 1259 173 3 rp C 1 0 scol L ; : 223 1206 6 56 rc N 226 1206 M 226 1262 I : 2.969 2.969 +S K ; ; : N 279 1206 377 53 rp C 1 0 scol L ; : N 279 1259 377 3 rp C 1 0 scol L ; : 653 1206 6 56 rc N 656 1206 M 656 1262 I : 2.969 2.969 +S K ; ; : N 710 1206 113 53 rp C 1 0 scol L ; : N 710 1259 113 3 rp C 1 0 scol L ; : 820 1206 6 56 rc N 823 1206 M 823 1262 I : 2.969 2.969 +S K ; ; : N 876 1206 122 53 rp C 1 0 scol L ; : N 876 1259 122 3 rp C 1 0 scol L ; : 995 1206 6 56 rc N 998 1206 M 998 1262 I : 2.969 2.969 +S K ; ; : N 1051 1206 295 53 rp C 1 0 scol L ; : N 1051 1259 295 3 rp C 1 0 scol L ; : 1343 1206 6 56 rc N 1346 1206 M 1346 1262 I : 2.969 2.969 +S K ; ; : N 1399 1206 181 53 rp C 1 0 scol L ; : N 1399 1259 181 3 rp C 1 0 scol L ; : 1577 1206 6 56 rc N 1580 1206 M 1580 1262 I : 2.969 2.969 +S K ; ; : N 1634 1206 211 53 rp C 1 0 scol L ; : N 1634 1259 211 3 rp C 1 0 scol L ; : 1842 1206 6 56 rc N 1845 1206 M 1845 1262 I : 2.969 2.969 +S K ; ; : N 1898 1206 208 53 rp C 1 0 scol L ; : N 1898 1259 208 3 rp C 1 0 scol L ; : 2103 1206 6 56 rc N 2106 1206 M 2106 1262 I : 2.969 2.969 +S K ; ; : N 2159 1206 318 53 rp C 1 0 scol L ; : N 2159 1259 318 3 rp C 1 0 scol L ; : 2474 1206 6 56 rc N 2477 1206 M 2477 1262 I : 2.969 2.969 +S K ; ; : N 2480 1206 48 53 rp C 1 0 scol L ; : 2483 1209 45 39 rc : 16 13 8 16 48 39 2483 1209 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2480 1256 51 6 rc N 2480 1259 M 2531 1259 I : 2.969 2.969 +S K ; ; : N 2528 1206 3 53 rp C 1 0 scol L ; : N 2531 1206 258 53 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2534 1245 M (name)[24 22 35 0]xS 0.754 0 scol : 2531 1256 261 6 rc N 2531 1259 M 2792 1259 I : 2.969 2.969 +S K ; ; : 2786 1206 6 56 rc N 2789 1206 M 2789 1262 I : 2.969 2.969 +S K ; ; : N 2792 1206 371 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1244 M (Xraybrightness)[25 13 22 19 22 13 9 22 22 11 22 22 19 0]xS 0.754 0 scol : 2792 1256 374 6 rc N 2792 1259 M 3166 1259 I : 2.969 2.969 +S K ; ; : 3160 1206 6 56 rc N 3163 1206 M 3163 1262 I : 2.969 2.969 +S K ; ; : N 53 1262 173 54 rp C 1 0 scol L ; : N 53 1316 173 3 rp C 1 0 scol L ; : 223 1262 6 57 rc N 226 1262 M 226 1319 I : 2.969 2.969 +S K ; ; : N 279 1262 377 54 rp C 1 0 scol L ; : N 279 1316 377 3 rp C 1 0 scol L ; : 653 1262 6 57 rc N 656 1262 M 656 1319 I : 2.969 2.969 +S K ; ; : N 710 1262 113 54 rp C 1 0 scol L ; : N 710 1316 113 3 rp C 1 0 scol L ; : 820 1262 6 57 rc N 823 1262 M 823 1319 I : 2.969 2.969 +S K ; ; : N 876 1262 122 54 rp C 1 0 scol L ; : N 876 1316 122 3 rp C 1 0 scol L ; : 995 1262 6 57 rc N 998 1262 M 998 1319 I : 2.969 2.969 +S K ; ; : N 1051 1262 295 54 rp C 1 0 scol L ; : N 1051 1316 295 3 rp C 1 0 scol L ; : 1343 1262 6 57 rc N 1346 1262 M 1346 1319 I : 2.969 2.969 +S K ; ; : N 1399 1262 181 54 rp C 1 0 scol L ; : N 1399 1316 181 3 rp C 1 0 scol L ; : 1577 1262 6 57 rc N 1580 1262 M 1580 1319 I : 2.969 2.969 +S K ; ; : N 1634 1262 211 54 rp C 1 0 scol L ; : N 1634 1316 211 3 rp C 1 0 scol L ; : 1842 1262 6 57 rc N 1845 1262 M 1845 1319 I : 2.969 2.969 +S K ; ; : N 1898 1262 208 54 rp C 1 0 scol L ; : N 1898 1316 208 3 rp C 1 0 scol L ; : 2103 1262 6 57 rc N 2106 1262 M 2106 1319 I : 2.969 2.969 +S K ; ; : N 2159 1262 318 54 rp C 1 0 scol L ; : N 2159 1316 318 3 rp C 1 0 scol L ; : 2474 1262 6 57 rc N 2477 1262 M 2477 1319 I : 2.969 2.969 +S K ; ; : N 2480 1262 48 54 rp C 1 0 scol L ; : 2483 1265 45 39 rc : 16 13 8 16 48 39 2483 1265 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2480 1313 51 6 rc N 2480 1316 M 2531 1316 I : 2.969 2.969 +S K ; ; : N 2528 1262 3 54 rp C 1 0 scol L ; : N 2531 1262 258 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2534 1301 M (units)[24 24 11 13 0]xS 0.754 0 scol : 2531 1313 261 6 rc N 2531 1316 M 2792 1316 I : 2.969 2.969 +S K ; ; : 2786 1262 6 57 rc N 2789 1262 M 2789 1319 I : 2.969 2.969 +S K ; ; : N 2792 1262 371 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1300 M (@xrayUnits)[40 18 13 22 19 28 22 9 11 0]xS 0.754 0 scol : 2792 1313 374 6 rc N 2792 1316 M 3166 1316 I : 2.969 2.969 +S K ; ; : 3160 1262 6 57 rc N 3163 1262 M 3163 1319 I : 2.969 2.969 +S K ; ; : N 53 1319 173 53 rp C 1 0 scol L ; : N 53 1372 173 3 rp C 1 0 scol L ; : 223 1319 6 56 rc N 226 1319 M 226 1375 I : 2.969 2.969 +S K ; ; : N 279 1319 377 53 rp C 1 0 scol L ; : N 279 1372 377 3 rp C 1 0 scol L ; : 653 1319 6 56 rc N 656 1319 M 656 1375 I : 2.969 2.969 +S K ; ; : N 710 1319 113 53 rp C 1 0 scol L ; : N 710 1372 113 3 rp C 1 0 scol L ; : 820 1319 6 56 rc N 823 1319 M 823 1375 I : 2.969 2.969 +S K ; ; : N 876 1319 122 53 rp C 1 0 scol L ; : N 876 1372 122 3 rp C 1 0 scol L ; : 995 1319 6 56 rc N 998 1319 M 998 1375 I : 2.969 2.969 +S K ; ; : N 1051 1319 295 53 rp C 1 0 scol L ; : N 1051 1372 295 3 rp C 1 0 scol L ; : 1343 1319 6 56 rc N 1346 1319 M 1346 1375 I : 2.969 2.969 +S K ; ; : N 1399 1319 181 53 rp C 1 0 scol L ; : N 1399 1372 181 3 rp C 1 0 scol L ; : 1577 1319 6 56 rc N 1580 1319 M 1580 1375 I : 2.969 2.969 +S K ; ; : N 1634 1319 211 53 rp C 1 0 scol L ; : N 1634 1372 211 3 rp C 1 0 scol L ; : 1842 1319 6 56 rc N 1845 1319 M 1845 1375 I : 2.969 2.969 +S K ; ; : N 1898 1319 208 53 rp C 1 0 scol L ; : N 1898 1372 208 3 rp C 1 0 scol L ; : 2103 1319 6 56 rc N 2106 1319 M 2106 1375 I : 2.969 2.969 +S K ; ; : N 2159 1319 318 53 rp C 1 0 scol L ; : 2159 1369 321 6 rc N 2159 1372 M 2480 1372 I : 2.969 2.969 +S K ; ; : 2474 1319 6 56 rc N 2477 1319 M 2477 1375 I : 2.969 2.969 +S K ; ; : N 2480 1319 48 53 rp C 1 0 scol L ; : 2483 1322 45 38 rc : 16 13 8 16 48 38 2483 1322 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 2480 1369 51 6 rc N 2480 1372 M 2531 1372 I : 2.969 2.969 +S K ; ; : N 2528 1319 3 53 rp C 1 0 scol L ; : N 2531 1319 258 53 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 2534 1358 M (Text)[24 22 20 0]xS 0.754 0 scol : 2531 1369 261 6 rc N 2531 1372 M 2792 1372 I : 2.969 2.969 +S K ; ; : 2786 1319 6 56 rc N 2789 1319 M 2789 1375 I : 2.969 2.969 +S K ; ; : N 2792 1319 371 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1357 M (@gXray)[40 22 25 13 22 0]xS 0.754 0 scol : 2792 1369 374 6 rc N 2792 1372 M 3166 1372 I : 2.969 2.969 +S K ; ; : 3160 1319 6 56 rc N 3163 1319 M 3163 1375 I : 2.969 2.969 +S K ; ; : N 53 1375 173 51 rp C 1 0 scol L ; : N 53 1426 173 3 rp C 1 0 scol L ; : 223 1375 6 54 rc N 226 1375 M 226 1429 I : 2.969 2.969 +S K ; ; : N 279 1375 377 51 rp C 1 0 scol L ; : N 279 1426 377 3 rp C 1 0 scol L ; : 653 1375 6 54 rc N 656 1375 M 656 1429 I : 2.969 2.969 +S K ; ; : N 710 1375 113 51 rp C 1 0 scol L ; : N 710 1426 113 3 rp C 1 0 scol L ; : 820 1375 6 54 rc N 823 1375 M 823 1429 I : 2.969 2.969 +S K ; ; : N 876 1375 122 51 rp C 1 0 scol L ; : N 876 1426 122 3 rp C 1 0 scol L ; : 995 1375 6 54 rc N 998 1375 M 998 1429 I : 2.969 2.969 +S K ; ; : N 1051 1375 295 51 rp C 1 0 scol L ; : N 1051 1426 295 3 rp C 1 0 scol L ; : 1343 1375 6 54 rc N 1346 1375 M 1346 1429 I : 2.969 2.969 +S K ; ; : N 1399 1375 181 51 rp C 1 0 scol L ; : N 1399 1426 181 3 rp C 1 0 scol L ; : 1577 1375 6 54 rc N 1580 1375 M 1580 1429 I : 2.969 2.969 +S K ; ; : N 1634 1375 211 51 rp C 1 0 scol L ; : N 1634 1426 211 3 rp C 1 0 scol L ; : 1842 1375 6 54 rc N 1845 1375 M 1845 1429 I : 2.969 2.969 +S K ; ; : N 1898 1375 208 51 rp C 1 0 scol L ; : N 1898 1426 208 3 rp C 1 0 scol L ; : 2103 1375 6 54 rc N 2106 1375 M 2106 1429 I : 2.969 2.969 +S K ; ; : N 2121 1384 27 202 rp C 0.91 0 scol L ; 1 0 scol N 2121 1586 M 2121 1384 I : 2.969 2.969 +S K ; N 2121 1384 M 2148 1384 I : 2.969 2.969 +S K ; 0.496 0 scol N 2121 1583 M 2145 1583 I : 2.969 2.969 +S K ; N 2145 1583 M 2145 1384 I : 2.969 2.969 +S K ; : N 2118 1381 32 3 rp C 0.91 0 scol L ; : N 2118 1586 32 3 rp C 0.91 0 scol L ; : N 2118 1384 3 202 rp C 0.91 0 scol L ; : N 2148 1384 2 202 rp C 0.91 0 scol L ; : N 2109 1375 9 220 rp C 1 0 scol L ; : N 2150 1375 6 220 rp C 1 0 scol L ; : N 2109 1375 47 6 rp C 1 0 scol L ; : N 2109 1589 47 6 rp C 1 0 scol L ; : N 2133 1393 M 2133 1396 I 2130 1396 I 2130 1399 I 2127 1399 I 2127 1402 I 2124 1402 I 2124 1405 I 2145 1405 I 2145 1402 I 2142 1402 I 2142 1399 I 2139 1399 I 2139 1396 I 2136 1396 I 2136 1393 I C eoclip : N 2124 1393 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2109 1592 50 6 rc N 2109 1595 M 2159 1595 I : 2.969 2.969 +S K ; ; : N 2156 1375 3 220 rp C 1 0 scol L ; : N 2159 1375 1004 51 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2162 1413 M (siap:)[22 11 22 24 0]xS F2S26 Ji 2254 1414 M (image)[11 35 22 24 0]xS 0.754 0 scol : 2471 1423 695 6 rc N 2474 1426 M 3166 1426 I : 2.969 2.969 +S K ; ; : 3160 1375 6 54 rc N 3163 1375 M 3163 1429 I : 2.969 2.969 +S K ; ; 1 0 scol : 2159 1423 322 6 rc N 2159 1426 M 2477 1426 I : 2.969 2.969 +S K ; ; : N 53 1429 173 53 rp C L ; : N 53 1482 173 3 rp C L ; 0.754 0 scol : 223 1429 6 56 rc N 226 1429 M 226 1485 I : 2.969 2.969 +S K ; ; : N 279 1429 377 53 rp C 1 0 scol L ; : N 279 1482 377 3 rp C 1 0 scol L ; : 653 1429 6 56 rc N 656 1429 M 656 1485 I : 2.969 2.969 +S K ; ; : N 710 1429 113 53 rp C 1 0 scol L ; : N 710 1482 113 3 rp C 1 0 scol L ; : 820 1429 6 56 rc N 823 1429 M 823 1485 I : 2.969 2.969 +S K ; ; : N 876 1429 122 53 rp C 1 0 scol L ; : N 876 1482 122 3 rp C 1 0 scol L ; : 995 1429 6 56 rc N 998 1429 M 998 1485 I : 2.969 2.969 +S K ; ; : N 1051 1429 295 53 rp C 1 0 scol L ; : N 1051 1482 295 3 rp C 1 0 scol L ; : 1343 1429 6 56 rc N 1346 1429 M 1346 1485 I : 2.969 2.969 +S K ; ; : N 1399 1429 181 53 rp C 1 0 scol L ; : N 1399 1482 181 3 rp C 1 0 scol L ; : 1577 1429 6 56 rc N 1580 1429 M 1580 1485 I : 2.969 2.969 +S K ; ; : N 1634 1429 211 53 rp C 1 0 scol L ; : N 1634 1482 211 3 rp C 1 0 scol L ; : 1842 1429 6 56 rc N 1845 1429 M 1845 1485 I : 2.969 2.969 +S K ; ; : N 1898 1429 208 53 rp C 1 0 scol L ; : N 1898 1482 208 3 rp C 1 0 scol L ; : 2103 1429 6 56 rc N 2106 1429 M 2106 1485 I : 2.969 2.969 +S K ; ; : N 2159 1429 318 53 rp C 1 0 scol L ; : N 2159 1482 318 3 rp C 1 0 scol L ; : 2474 1429 6 56 rc N 2477 1429 M 2477 1485 I : 2.969 2.969 +S K ; ; : N 2480 1429 48 53 rp C 1 0 scol L ; : 2483 1432 45 38 rc : 16 13 8 16 48 38 2483 1432 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2480 1479 51 6 rc N 2480 1482 M 2531 1482 I : 2.969 2.969 +S K ; ; : N 2528 1429 3 53 rp C 1 0 scol L ; : N 2531 1429 258 53 rp C 1 0 scol L ; 0 0 scol 2534 1468 M (band)[24 22 24 0]xS 0.754 0 scol : 2531 1479 261 6 rc N 2531 1482 M 2792 1482 I : 2.969 2.969 +S K ; ; : 2786 1429 6 56 rc N 2789 1429 M 2789 1485 I : 2.969 2.969 +S K ; ; : N 2792 1429 371 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1467 M (optical)[22 22 11 9 20 22 0]xS 0.754 0 scol : 2792 1479 374 6 rc N 2792 1482 M 3166 1482 I : 2.969 2.969 +S K ; ; : 3160 1429 6 56 rc N 3163 1429 M 3163 1485 I : 2.969 2.969 +S K ; ; : N 53 1485 173 54 rp C 1 0 scol L ; : N 53 1539 173 3 rp C 1 0 scol L ; : 223 1485 6 57 rc N 226 1485 M 226 1542 I : 2.969 2.969 +S K ; ; : N 279 1485 377 54 rp C 1 0 scol L ; : N 279 1539 377 3 rp C 1 0 scol L ; : 653 1485 6 57 rc N 656 1485 M 656 1542 I : 2.969 2.969 +S K ; ; : N 710 1485 113 54 rp C 1 0 scol L ; : N 710 1539 113 3 rp C 1 0 scol L ; : 820 1485 6 57 rc N 823 1485 M 823 1542 I : 2.969 2.969 +S K ; ; : N 876 1485 122 54 rp C 1 0 scol L ; : N 876 1539 122 3 rp C 1 0 scol L ; : 995 1485 6 57 rc N 998 1485 M 998 1542 I : 2.969 2.969 +S K ; ; : N 1051 1485 295 54 rp C 1 0 scol L ; : N 1051 1539 295 3 rp C 1 0 scol L ; : 1343 1485 6 57 rc N 1346 1485 M 1346 1542 I : 2.969 2.969 +S K ; ; : N 1399 1485 181 54 rp C 1 0 scol L ; : N 1399 1539 181 3 rp C 1 0 scol L ; : 1577 1485 6 57 rc N 1580 1485 M 1580 1542 I : 2.969 2.969 +S K ; ; : N 1634 1485 211 54 rp C 1 0 scol L ; : N 1634 1539 211 3 rp C 1 0 scol L ; : 1842 1485 6 57 rc N 1845 1485 M 1845 1542 I : 2.969 2.969 +S K ; ; : N 1898 1485 208 54 rp C 1 0 scol L ; : N 1898 1539 208 3 rp C 1 0 scol L ; : 2103 1485 6 57 rc N 2106 1485 M 2106 1542 I : 2.969 2.969 +S K ; ; : N 2159 1485 318 54 rp C 1 0 scol L ; : N 2159 1539 318 3 rp C 1 0 scol L ; : 2474 1485 6 57 rc N 2477 1485 M 2477 1542 I : 2.969 2.969 +S K ; ; : N 2480 1485 48 54 rp C 1 0 scol L ; : 2483 1488 45 39 rc : 16 13 8 16 48 39 2483 1488 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 2480 1536 51 6 rc N 2480 1539 M 2531 1539 I : 2.969 2.969 +S K ; ; : N 2528 1485 3 54 rp C 1 0 scol L ; : N 2531 1485 258 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 2534 1524 M (quality)[24 24 22 11 11 13 0]xS 0.754 0 scol : 2531 1536 261 6 rc N 2531 1539 M 2792 1539 I : 2.969 2.969 +S K ; ; : 2786 1485 6 57 rc N 2789 1485 M 2789 1542 I : 2.969 2.969 +S K ; ; : N 2792 1485 371 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1523 M (@@q)[40 40 0]xS 0.754 0 scol : 2792 1536 374 6 rc N 2792 1539 M 3166 1539 I : 2.969 2.969 +S K ; ; : 3160 1485 6 57 rc N 3163 1485 M 3163 1542 I : 2.969 2.969 +S K ; ; : N 53 1542 173 53 rp C 1 0 scol L ; : N 53 1595 173 3 rp C 1 0 scol L ; : 223 1542 6 56 rc N 226 1542 M 226 1598 I : 2.969 2.969 +S K ; ; : N 279 1542 377 53 rp C 1 0 scol L ; : N 279 1595 377 3 rp C 1 0 scol L ; : 653 1542 6 56 rc N 656 1542 M 656 1598 I : 2.969 2.969 +S K ; ; : N 710 1542 113 53 rp C 1 0 scol L ; : 710 1592 116 6 rc N 710 1595 M 826 1595 I : 2.969 2.969 +S K ; ; : 820 1542 6 56 rc N 823 1542 M 823 1598 I : 2.969 2.969 +S K ; ; : N 876 1542 122 53 rp C 1 0 scol L ; : 876 1592 125 6 rc N 876 1595 M 1001 1595 I : 2.969 2.969 +S K ; ; : 995 1542 6 56 rc N 998 1542 M 998 1598 I : 2.969 2.969 +S K ; ; : N 1051 1542 295 53 rp C 1 0 scol L ; : 1051 1592 298 6 rc N 1052 1595 M 1349 1595 I : 2.969 2.969 +S K ; ; : 1343 1542 6 56 rc N 1346 1542 M 1346 1598 I : 2.969 2.969 +S K ; ; : N 1399 1542 181 53 rp C 1 0 scol L ; : 1399 1592 184 6 rc N 1399 1595 M 1583 1595 I : 2.969 2.969 +S K ; ; : 1577 1542 6 56 rc N 1580 1542 M 1580 1598 I : 2.969 2.969 +S K ; ; : N 1634 1542 211 53 rp C 1 0 scol L ; : 1634 1592 214 6 rc N 1634 1595 M 1848 1595 I : 2.969 2.969 +S K ; ; : 1842 1542 6 56 rc N 1845 1542 M 1845 1598 I : 2.969 2.969 +S K ; ; : N 1898 1542 208 53 rp C 1 0 scol L ; : 1898 1592 211 6 rc N 1898 1595 M 2109 1595 I : 2.969 2.969 +S K ; ; : 2103 1542 6 56 rc N 2106 1542 M 2106 1598 I : 2.969 2.969 +S K ; ; : N 2159 1542 318 53 rp C 1 0 scol L ; : 2159 1592 321 6 rc N 2159 1595 M 2480 1595 I : 2.969 2.969 +S K ; ; : 2474 1542 6 56 rc N 2477 1542 M 2477 1598 I : 2.969 2.969 +S K ; ; : N 2480 1542 48 53 rp C 1 0 scol L ; : 2483 1545 45 38 rc : 16 13 8 16 48 38 2483 1545 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 2480 1592 51 6 rc N 2480 1595 M 2531 1595 I : 2.969 2.969 +S K ; ; : N 2528 1542 3 53 rp C 1 0 scol L ; : N 2531 1542 258 53 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2534 1580 M (siap:)[22 11 22 24 0]xS F2S26 Ji 2626 1581 M (URL)[28 28 0]xS 0.754 0 scol : 2531 1592 261 6 rc N 2531 1595 M 2792 1595 I : 2.969 2.969 +S K ; ; : 2786 1542 6 56 rc N 2789 1542 M 2789 1598 I : 2.969 2.969 +S K ; ; : N 2792 1542 371 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 1580 M (@@images)[40 40 9 33 22 22 22 0]xS 0.754 0 scol : 2792 1592 374 6 rc N 2792 1595 M 3166 1595 I : 2.969 2.969 +S K ; ; : 3160 1542 6 56 rc N 3163 1542 M 3163 1598 I : 2.969 2.969 +S K ; ; : N 53 1598 173 51 rp C 1 0 scol L ; : N 53 1649 173 2 rp C 1 0 scol L ; : 223 1598 6 53 rc N 226 1598 M 226 1652 I : 2.969 2.969 +S K ; ; : N 279 1598 377 51 rp C 1 0 scol L ; : N 279 1649 377 2 rp C 1 0 scol L ; : 653 1598 6 53 rc N 656 1598 M 656 1652 I : 2.969 2.969 +S K ; ; : N 671 1607 27 579 rp C 0.91 0 scol L ; 1 0 scol N 671 2186 M 671 1607 I : 2.969 2.969 +S K ; N 671 1607 M 698 1607 I : 2.969 2.969 +S K ; 0.496 0 scol N 671 2183 M 695 2183 I : 2.969 2.969 +S K ; N 695 2183 M 695 1607 I : 2.969 2.969 +S K ; : N 668 1604 33 3 rp C 0.91 0 scol L ; : N 668 2186 33 3 rp C 0.91 0 scol L ; : N 668 1607 3 579 rp C 0.91 0 scol L ; : N 698 1607 3 579 rp C 0.91 0 scol L ; : N 659 1598 9 597 rp C 1 0 scol L ; : N 701 1598 6 597 rp C 1 0 scol L ; : N 659 1598 48 6 rp C 1 0 scol L ; : N 659 2189 48 6 rp C 1 0 scol L ; : N 683 1616 M 683 1619 I 680 1619 I 680 1622 I 677 1622 I 677 1625 I 674 1625 I 674 1628 I 695 1628 I 695 1625 I 692 1625 I 692 1622 I 689 1622 I 689 1619 I 686 1619 I 686 1616 I C eoclip : N 674 1616 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 659 2192 51 6 rc N 659 2195 M 710 2195 I : 2.969 2.969 +S K ; ; : N 707 1598 3 597 rp C 1 0 scol L ; : N 710 1598 2453 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 713 1637 M (math)[35 22 13 0]xS 0.754 0 scol : 817 1646 2349 5 rc N 820 1649 M 3166 1649 I : 2.969 2.969 +S K ; ; : 3160 1598 6 53 rc N 3163 1598 M 3163 1652 I : 2.969 2.969 +S K ; ; 1 0 scol : 710 1646 117 5 rc N 710 1649 M 823 1649 I : 2.969 2.969 +S K ; ; : N 53 1651 173 51 rp C L ; : N 53 1702 173 3 rp C L ; 0.754 0 scol : 223 1651 6 54 rc N 226 1652 M 226 1705 I : 2.969 2.969 +S K ; ; : N 279 1651 377 51 rp C 1 0 scol L ; : N 279 1702 377 3 rp C 1 0 scol L ; : 653 1651 6 54 rc N 656 1652 M 656 1705 I : 2.969 2.969 +S K ; ; : N 710 1651 113 51 rp C 1 0 scol L ; : N 710 1702 113 3 rp C 1 0 scol L ; : 820 1651 6 54 rc N 823 1652 M 823 1705 I : 2.969 2.969 +S K ; ; : N 838 1660 26 526 rp C 0.91 0 scol L ; 1 0 scol N 838 2186 M 838 1660 I : 2.969 2.969 +S K ; N 838 1660 M 864 1660 I : 2.969 2.969 +S K ; 0.496 0 scol N 838 2183 M 861 2183 I : 2.969 2.969 +S K ; N 861 2183 M 861 1660 I : 2.969 2.969 +S K ; : N 835 1657 32 3 rp C 0.91 0 scol L ; : N 835 2186 32 3 rp C 0.91 0 scol L ; : N 835 1660 3 526 rp C 0.91 0 scol L ; : N 864 1660 3 526 rp C 0.91 0 scol L ; : N 826 1651 9 544 rp C 1 0 scol L ; : N 867 1651 6 544 rp C 1 0 scol L ; : N 826 1651 47 6 rp C 1 0 scol L ; : N 826 2189 47 6 rp C 1 0 scol L ; : N 850 1669 M 850 1672 I 847 1672 I 847 1675 I 844 1675 I 844 1678 I 841 1678 I 841 1681 I 861 1681 I 861 1678 I 858 1678 I 858 1675 I 855 1675 I 855 1672 I 853 1672 I 853 1669 I C eoclip : N 841 1669 20 12 rp C 0 0 scol L ; ; 0.754 0 scol : 826 2192 50 6 rc N 826 2195 M 876 2195 I : 2.969 2.969 +S K ; ; : N 873 1651 3 544 rp C 1 0 scol L ; : N 876 1651 2287 51 rp C 1 0 scol L ; 0 0 scol 879 1690 M (apply)[22 24 24 11 0]xS 0.754 0 scol : 992 1699 2174 6 rc N 995 1702 M 3166 1702 I : 2.969 2.969 +S K ; ; : 3160 1651 6 54 rc N 3163 1652 M 3163 1705 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 1699 126 6 rc N 876 1702 M 998 1702 I : 2.969 2.969 +S K ; ; : N 53 1705 173 50 rp C L ; : N 53 1755 173 3 rp C L ; 0.754 0 scol : 223 1705 6 53 rc N 226 1705 M 226 1758 I : 2.969 2.969 +S K ; ; : N 279 1705 377 50 rp C 1 0 scol L ; : N 279 1755 377 3 rp C 1 0 scol L ; : 653 1705 6 53 rc N 656 1705 M 656 1758 I : 2.969 2.969 +S K ; ; : N 710 1705 113 50 rp C 1 0 scol L ; : N 710 1755 113 3 rp C 1 0 scol L ; : 820 1705 6 53 rc N 823 1705 M 823 1758 I : 2.969 2.969 +S K ; ; : N 876 1705 122 50 rp C 1 0 scol L ; : N 876 1755 122 3 rp C 1 0 scol L ; : 995 1705 6 53 rc N 998 1705 M 998 1758 I : 2.969 2.969 +S K ; ; : N 1013 1714 27 472 rp C 0.91 0 scol L ; 1 0 scol N 1013 2186 M 1013 1714 I : 2.969 2.969 +S K ; N 1013 1714 M 1040 1714 I : 2.969 2.969 +S K ; 0.496 0 scol N 1013 2183 M 1037 2183 I : 2.969 2.969 +S K ; N 1037 2183 M 1037 1714 I : 2.969 2.969 +S K ; : N 1010 1711 33 3 rp C 0.91 0 scol L ; : N 1010 2186 33 3 rp C 0.91 0 scol L ; : N 1010 1714 3 472 rp C 0.91 0 scol L ; : N 1040 1714 3 472 rp C 0.91 0 scol L ; : N 1001 1705 9 490 rp C 1 0 scol L ; : N 1043 1705 6 490 rp C 1 0 scol L ; : N 1001 1705 48 6 rp C 1 0 scol L ; : N 1001 2189 48 6 rp C 1 0 scol L ; : N 1025 1723 M 1025 1726 I 1022 1726 I 1022 1729 I 1019 1729 I 1019 1732 I 1016 1732 I 1016 1735 I 1037 1735 I 1037 1732 I 1034 1732 I 1034 1729 I 1031 1729 I 1031 1726 I 1028 1726 I 1028 1723 I C eoclip : N 1016 1723 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1001 2192 50 6 rc N 1001 2195 M 1052 2195 I : 2.969 2.969 +S K ; ; : N 1049 1705 2 490 rp C 1 0 scol L ; : N 1051 1705 2112 50 rp C 1 0 scol L ; 0 0 scol : 1054 1708 70 44 rc 1054 1744 M (geq)[24 22 0]xS ; 0.754 0 scol : 1340 1752 1826 6 rc N 1343 1755 M 3166 1755 I : 2.969 2.969 +S K ; ; : 3160 1705 6 53 rc N 3163 1705 M 3163 1758 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1752 299 6 rc N 1052 1755 M 1346 1755 I : 2.969 2.969 +S K ; ; : N 53 1758 173 51 rp C L ; : N 53 1809 173 3 rp C L ; 0.754 0 scol : 223 1758 6 54 rc N 226 1758 M 226 1812 I : 2.969 2.969 +S K ; ; : N 279 1758 377 51 rp C 1 0 scol L ; : N 279 1809 377 3 rp C 1 0 scol L ; : 653 1758 6 54 rc N 656 1758 M 656 1812 I : 2.969 2.969 +S K ; ; : N 710 1758 113 51 rp C 1 0 scol L ; : N 710 1809 113 3 rp C 1 0 scol L ; : 820 1758 6 54 rc N 823 1758 M 823 1812 I : 2.969 2.969 +S K ; ; : N 876 1758 122 51 rp C 1 0 scol L ; : N 876 1809 122 3 rp C 1 0 scol L ; : 995 1758 6 54 rc N 998 1758 M 998 1812 I : 2.969 2.969 +S K ; ; : N 1051 1758 295 51 rp C 1 0 scol L ; : N 1051 1809 295 3 rp C 1 0 scol L ; : 1343 1758 6 54 rc N 1346 1758 M 1346 1812 I : 2.969 2.969 +S K ; ; : N 1360 1767 27 253 rp C 0.91 0 scol L ; 1 0 scol N 1360 2020 M 1360 1767 I : 2.969 2.969 +S K ; N 1360 1767 M 1387 1767 I : 2.969 2.969 +S K ; 0.496 0 scol N 1360 2017 M 1384 2017 I : 2.969 2.969 +S K ; N 1384 2017 M 1384 1767 I : 2.969 2.969 +S K ; : N 1357 1764 33 3 rp C 0.91 0 scol L ; : N 1357 2020 33 3 rp C 0.91 0 scol L ; : N 1357 1767 3 253 rp C 0.91 0 scol L ; : N 1387 1767 3 253 rp C 0.91 0 scol L ; : N 1349 1758 8 271 rp C 1 0 scol L ; : N 1390 1758 6 271 rp C 1 0 scol L ; : N 1349 1758 47 6 rp C 1 0 scol L ; : N 1349 2023 47 6 rp C 1 0 scol L ; : N 1372 1776 M 1372 1779 I 1369 1779 I 1369 1782 I 1366 1782 I 1366 1785 I 1363 1785 I 1363 1788 I 1384 1788 I 1384 1785 I 1381 1785 I 1381 1782 I 1378 1782 I 1378 1779 I 1375 1779 I 1375 1776 I C eoclip : N 1363 1776 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1349 2026 50 6 rc N 1349 2029 M 1399 2029 I : 2.969 2.969 +S K ; ; : N 1396 1758 3 271 rp C 1 0 scol L ; : N 1399 1758 1764 51 rp C 1 0 scol L ; 0 0 scol 1402 1797 M (apply)[22 24 24 11 0]xS 0.754 0 scol : 1574 1806 1592 6 rc N 1577 1809 M 3166 1809 I : 2.969 2.969 +S K ; ; : 3160 1758 6 54 rc N 3163 1758 M 3163 1812 I : 2.969 2.969 +S K ; ; 1 0 scol : 1399 1806 185 6 rc N 1399 1809 M 1580 1809 I : 2.969 2.969 +S K ; ; : N 53 1812 173 50 rp C L ; : N 53 1862 173 3 rp C L ; 0.754 0 scol : 223 1812 6 53 rc N 226 1812 M 226 1865 I : 2.969 2.969 +S K ; ; : N 279 1812 377 50 rp C 1 0 scol L ; : N 279 1862 377 3 rp C 1 0 scol L ; : 653 1812 6 53 rc N 656 1812 M 656 1865 I : 2.969 2.969 +S K ; ; : N 710 1812 113 50 rp C 1 0 scol L ; : N 710 1862 113 3 rp C 1 0 scol L ; : 820 1812 6 53 rc N 823 1812 M 823 1865 I : 2.969 2.969 +S K ; ; : N 876 1812 122 50 rp C 1 0 scol L ; : N 876 1862 122 3 rp C 1 0 scol L ; : 995 1812 6 53 rc N 998 1812 M 998 1865 I : 2.969 2.969 +S K ; ; : N 1051 1812 295 50 rp C 1 0 scol L ; : N 1051 1862 295 3 rp C 1 0 scol L ; : 1343 1812 6 53 rc N 1346 1812 M 1346 1865 I : 2.969 2.969 +S K ; ; : N 1399 1812 181 50 rp C 1 0 scol L ; : N 1399 1862 181 3 rp C 1 0 scol L ; : 1577 1812 6 53 rc N 1580 1812 M 1580 1865 I : 2.969 2.969 +S K ; ; : N 1595 1821 27 199 rp C 0.91 0 scol L ; 1 0 scol N 1595 2020 M 1595 1821 I : 2.969 2.969 +S K ; N 1595 1821 M 1622 1821 I : 2.969 2.969 +S K ; 0.496 0 scol N 1595 2017 M 1619 2017 I : 2.969 2.969 +S K ; N 1619 2017 M 1619 1821 I : 2.969 2.969 +S K ; : N 1592 1818 33 3 rp C 0.91 0 scol L ; : N 1592 2020 33 3 rp C 0.91 0 scol L ; : N 1592 1821 3 199 rp C 0.91 0 scol L ; : N 1622 1821 3 199 rp C 0.91 0 scol L ; : N 1583 1812 9 217 rp C 1 0 scol L ; : N 1625 1812 6 217 rp C 1 0 scol L ; : N 1583 1812 48 6 rp C 1 0 scol L ; : N 1583 2023 48 6 rp C 1 0 scol L ; : N 1607 1830 M 1607 1833 I 1604 1833 I 1604 1836 I 1601 1836 I 1601 1839 I 1598 1839 I 1598 1842 I 1619 1842 I 1619 1839 I 1616 1839 I 1616 1836 I 1613 1836 I 1613 1833 I 1610 1833 I 1610 1830 I C eoclip : N 1598 1830 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1583 2026 51 6 rc N 1583 2029 M 1634 2029 I : 2.969 2.969 +S K ; ; : N 1631 1812 3 217 rp C 1 0 scol L ; : N 1634 1812 1529 50 rp C 1 0 scol L ; 0 0 scol : 1637 1815 113 44 rc 1637 1851 M (divide)[24 11 21 11 24 0]xS ; 0.754 0 scol : 1839 1859 1327 6 rc N 1842 1862 M 3166 1862 I : 2.969 2.969 +S K ; ; : 3160 1812 6 53 rc N 3163 1812 M 3163 1865 I : 2.969 2.969 +S K ; ; 1 0 scol : 1634 1859 215 6 rc N 1634 1862 M 1845 1862 I : 2.969 2.969 +S K ; ; : N 53 1865 173 54 rp C L ; : N 53 1919 173 3 rp C L ; 0.754 0 scol : 223 1865 6 57 rc N 226 1865 M 226 1922 I : 2.969 2.969 +S K ; ; : N 279 1865 377 54 rp C 1 0 scol L ; : N 279 1919 377 3 rp C 1 0 scol L ; : 653 1865 6 57 rc N 656 1865 M 656 1922 I : 2.969 2.969 +S K ; ; : N 710 1865 113 54 rp C 1 0 scol L ; : N 710 1919 113 3 rp C 1 0 scol L ; : 820 1865 6 57 rc N 823 1865 M 823 1922 I : 2.969 2.969 +S K ; ; : N 876 1865 122 54 rp C 1 0 scol L ; : N 876 1919 122 3 rp C 1 0 scol L ; : 995 1865 6 57 rc N 998 1865 M 998 1922 I : 2.969 2.969 +S K ; ; : N 1051 1865 295 54 rp C 1 0 scol L ; : N 1051 1919 295 3 rp C 1 0 scol L ; : 1343 1865 6 57 rc N 1346 1865 M 1346 1922 I : 2.969 2.969 +S K ; ; : N 1399 1865 181 54 rp C 1 0 scol L ; : N 1399 1919 181 3 rp C 1 0 scol L ; : 1577 1865 6 57 rc N 1580 1865 M 1580 1922 I : 2.969 2.969 +S K ; ; : N 1634 1865 211 54 rp C 1 0 scol L ; : N 1634 1919 211 3 rp C 1 0 scol L ; : 1842 1865 6 57 rc N 1845 1865 M 1845 1922 I : 2.969 2.969 +S K ; ; : N 1848 1865 47 54 rp C 1 0 scol L ; : 1850 1868 45 39 rc : 16 13 8 16 48 39 1850 1868 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 1848 1916 50 6 rc N 1848 1919 M 1898 1919 I : 2.969 2.969 +S K ; ; : N 1895 1865 3 54 rp C 1 0 scol L ; : N 1898 1865 208 54 rp C 1 0 scol L ; 0 0 scol 1901 1904 M (ci)[22 0]xS 0.754 0 scol : 1898 1916 211 6 rc N 1898 1919 M 2109 1919 I : 2.969 2.969 +S K ; ; : 2103 1865 6 57 rc N 2106 1865 M 2106 1922 I : 2.969 2.969 +S K ; ; : N 2109 1865 1054 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2112 1903 M (@Xraybrightness)[40 25 13 22 19 22 13 9 22 22 11 22 22 19 0]xS 0.754 0 scol : 2109 1916 1057 6 rc N 2109 1919 M 3166 1919 I : 2.969 2.969 +S K ; ; : 3160 1865 6 57 rc N 3163 1865 M 3163 1922 I : 2.969 2.969 +S K ; ; : N 53 1922 173 50 rp C 1 0 scol L ; : N 53 1972 173 3 rp C 1 0 scol L ; : 223 1922 6 53 rc N 226 1922 M 226 1975 I : 2.969 2.969 +S K ; ; : N 279 1922 377 50 rp C 1 0 scol L ; : N 279 1972 377 3 rp C 1 0 scol L ; : 653 1922 6 53 rc N 656 1922 M 656 1975 I : 2.969 2.969 +S K ; ; : N 710 1922 113 50 rp C 1 0 scol L ; : N 710 1972 113 3 rp C 1 0 scol L ; : 820 1922 6 53 rc N 823 1922 M 823 1975 I : 2.969 2.969 +S K ; ; : N 876 1922 122 50 rp C 1 0 scol L ; : N 876 1972 122 3 rp C 1 0 scol L ; : 995 1922 6 53 rc N 998 1922 M 998 1975 I : 2.969 2.969 +S K ; ; : N 1051 1922 295 50 rp C 1 0 scol L ; : N 1051 1972 295 3 rp C 1 0 scol L ; : 1343 1922 6 53 rc N 1346 1922 M 1346 1975 I : 2.969 2.969 +S K ; ; : N 1399 1922 181 50 rp C 1 0 scol L ; : N 1399 1972 181 3 rp C 1 0 scol L ; : 1577 1922 6 53 rc N 1580 1922 M 1580 1975 I : 2.969 2.969 +S K ; ; : N 1634 1922 211 50 rp C 1 0 scol L ; : N 1634 1972 211 3 rp C 1 0 scol L ; : 1842 1922 6 53 rc N 1845 1922 M 1845 1975 I : 2.969 2.969 +S K ; ; : N 1859 1931 27 89 rp C 0.91 0 scol L ; 1 0 scol N 1859 2020 M 1859 1931 I : 2.969 2.969 +S K ; N 1859 1931 M 1886 1931 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 2017 M 1883 2017 I : 2.969 2.969 +S K ; N 1883 2017 M 1883 1931 I : 2.969 2.969 +S K ; : N 1856 1928 33 3 rp C 0.91 0 scol L ; : N 1856 2020 33 3 rp C 0.91 0 scol L ; : N 1856 1931 3 89 rp C 0.91 0 scol L ; : N 1886 1931 3 89 rp C 0.91 0 scol L ; : N 1848 1922 8 107 rp C 1 0 scol L ; : N 1889 1922 6 107 rp C 1 0 scol L ; : N 1848 1922 47 6 rp C 1 0 scol L ; : N 1848 2023 47 6 rp C 1 0 scol L ; : N 1871 1940 M 1871 1943 I 1868 1943 I 1868 1946 I 1865 1946 I 1865 1949 I 1862 1949 I 1862 1952 I 1883 1952 I 1883 1949 I 1880 1949 I 1880 1946 I 1877 1946 I 1877 1943 I 1874 1943 I 1874 1940 I C eoclip : N 1862 1940 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 2026 50 6 rc N 1848 2029 M 1898 2029 I : 2.969 2.969 +S K ; ; : N 1895 1922 3 107 rp C 1 0 scol L ; : N 1898 1922 1265 50 rp C 1 0 scol L ; 0 0 scol : 1901 1925 102 44 rc F2S26 Ji 1901 1961 M (apply)[22 24 24 11 0]xS ; 0.754 0 scol : 2100 1969 1066 6 rc N 2103 1972 M 3166 1972 I : 2.969 2.969 +S K ; ; : 3160 1922 6 53 rc N 3163 1922 M 3163 1975 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 1969 212 6 rc N 1898 1972 M 2106 1972 I : 2.969 2.969 +S K ; ; : N 53 1975 173 54 rp C L ; : N 53 2029 173 3 rp C L ; 0.754 0 scol : 223 1975 6 57 rc N 226 1975 M 226 2032 I : 2.969 2.969 +S K ; ; : N 279 1975 377 54 rp C 1 0 scol L ; : N 279 2029 377 3 rp C 1 0 scol L ; : 653 1975 6 57 rc N 656 1975 M 656 2032 I : 2.969 2.969 +S K ; ; : N 710 1975 113 54 rp C 1 0 scol L ; : N 710 2029 113 3 rp C 1 0 scol L ; : 820 1975 6 57 rc N 823 1975 M 823 2032 I : 2.969 2.969 +S K ; ; : N 876 1975 122 54 rp C 1 0 scol L ; : N 876 2029 122 3 rp C 1 0 scol L ; : 995 1975 6 57 rc N 998 1975 M 998 2032 I : 2.969 2.969 +S K ; ; : N 1051 1975 295 54 rp C 1 0 scol L ; : N 1051 2029 295 3 rp C 1 0 scol L ; : 1343 1975 6 57 rc N 1346 1975 M 1346 2032 I : 2.969 2.969 +S K ; ; : N 1399 1975 181 54 rp C 1 0 scol L ; : 1399 2026 184 6 rc N 1399 2029 M 1583 2029 I : 2.969 2.969 +S K ; ; : 1577 1975 6 57 rc N 1580 1975 M 1580 2032 I : 2.969 2.969 +S K ; ; : N 1634 1975 211 54 rp C 1 0 scol L ; : 1634 2026 214 6 rc N 1634 2029 M 1848 2029 I : 2.969 2.969 +S K ; ; : 1842 1975 6 57 rc N 1845 1975 M 1845 2032 I : 2.969 2.969 +S K ; ; : N 1898 1975 208 54 rp C 1 0 scol L ; : 1898 2026 211 6 rc N 1898 2029 M 2109 2029 I : 2.969 2.969 +S K ; ; : 2103 1975 6 57 rc N 2106 1975 M 2106 2032 I : 2.969 2.969 +S K ; ; : N 2109 1975 47 54 rp C 1 0 scol L ; : 2112 1978 44 39 rc : 16 13 8 16 47 39 2112 1978 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 2109 2026 50 6 rc N 2109 2029 M 2159 2029 I : 2.969 2.969 +S K ; ; : N 2156 1975 3 54 rp C 1 0 scol L ; : N 2159 1975 318 54 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2162 2013 M (ql:)[24 10 0]xS F2S26 Ji 2210 2014 M (numberOf)[24 24 35 24 22 15 30 0]xS 0.754 0 scol : 2159 2026 321 6 rc N 2159 2029 M 2480 2029 I : 2.969 2.969 +S K ; ; : 2474 1975 6 57 rc N 2477 1975 M 2477 2032 I : 2.969 2.969 +S K ; ; : N 2480 1975 683 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2483 2013 M (@galaxyName)[40 22 22 9 22 18 19 28 22 33 0]xS 0.754 0 scol : 2480 2026 686 6 rc N 2480 2029 M 3166 2029 I : 2.969 2.969 +S K ; ; : 3160 1975 6 57 rc N 3163 1975 M 3163 2032 I : 2.969 2.969 +S K ; ; : N 53 2032 173 50 rp C 1 0 scol L ; : N 53 2082 173 3 rp C 1 0 scol L ; : 223 2032 6 53 rc N 226 2032 M 226 2085 I : 2.969 2.969 +S K ; ; : N 279 2032 377 50 rp C 1 0 scol L ; : N 279 2082 377 3 rp C 1 0 scol L ; : 653 2032 6 53 rc N 656 2032 M 656 2085 I : 2.969 2.969 +S K ; ; : N 710 2032 113 50 rp C 1 0 scol L ; : N 710 2082 113 3 rp C 1 0 scol L ; : 820 2032 6 53 rc N 823 2032 M 823 2085 I : 2.969 2.969 +S K ; ; : N 876 2032 122 50 rp C 1 0 scol L ; : N 876 2082 122 3 rp C 1 0 scol L ; : 995 2032 6 53 rc N 998 2032 M 998 2085 I : 2.969 2.969 +S K ; ; : N 1051 2032 295 50 rp C 1 0 scol L ; : N 1051 2082 295 3 rp C 1 0 scol L ; : 1343 2032 6 53 rc N 1346 2032 M 1346 2085 I : 2.969 2.969 +S K ; ; : N 1360 2041 27 145 rp C 0.91 0 scol L ; 1 0 scol N 1360 2186 M 1360 2041 I : 2.969 2.969 +S K ; N 1360 2041 M 1387 2041 I : 2.969 2.969 +S K ; 0.496 0 scol N 1360 2183 M 1384 2183 I : 2.969 2.969 +S K ; N 1384 2183 M 1384 2041 I : 2.969 2.969 +S K ; : N 1357 2038 33 3 rp C 0.91 0 scol L ; : N 1357 2186 33 3 rp C 0.91 0 scol L ; : N 1357 2041 3 145 rp C 0.91 0 scol L ; : N 1387 2041 3 145 rp C 0.91 0 scol L ; : N 1349 2032 8 163 rp C 1 0 scol L ; : N 1390 2032 6 163 rp C 1 0 scol L ; : N 1349 2032 47 6 rp C 1 0 scol L ; : N 1349 2189 47 6 rp C 1 0 scol L ; : N 1372 2050 M 1372 2053 I 1369 2053 I 1369 2055 I 1366 2055 I 1366 2058 I 1363 2058 I 1363 2061 I 1384 2061 I 1384 2058 I 1381 2058 I 1381 2055 I 1378 2055 I 1378 2053 I 1375 2053 I 1375 2050 I C eoclip : N 1363 2050 21 11 rp C 0 0 scol L ; ; 0.754 0 scol : 1349 2192 50 6 rc N 1349 2195 M 1399 2195 I : 2.969 2.969 +S K ; ; : N 1396 2032 3 163 rp C 1 0 scol L ; : N 1399 2032 1764 50 rp C 1 0 scol L ; 0 0 scol : 1402 2035 46 44 rc F2S26 Ji 1402 2071 M (cn)[22 0]xS ; 0.754 0 scol : 1574 2079 1592 6 rc N 1577 2082 M 3166 2082 I : 2.969 2.969 +S K ; ; : 3160 2032 6 53 rc N 3163 2032 M 3163 2085 I : 2.969 2.969 +S K ; ; 1 0 scol : 1399 2079 185 6 rc N 1399 2082 M 1580 2082 I : 2.969 2.969 +S K ; ; : N 53 2085 173 54 rp C L ; : N 53 2139 173 3 rp C L ; 0.754 0 scol : 223 2085 6 57 rc N 226 2085 M 226 2142 I : 2.969 2.969 +S K ; ; : N 279 2085 377 54 rp C 1 0 scol L ; : N 279 2139 377 3 rp C 1 0 scol L ; : 653 2085 6 57 rc N 656 2085 M 656 2142 I : 2.969 2.969 +S K ; ; : N 710 2085 113 54 rp C 1 0 scol L ; : N 710 2139 113 3 rp C 1 0 scol L ; : 820 2085 6 57 rc N 823 2085 M 823 2142 I : 2.969 2.969 +S K ; ; : N 876 2085 122 54 rp C 1 0 scol L ; : N 876 2139 122 3 rp C 1 0 scol L ; : 995 2085 6 57 rc N 998 2085 M 998 2142 I : 2.969 2.969 +S K ; ; : N 1051 2085 295 54 rp C 1 0 scol L ; : N 1051 2139 295 3 rp C 1 0 scol L ; : 1343 2085 6 57 rc N 1346 2085 M 1346 2142 I : 2.969 2.969 +S K ; ; : N 1399 2085 181 54 rp C 1 0 scol L ; : N 1399 2139 181 3 rp C 1 0 scol L ; : 1577 2085 6 57 rc N 1580 2085 M 1580 2142 I : 2.969 2.969 +S K ; ; : N 1583 2085 48 54 rp C 1 0 scol L ; : 1586 2088 45 39 rc : 16 13 8 16 48 39 1586 2088 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1583 2136 51 6 rc N 1583 2139 M 1634 2139 I : 2.969 2.969 +S K ; ; : N 1631 2085 3 54 rp C 1 0 scol L ; : N 1634 2085 211 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1637 2124 M (units)[24 24 11 13 0]xS 0.754 0 scol : 1634 2136 214 6 rc N 1634 2139 M 1848 2139 I : 2.969 2.969 +S K ; ; : 1842 2085 6 57 rc N 1845 2085 M 1845 2142 I : 2.969 2.969 +S K ; ; : N 1848 2085 1315 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1851 2123 M (Jansky)[20 22 22 19 20 0]xS 0.754 0 scol : 1848 2136 1318 6 rc N 1848 2139 M 3166 2139 I : 2.969 2.969 +S K ; ; : 3160 2085 6 57 rc N 3163 2085 M 3163 2142 I : 2.969 2.969 +S K ; ; : N 53 2142 173 53 rp C 1 0 scol L ; : N 53 2195 173 3 rp C 1 0 scol L ; : 223 2142 6 56 rc N 226 2142 M 226 2198 I : 2.969 2.969 +S K ; ; : N 279 2142 377 53 rp C 1 0 scol L ; : 279 2192 380 6 rc N 279 2195 M 659 2195 I : 2.969 2.969 +S K ; ; : 653 2142 6 56 rc N 656 2142 M 656 2198 I : 2.969 2.969 +S K ; ; : N 710 2142 113 53 rp C 1 0 scol L ; : 710 2192 116 6 rc N 710 2195 M 826 2195 I : 2.969 2.969 +S K ; ; : 820 2142 6 56 rc N 823 2142 M 823 2198 I : 2.969 2.969 +S K ; ; : N 876 2142 122 53 rp C 1 0 scol L ; : 876 2192 125 6 rc N 876 2195 M 1001 2195 I : 2.969 2.969 +S K ; ; : 995 2142 6 56 rc N 998 2142 M 998 2198 I : 2.969 2.969 +S K ; ; : N 1051 2142 295 53 rp C 1 0 scol L ; : 1051 2192 298 6 rc N 1052 2195 M 1349 2195 I : 2.969 2.969 +S K ; ; : 1343 2142 6 56 rc N 1346 2142 M 1346 2198 I : 2.969 2.969 +S K ; ; : N 1399 2142 181 53 rp C 1 0 scol L ; : 1399 2192 184 6 rc N 1399 2195 M 1583 2195 I : 2.969 2.969 +S K ; ; : 1577 2142 6 56 rc N 1580 2142 M 1580 2198 I : 2.969 2.969 +S K ; ; : N 1583 2142 48 53 rp C 1 0 scol L ; : 1586 2145 45 38 rc : 16 13 8 16 48 38 1586 2145 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; ; : 1583 2192 51 6 rc N 1583 2195 M 1634 2195 I : 2.969 2.969 +S K ; ; : N 1631 2142 3 53 rp C 1 0 scol L ; : N 1634 2142 211 53 rp C 1 0 scol L ; 0 0 scol F1S26 Ji 1637 2181 M (Text)[24 22 20 0]xS 0.754 0 scol : 1634 2192 214 6 rc N 1634 2195 M 1848 2195 I : 2.969 2.969 +S K ; ; : 1842 2142 6 56 rc N 1845 2142 M 1845 2198 I : 2.969 2.969 +S K ; ; : N 1848 2142 1315 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1851 2180 M (3.0E3)[22 11 22 26 0]xS 0.754 0 scol : 1848 2192 1318 6 rc N 1848 2195 M 3166 2195 I : 2.969 2.969 +S K ; ; : 3160 2142 6 56 rc N 3163 2142 M 3163 2198 I : 2.969 2.969 +S K ; ; : N 53 2198 173 51 rp C 1 0 scol L ; : N 53 2249 173 2 rp C 1 0 scol L ; : 223 2198 6 53 rc N 226 2198 M 226 2252 I : 2.969 2.969 +S K ; ; : N 241 2207 26 101 rp C 0.91 0 scol L ; 1 0 scol : 238 2204 7 104 rc N 241 3621 M 241 2207 I : 2.969 2.969 +S K ; ; N 241 2207 M 267 2207 I : 2.969 2.969 +S K ; 0.496 0 scol : 261 2204 7 104 rc N 264 3618 M 264 2207 I : 2.969 2.969 +S K ; ; : N 238 2204 32 3 rp C 0.91 0 scol L ; : N 238 2207 3 101 rp C 0.91 0 scol L ; : N 267 2207 3 101 rp C 0.91 0 scol L ; : N 229 2198 9 110 rp C 1 0 scol L ; : N 270 2198 6 110 rp C 1 0 scol L ; : N 229 2198 47 6 rp C 1 0 scol L ; : N 253 2216 M 253 2219 I 250 2219 I 250 2222 I 247 2222 I 247 2225 I 244 2225 I 244 2228 I 264 2228 I 264 2225 I 261 2225 I 261 2222 I 258 2222 I 258 2219 I 255 2219 I 255 2216 I C eoclip : N 244 2216 20 12 rp C 0 0 scol L ; ; : N 276 2198 3 110 rp C 1 0 scol L ; : N 279 2198 2884 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 282 2237 M (return)[15 22 13 24 15 0]xS 0.754 0 scol : 650 2246 2516 5 rc N 653 2249 M 3166 2249 I : 2.969 2.969 +S K ; ; : 3160 2198 6 53 rc N 3163 2198 M 3163 2252 I : 2.969 2.969 +S K ; ; 1 0 scol : 279 2246 381 5 rc N 279 2249 M 656 2249 I : 2.969 2.969 +S K ; ; : N 53 2251 173 54 rp C L ; : N 53 2305 173 3 rp C L ; 0.754 0 scol : 223 2251 6 57 rc N 226 2252 M 226 2308 I : 2.969 2.969 +S K ; ; : N 279 2251 377 54 rp C 1 0 scol L ; : N 279 2305 377 3 rp C 1 0 scol L ; : 653 2251 6 57 rc N 656 2252 M 656 2308 I : 2.969 2.969 +S K ; ; : N 659 2251 48 54 rp C 1 0 scol L ; : 662 2254 45 39 rc : 16 13 8 16 48 39 662 2254 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 659 2302 51 6 rc N 659 2305 M 710 2305 I : 2.969 2.969 +S K ; ; : N 707 2251 3 54 rp C 1 0 scol L ; : N 710 2251 113 54 rp C 1 0 scol L ; 0 0 scol 713 2290 M (type)[13 21 24 0]xS 0.754 0 scol : 710 2302 116 6 rc N 710 2305 M 826 2305 I : 2.969 2.969 +S K ; ; : 820 2251 6 57 rc N 823 2252 M 823 2308 I : 2.969 2.969 +S K ; ; : N 826 2251 2337 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 829 2289 M (VOTable)[26 30 23 22 22 9 0]xS 0.754 0 scol : 826 2302 2340 6 rc N 826 2305 M 3166 2305 I : 2.969 2.969 +S K ; ; : 3160 2251 6 57 rc N 3163 2252 M 3163 2308 I : 2.969 2.969 +S K ; ; LH (%%[Page: 2]%%) = %%PageTrailer %%Page: 3 3 %%PageBoundingBox: 15 13 597 780 %%EndPageComments %%BeginPageSetup /DeviceRGB dup setcolorspace /colspABC exch def mysetup concat colspRefresh %%EndPageSetup /DeviceGray dup setcolorspace /colspABC exch def : 550 348 8 550 172 109 1509 0 F F 3 [ 0 ] F X doNimage JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL) JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$qZ#aZJcC<$qu;6IK)aI' JcCB&JcCN*c2`FqM#W&+MuUcsJcC]/JcCf2^&W`aOT0n3PQ/&kJcCu7JcD&9YQ07SQiDX:R/a5f JcD/V>u2ISH"0?T)YG`JcDABJcDDCS,e-?U&T]DUApS\JcDMFJcDPGPQ6:7V>l,HVZ2_X JcDYJJcD\KMu\G/WW.PLWrIkTJcDeNJcDhOKE-T'XoEtPXoEtQJcDnQJcDqRJH5ZLJcDtSJcE"T JH5NHJcE%UJcE%UJH5HFJcE(VJcE+WJH5CCX8qqnec::$d/S[sd/Vc!mJjNnmJki>JcF-tJcF*s gApI;\cCsogAlg)dJndtdJqu%jSupojT"!8JcF0uJcF0uh#QF6^]bCn h>c=3JcF7"JcF4!hZ2F2`W4cnhZ/6-eGk+"eGnD+g&K+ng&Kq0JcF:#JcF:#hZ2:.aoL&nhZ/6- f)L=$ec4P-ec3hnec4P-JcF=$JcF=$huM7+c2c>nhuJ?.fDgF%fDjb/dJqPndJr,)JcFC&JcF@% huM.(dK%Vni;eH/f`-O&f`0k0cMuAoli6b\m/PuDJcFF'JcFC&i;h+%ec>+;o)S4Yi;eH/g&HX' g&Kt1bQ$2pmf2_UnGhDHJcFI(JcFI(huLn!g&UUAlN$JThuJ?.g])j)gAg(2aT(#qn,MVPo)IVJ JcFL)JcFL)huLdsh>m$Ek5b)QhuJ?.h#Ds*g]-13`W+irn,MJLoDd_KJcFO*JcFO*hZ1UpiW/HI j8efOhZ/6-h>`'+h#H:4_Z/Zsn,MAIoDd_KJcFR+JcFR+hZ1LmjoFlMi;iKLhZ/6-hZ&0,h>c@4 _#NTun,M8Fo`*eKJcFU,JcFU,h>k=jl2^;Qh>m3Jh>i-,huA9-hZ)F4^AmO"n,M2DoDd\JJcFX- JcFX-h>k4gmJu_UgApmGh>i-,i;\B.huDO5]Dq@#n,M)Ao`*bJJcF[.JcF[.h#P%dnc8.Yf`:[E h#N$+iW"K/i;_U5\c;:%n,M#?o`*_IJcF^/JcF^/g]4kap&OR]f)YICg]2p*ir=T0iW%[5\,Z4' n,Lr=o`*\HJcFa0JcF^/g]4e_q>g!aeH#7Ag]2p*ir=T0ir@^4[f?7*n,Ll;o`*YGJcFd1JcFa0 g&SP\rW)Eee,].@g&Q^(j8X]1j8[d4[/U++n,Li:o`*SEJcFg2JcFd1f`7cHdK&q>f`6U'jSsf2 j8[d4U]8aBoDdJDJcFg2JcFg2f)VZId/`h=f)UC%jo9o3jT!g3VZ5$DoDdDBJcFj3JcFg2f)V`K d/`b;f)UC%jo9o3jo JcFm4JcFj3e,ZWNciEV9e,Y("k5U#4k5Wj0YQ)rLnc.#;JcFp5JcFm4dK$NOciES8dK"jukPp,5 k5Wg/ZN&8OnGgl9JcFp5JcFm4ciCHQciES8ciAXskPp,5kPrg-[f=\SnGgc6JcFs6JcFp5blG9R ciES8blE=pkl656kPra+])U+WnGg]4JcFs6JcFp5b5f3Td/`Y8b5d+nkl656kl8a)^AlR\n,LK0 JcG!7JcFs6a8j$Ud/`Y8a8gekl2Q>7kl8['_Z/!`n,LE.JcG!7JcFs6`W3sWd/`Y8`W1Sil2Q>7 kl8U%`rFEdn,L?,JcG!7JcG!7_Z7dXd/`Y8_Z58flMlG8l2SU#b5]ihn,L6)JcG$8JcG!7_#V^Z d/`Y8_#T&dlMlG8l2SO!cMu8ln,L0'JcG$8JcG!7^AuX\d/`Y8^AriblMlG8l2SHtdf7\pn,L*% JcG$8JcG!7]`?R^d/`Y8]`bn'n,KisJcG'9JcG$8[K,4b dK&b9[K(mYli2P9lMn6li;_7+n,KcqJcG'9JcG$8ZiK(be,\t;ZiG[Wli2P9lMn0jj8[U/n,K]o JcG'9JcG$8Z2itceH#(YQ07Sli2P9 lMn$fkPs07n,KQkJcG'9JcG$8YQ3hcfDt@>YQ07Sli2P9lMn*hjo.ln,L0' JcG$8JcG!7_#Va[ciEP7_#T&dlMlG8l2SU#bQ#ohn,L6)JcG$8JcG!7_Z7gYciEP7_Z58flMlG8 kl8U%a8aKdn,L?,JcG!7JcFs6`W4!XciEP7`W1Sil2Q>7kl8['_uJ'`n,LE.JcG!7JcFs6a8j'V ciEP7a8gekl2Q>7kl8a)^]2X\n,LK0JcG!7JcFs6aoK-TciEP7aoI"ml2Q>7kPra+]Dp4Xn,LT3 JcFs6JcFp5blG@Bg]2p*ir=T0i;_U5\Gu7&n,Lu>o`*_I JcF^/JcF[.h#P"coDn@[fDtRDh#N$+iW"K/i;_U5])V=$n,M&@o`*_IJcF^/JcFX-h>k1fn,VqW g&UdFh>i-,i;\B.huDO5]`7C"n,M,Bo`*bJJcF[.JcFU,h>k:ili?MSh#R*Ih>i-,huA9-hZ)F4 ^]3R!n,M5Eo`*bJJcFX-JcFR+hZ1IlkQ()OhZ3c@4_>iWtn,M>HoDd\JJcFU, JcFO*huLXoj8eZKiW/TMhuJ?.h>`'+h#H73`;efsn,MGKoDd\JJcFR+JcFL)huLarhuN6GjoFuP huJ?.h#Ds*g]-13`rFlqn,MPNo)IVJJcFO*JcFI(huLjug]6gCklC;ShuJ?.g])j)g&L"2aoC&p mf2YSnGhGIJcFI(JcFF'huLt#fDt@>mf;kWhuJ?.gAca(f`0n1bl?5omJlbXmf25GJcFF'JcFC& huM(&e,\h7q#Kd]huJ?.g&HX'fDjb/d/VMod/W#(JcFC&JcF=$huM4*ciDMohuJ?.fDgF%f)OY. e,R\ne,S>+JcF@%JcF:#huM=-bQ-2nhuJ?.f)L=$eGnG,fDitnfDjb/JcF:#JcF7"hZ2@0a8jon hZ/6-ec14#e,S8)h#G@oh#H42JcF7"JcF0uh>lI5_>rKnh>i-,e,P"!df8)&ir?doir@d6JcF4! JcF-tg]6I9]E%'ng]2p*df4mud/Vf"lMn?olMoQJcE4ZJcE.XJH56@JcE1Y JcE(VJH5BDJcE+WJcE%UJH5HFJcE(VJcDtSJH5TJJcE"TJcDnQJH,ZMJcDqRJcDkPJcLB%Y5a(Q X8dnSJcDhOJcD_LM?&5-WrIYMVuMbWJcD\KJcDSHOoU(5VZ25IU]6V[JcDPGJcDGDRK.p=UAofE TDtJ_JcDDCJcD;@U&]cET)XBARfB;dJcD5>JcD):XoO%QR/_a;PlJ)jJcD#8JcCl4\c@<]P5g+5 NrQlpJcCf2JcCW-a8gekMuSA.L&]R$JcCK)JcC<$s8UpUJcC<$!<7WMJcGECnc47@JcGHDJcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$ JcC<$g])j)Q2gLWJcC<$e,P"!Q2gLWJcFs6i;ei:JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6i;ei: JcD#8o`0RCkl9TAN;nJ/Q2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!G o`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'LBQ2gLWJcFs6q#H!Go`'mMoDnC\o`4jg blI54o`4R_i;iWPirJNIp&OU^p&OpgkQ$>:MuWDLoDeF_q>\S;o)J@_p&EkKp]'.Onc/:_nGi1^ q>]LUM>rJ5oDnRaoDn[da8kl4o`4^ch#R3Lh>m0Ip&OU^p&OpgiW+o:M?!2Jp]'jcp]&86p&F[b p]'"Kp]'"Kp&F^cnGi1^q>]CRN;n_6oDn^eoDnUb`W5`4o`4degAq!JgApsIp&OU^p&O.Qp&L*P L]?uHqu?9gp&E#3pAadcq#B(Kp]&qIp]'penGi1^iW&ZQNW4b5oDnjioDnO`p&Oabo`4^coDnXc o`4gfoDm_Io`4U`o)SRcp&OU^p&O%Np]-?SK`C]Fs8V]koDeLao`+Rap&F[bp]'mdq>^*fh#I$I nc/4]q>^-gnGi1^i;`QPNrOb3kQ(2Rp&Oabo`4Xap&Ojeo`4gfo`3eIo`4L]o`4gfp&OU^p&O%N p]-?SK)b*9nc/:_o`+Rao`+Ubp]'mdq>^*fh#I$In,N%\qZ$6hnGi1^iW&ZQNW4S0li?PTp&Oab o`4Xao`4deo`4gfo)RYIo`4I\o`4jgp&OU^p&O+PpAg3QJc>`Mmf;eUp&Oabo`4Xao`4deo`4gf hZ36Io`4F[p&Oshp&OU^p&Opgi;ei:JcGcMnGqtVp&Oabo`4Xao`4deo`4deh#R-Jo`4F[p&Osh p&OU^p&OpgiW+o:JcG`Lo)S.Wp&Oabo`4Xao`4deo`4adg]7*Ko`4F[p&Oshp&OU^p&OpgirFu: JcG`Lo)S.Wp&Oabo`4Xao`4deo`4^cg]7-Lo`4F[p&Oshp&OU^p&OpgjoC2:JcGcMnGqtVp&Oab o`4Xao`4deo`4Xah>m?No`4F[p&Oshp&OU^p&K[DjSsf2!<;Kfmf2t\o`+Rao`+Raq#C!emf2;I q>^*fn,N%\qZ$6hnGi1^JcFg2JcG*;n,N(]o`+Rao`+Raq#C!eh#I$Iq>^*fn,N%\qZ$6hnGi1^ JcFg2K)b-:nGi1^o`+Rao`+Raq#C!eg]-sIq>^*fn,N%\qZ$6hnGi1^JcFg2K`C38o)JC`o`+Ra o`+Raq#C!eg]-sIq>^*fnGi.]q>^-gnGi1^JcFg2L&^cFs8V]koDeLao`+Rao`+Raq#C!eg]-sI q>^*fo)J:]q>^*fnc/:_JcFg2LB$lGrVuKio`+Ubo`+Rao`+Raq#C!eh#I$Iq>^*fo`+I^p]'jc oDeLaJcFg2L]?uHqu?9gp&F^co`+Rao`+Raq#C!eq#B"Iq>].KpA`kIJcFg2M#[)Iq>^'epAagd o`+Rao`+Raq#C!eq#B%Jq#B(Ko`*\HJcFg2M?!2Jp]'jcp]'peo`+Rao`+Raq#C!eq#B(Kp]'"K o)IMGJcFg2MZ<;Kp&FXaq#C$fo`+Rao`+Raq#C!eq#B+LpA`tLn,M5EJcFg2MuWDLoDeF_q>^-g o`+Rao`+Raq#C!eq#B.Mp&EqMli5lCJcFg2N;rMMnc/4]qZ$6ho`+Rao`+Raq#C!eq#B7Po)IbN j8\0?JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j0.JcFg2JcC<$d/Wb=_>j3/JcFd1JcC<$ d/Wb=_Z09/JcFd1JcC<$d/Wb=`W,K/JcFd1JcC<$d/Wb=g]-(0JcFa0JcC<$d/Wb=g]-+1JcF^/ JcC<$d/Wb=g]-.2JcF[.JcC<$d/Wb=g]-44JcFU,JcC<$d/Wb=g]-:6JcFO*JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)JcC<$JcC<$g])j) JcC<$JcFL)JcC<$JcC<$g])j)JcC<$JcFL)~> Z ; 0 0 scol F0S22 Ji 0 66 M (I:\\NVO\\voql\\useCase1.xml)[9 9 9 25 23 26 9 17 18 18 7 9 19 17 18 25 18 17 18 19 9 16 27 0]xS 2918 66 M (0)S 2937 66 M (3)S 2956 66 M (/)S 2965 66 M (0)S 2984 66 M (5)S 3003 66 M (/)S 3012 66 M (0)S 3031 66 M (3)S 3050 66 M ( )S 3059 66 M (1)S 3078 66 M (1)S 3097 66 M (:)S 3106 66 M (5)S 3125 66 M (9)S 3144 66 M (:)S 3153 66 M (4)S 3172 66 M (7)S 0 2415 M (\2511998-2003 Altova GmbH http://www.xmlspy.com)[25 19 19 19 19 11 19 19 19 19 9 23 7 9 18 17 18 9 26 27 18 25 9 9 9 19 9 9 18 9 9 9 23 23 23 9 16 27 7 17 18 17 9 17 18 0]xS 3086 2415 M (P)S 3109 2415 M (a)S 3127 2415 M (g)S 3145 2415 M (e)S 3163 2415 M ( )S 3172 2415 M (3)S 1357 2415 M (Registered to Ed Shaya \(NASA\))[25 18 18 7 17 9 18 11 18 18 9 9 18 9 23 18 9 23 19 18 17 18 9 11 25 23 23 23 0]xS solid N 0 81 M 1463 81 I K N 3191 81 M 1725 81 I K N 0 2375 M 3191 2375 I K 0.754 0 scol 1 Lj 1 Lc solid : 0 154 4 1335 rc N 0 157 M 0 1485 I : 2.969 2.969 +S K ; ; : N 15 160 27 1313 rp C 0.91 0 scol L ; 1 0 scol : 12 160 7 1317 rc N 15 1473 M 15 -3906 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 15 1470 M 39 1470 I : 2.969 2.969 +S K ; : 36 160 7 1314 rc N 39 1470 M 39 -3906 I : 2.969 2.969 +S K ; ; : N 12 1473 33 3 rp C 0.91 0 scol L ; : N 12 160 3 1313 rp C 0.91 0 scol L ; : N 42 160 3 1313 rp C 0.91 0 scol L ; : N 3 160 9 1322 rp C 1 0 scol L ; : N 45 160 5 1322 rp C 1 0 scol L ; : N 3 1476 47 6 rp C 1 0 scol L ; 0.754 0 scol : 3 1479 50 6 rc N 3 1482 M 53 1482 I : 2.969 2.969 +S K ; ; : N 50 160 3 1322 rp C 1 0 scol L ; : N 53 160 173 54 rp C 1 0 scol L ; : N 53 214 173 3 rp C 1 0 scol L ; : 223 160 6 57 rc N 226 160 M 226 217 I : 2.969 2.969 +S K ; ; : N 241 160 26 1313 rp C 0.91 0 scol L ; 1 0 scol : 238 160 7 1317 rc N 241 1473 M 241 59 I : 2.969 2.969 +S K ; ; 0.496 0 scol N 241 1470 M 264 1470 I : 2.969 2.969 +S K ; : 261 160 7 1314 rc N 264 1470 M 264 59 I : 2.969 2.969 +S K ; ; : N 238 1473 32 3 rp C 0.91 0 scol L ; : N 238 160 3 1313 rp C 0.91 0 scol L ; : N 267 160 3 1313 rp C 0.91 0 scol L ; : N 229 160 9 1322 rp C 1 0 scol L ; : N 270 160 6 1322 rp C 1 0 scol L ; : N 229 1476 47 6 rp C 1 0 scol L ; 0.754 0 scol : 229 1479 50 6 rc N 229 1482 M 279 1482 I : 2.969 2.969 +S K ; ; : N 276 160 3 1322 rp C 1 0 scol L ; : N 279 160 377 54 rp C 1 0 scol L ; : N 279 214 377 3 rp C 1 0 scol L ; : 653 160 6 57 rc N 656 160 M 656 217 I : 2.969 2.969 +S K ; ; : N 659 160 48 54 rp C 1 0 scol L ; : 662 163 45 39 rc : 16 13 8 16 48 39 662 163 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 659 211 51 6 rc N 659 214 M 710 214 I : 2.969 2.969 +S K ; ; : N 707 160 3 54 rp C 1 0 scol L ; : N 710 160 113 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 713 199 M (name)[24 22 35 0]xS 0.754 0 scol : 710 211 116 6 rc N 710 214 M 826 214 I : 2.969 2.969 +S K ; ; : 820 160 6 57 rc N 823 160 M 823 217 I : 2.969 2.969 +S K ; ; : N 826 160 2337 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 829 198 M (Cluster Info)[28 9 22 19 11 22 13 11 11 22 12 0]xS 0.754 0 scol : 826 211 2340 6 rc N 826 214 M 3166 214 I : 2.969 2.969 +S K ; ; : 3160 160 6 57 rc N 3163 160 M 3163 217 I : 2.969 2.969 +S K ; ; : N 53 217 173 50 rp C 1 0 scol L ; : N 53 267 173 3 rp C 1 0 scol L ; : 223 217 6 53 rc N 226 217 M 226 270 I : 2.969 2.969 +S K ; ; : N 279 217 377 50 rp C 1 0 scol L ; : N 279 267 377 3 rp C 1 0 scol L ; : 653 217 6 53 rc N 656 217 M 656 270 I : 2.969 2.969 +S K ; ; : N 671 226 27 1247 rp C 0.91 0 scol L ; 1 0 scol N 671 1473 M 671 226 I : 2.969 2.969 +S K ; N 671 226 M 698 226 I : 2.969 2.969 +S K ; 0.496 0 scol N 671 1470 M 695 1470 I : 2.969 2.969 +S K ; N 695 1470 M 695 226 I : 2.969 2.969 +S K ; : N 668 223 33 3 rp C 0.91 0 scol L ; : N 668 1473 33 3 rp C 0.91 0 scol L ; : N 668 226 3 1247 rp C 0.91 0 scol L ; : N 698 226 3 1247 rp C 0.91 0 scol L ; : N 659 217 9 1265 rp C 1 0 scol L ; : N 701 217 6 1265 rp C 1 0 scol L ; : N 659 217 48 6 rp C 1 0 scol L ; : N 659 1476 48 6 rp C 1 0 scol L ; : N 683 235 M 683 238 I 680 238 I 680 241 I 677 241 I 677 244 I 674 244 I 674 247 I 695 247 I 695 244 I 692 244 I 692 241 I 689 241 I 689 238 I 686 238 I 686 235 I C eoclip : N 674 235 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 659 1479 51 6 rc N 659 1482 M 710 1482 I : 2.969 2.969 +S K ; ; : N 707 217 3 1265 rp C 1 0 scol L ; : N 710 217 2453 50 rp C 1 0 scol L ; 0 0 scol : 713 220 155 44 rc F2S26 Ji 713 256 M (for-each)[13 24 15 13 22 22 22 0]xS ; 0.754 0 scol : 817 264 2349 6 rc N 820 267 M 3166 267 I : 2.969 2.969 +S K ; ; : 3160 217 6 53 rc N 3163 217 M 3163 270 I : 2.969 2.969 +S K ; ; 1 0 scol : 710 264 117 6 rc N 710 267 M 823 267 I : 2.969 2.969 +S K ; ; : N 53 270 173 54 rp C L ; : N 53 324 173 3 rp C L ; 0.754 0 scol : 223 270 6 57 rc N 226 270 M 226 327 I : 2.969 2.969 +S K ; ; : N 279 270 377 54 rp C 1 0 scol L ; : N 279 324 377 3 rp C 1 0 scol L ; : 653 270 6 57 rc N 656 270 M 656 327 I : 2.969 2.969 +S K ; ; : N 710 270 113 54 rp C 1 0 scol L ; : N 710 324 113 3 rp C 1 0 scol L ; : 820 270 6 57 rc N 823 270 M 823 327 I : 2.969 2.969 +S K ; ; : N 826 270 47 54 rp C 1 0 scol L ; : 829 273 44 39 rc : 16 13 8 16 47 39 829 273 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 826 321 50 6 rc N 826 324 M 876 324 I : 2.969 2.969 +S K ; ; : N 873 270 3 54 rp C 1 0 scol L ; : N 876 270 122 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 879 309 M (object)[24 24 11 22 22 0]xS 0.754 0 scol : 876 321 125 6 rc N 876 324 M 1001 324 I : 2.969 2.969 +S K ; ; : 995 270 6 57 rc N 998 270 M 998 327 I : 2.969 2.969 +S K ; ; : N 1001 270 2162 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1004 308 M (@clusterName)[40 20 9 22 19 11 22 13 28 22 33 0]xS 0.754 0 scol : 1001 321 2165 6 rc N 1001 324 M 3166 324 I : 2.969 2.969 +S K ; ; : 3160 270 6 57 rc N 3163 270 M 3163 327 I : 2.969 2.969 +S K ; ; : N 53 327 173 50 rp C 1 0 scol L ; : N 53 377 173 3 rp C 1 0 scol L ; : 223 327 6 53 rc N 226 327 M 226 380 I : 2.969 2.969 +S K ; ; : N 279 327 377 50 rp C 1 0 scol L ; : N 279 377 377 3 rp C 1 0 scol L ; : 653 327 6 53 rc N 656 327 M 656 380 I : 2.969 2.969 +S K ; ; : N 710 327 113 50 rp C 1 0 scol L ; : N 710 377 113 3 rp C 1 0 scol L ; : 820 327 6 53 rc N 823 327 M 823 380 I : 2.969 2.969 +S K ; ; : N 838 336 26 525 rp C 0.91 0 scol L ; 1 0 scol N 838 861 M 838 336 I : 2.969 2.969 +S K ; N 838 336 M 864 336 I : 2.969 2.969 +S K ; 0.496 0 scol N 838 858 M 861 858 I : 2.969 2.969 +S K ; N 861 858 M 861 336 I : 2.969 2.969 +S K ; : N 835 333 32 3 rp C 0.91 0 scol L ; : N 835 861 32 3 rp C 0.91 0 scol L ; : N 835 336 3 525 rp C 0.91 0 scol L ; : N 864 336 3 525 rp C 0.91 0 scol L ; : N 826 327 9 543 rp C 1 0 scol L ; : N 867 327 6 543 rp C 1 0 scol L ; : N 826 327 47 6 rp C 1 0 scol L ; : N 826 864 47 6 rp C 1 0 scol L ; : N 850 345 M 850 348 I 847 348 I 847 351 I 844 351 I 844 353 I 841 353 I 841 356 I 861 356 I 861 353 I 858 353 I 858 351 I 855 351 I 855 348 I 853 348 I 853 345 I C eoclip : N 841 345 20 11 rp C 0 0 scol L ; ; 0.754 0 scol : 826 867 50 6 rc N 826 870 M 876 870 I : 2.969 2.969 +S K ; ; : N 873 327 3 543 rp C 1 0 scol L ; : N 876 327 2287 50 rp C 1 0 scol L ; 0 0 scol : 879 330 81 44 rc F2S26 Ji 879 366 M (field)[13 11 22 11 0]xS ; 0.5 0 scol 959 365 M ( \(5\))[11 13 22 0]xS 0.754 0 scol : 894 374 2272 6 rc N 897 377 M 3166 377 I : 2.969 2.969 +S K ; ; : 3160 327 6 53 rc N 3163 327 M 3163 380 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 374 28 6 rc N 876 377 M 900 377 I : 2.969 2.969 +S K ; ; : N 53 380 173 51 rp C L ; : N 53 431 173 3 rp C L ; 0.754 0 scol : 223 380 6 54 rc N 226 380 M 226 434 I : 2.969 2.969 +S K ; ; : N 279 380 377 51 rp C 1 0 scol L ; : N 279 431 377 3 rp C 1 0 scol L ; : 653 380 6 54 rc N 656 380 M 656 434 I : 2.969 2.969 +S K ; ; : N 710 380 113 51 rp C 1 0 scol L ; : N 710 431 113 3 rp C 1 0 scol L ; : 820 380 6 54 rc N 823 380 M 823 434 I : 2.969 2.969 +S K ; ; : N 900 380 98 51 rp C 0.973 0 scol L ; : N 876 380 24 51 rp C 1 0 scol L ; : 897 380 7 51 rc N 900 380 M 900 431 I : 2.969 2.969 +S K ; ; : 894 428 107 6 rc N 897 431 M 1001 431 I : 2.969 2.969 +S K ; ; : 995 380 6 54 rc N 998 380 M 998 434 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 428 28 6 rc N 876 431 M 900 431 I : 2.969 2.969 +S K ; ; : N 1001 380 48 51 rp C 0.973 0 scol L ; : 1004 383 45 39 rc : 16 13 8 16 47 39 1004 383 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; : 16 13 8 16 47 39 1004 383 F F 3 [ 0 ] F X doNimage nbDYLnbDYLrqQ=:qtU0cqBc3Xr:p6cqS<%(nbE+YqBl+7rqQ=:!5SO-rV66)r:ogWnb<~> Z ; ; 0.754 0 scol : 1001 428 50 6 rc N 1001 431 M 1052 431 I : 2.969 2.969 +S K ; ; : N 1049 380 2 51 rp C 0.973 0 scol L ; : N 1051 380 295 51 rp C 0.973 0 scol L ; 0 0 scol F2S26 Ji 1054 419 M (name)[24 22 35 0]xS 0.754 0 scol : 1051 428 298 6 rc N 1052 431 M 1349 431 I : 2.969 2.969 +S K ; ; : 1343 380 6 54 rc N 1346 380 M 1346 434 I : 2.969 2.969 +S K ; ; : N 1349 380 47 51 rp C 0.973 0 scol L ; : 1351 383 45 39 rc : 16 13 8 16 48 39 1351 383 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; : 16 13 8 16 48 39 1351 383 F F 3 [ 0 ] F X doNimage nbDYLnbDYLrqQ=:qtU0cqBc3Xr:p6cqS<%(nbE+YqBl+7rqQ=:!5SO-rV66)r:ogWnb<~> Z ; ; : 1349 428 50 6 rc N 1349 431 M 1399 431 I : 2.969 2.969 +S K ; ; : N 1396 380 3 51 rp C 0.973 0 scol L ; : N 1399 380 181 51 rp C 0.973 0 scol L ; 0 0 scol 1402 419 M (units)[24 24 11 13 0]xS 0.754 0 scol : 1399 428 184 6 rc N 1399 431 M 1583 431 I : 2.969 2.969 +S K ; ; : 1577 380 6 54 rc N 1580 380 M 1580 434 I : 2.969 2.969 +S K ; ; : N 1583 380 48 51 rp C 0.973 0 scol L ; : 1586 383 45 39 rc : 16 13 8 16 48 39 1586 383 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; : 16 13 8 16 48 39 1586 383 F F 3 [ 0 ] F X doNimage nbDYLnbE.Zru;"5!#t_.#P]85^`3%f_"ma/p`%$D)o2FlrqQL4s7cThr>PdQ)um\U)u(BIs1eX0 !VdW6^^(mp)o24f^`1)gp^Hp:_"\ka)o24f^`1)gp]^F3_"\karYkq6_"dpKs7lWh!5SX0!PnL0 _#F-/^]=0"q!n+~> Z ; ; : 1583 428 51 6 rc N 1583 431 M 1634 431 I : 2.969 2.969 +S K ; ; : N 1631 380 3 51 rp C 0.973 0 scol L ; : N 1634 380 211 51 rp C 0.973 0 scol L ; 0 0 scol F1S26 Ji 1637 419 M (Text)[24 22 20 0]xS 0.754 0 scol : 1634 428 214 6 rc N 1634 431 M 1848 431 I : 2.969 2.969 +S K ; ; : 1842 380 6 54 rc N 1845 380 M 1845 434 I : 2.969 2.969 +S K ; ; : N 1848 380 47 51 rp C 0.973 0 scol L ; : 1850 383 45 39 rc : 16 13 8 16 48 39 1850 383 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; : 16 13 8 16 48 39 1850 383 F F 3 [ 0 ] F X doNimage nbE+Y!5SU]s7lU@!5SO-rqQL?s1e[1_#GbZq#C*h_#G_]_#F-/-31j[q#C-h-NCm\p]/,0-N3]? pqZnV!5SO-s!@`]rqHKgs!Ic]r:g9-s!Ia?!VjJ1-N!T<-NCm]q#C-h-31jZq#;Z@_#F-/p]/,0 -N3]?^aB)srqQKfs!@`]rqQL?!5SR.rqHK/s!Id@s!Ic]rV6 Z ; ; : 1848 428 50 6 rc N 1848 431 M 1898 431 I : 2.969 2.969 +S K ; ; : N 1895 380 3 51 rp C 0.973 0 scol L ; : N 1898 380 1144 51 rp C 0.973 0 scol L ; 0 0 scol F2S26 Ji 1901 419 M (math)[35 22 13 0]xS 0.754 0 scol : 1898 428 1147 6 rc N 1898 431 M 3045 431 I : 2.969 2.969 +S K ; ; : 3039 380 6 54 rc N 3042 380 M 3042 434 I : 2.969 2.969 +S K ; ; : N 3045 380 47 51 rp C 1 0 scol L ; : N 3045 431 50 3 rp C 1 0 scol L ; : N 3092 380 3 51 rp C 1 0 scol L ; : N 3095 380 68 51 rp C 1 0 scol L ; : N 3095 431 68 3 rp C 1 0 scol L ; : 3160 380 6 54 rc N 3163 380 M 3163 434 I : 2.969 2.969 +S K ; ; : N 53 434 173 53 rp C 1 0 scol L ; : N 53 487 173 3 rp C 1 0 scol L ; : 223 434 6 56 rc N 226 434 M 226 490 I : 2.969 2.969 +S K ; ; : N 279 434 377 53 rp C 1 0 scol L ; : N 279 487 377 3 rp C 1 0 scol L ; : 653 434 6 56 rc N 656 434 M 656 490 I : 2.969 2.969 +S K ; ; : N 710 434 113 53 rp C 1 0 scol L ; : N 710 487 113 3 rp C 1 0 scol L ; : 820 434 6 56 rc N 823 434 M 823 490 I : 2.969 2.969 +S K ; ; : N 900 434 98 53 rp C 0.973 0 scol L ; : N 876 434 24 53 rp C 1 0 scol L ; : 897 434 7 53 rc N 900 434 M 900 487 I : 2.969 2.969 +S K ; ; 0 0 scol 962 473 M (1 )[22 0]xS 0.754 0 scol : 894 484 107 6 rc N 897 487 M 1001 487 I : 2.969 2.969 +S K ; ; : 995 434 6 56 rc N 998 434 M 998 490 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 484 28 6 rc N 876 487 M 900 487 I : 2.969 2.969 +S K ; ; : N 1001 434 345 53 rp C L ; 0 0 scol F0S26 Ji 1004 472 M (clusterName)[20 9 22 19 11 22 13 28 22 33 0]xS 0.754 0 scol : 1001 484 348 6 rc N 1001 487 M 1349 487 I : 2.969 2.969 +S K ; ; : 1343 434 6 56 rc N 1346 434 M 1346 490 I : 2.969 2.969 +S K ; ; : N 1349 434 231 53 rp C 1 0 scol L ; 0 0 scol 1352 472 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1349 484 234 6 rc N 1349 487 M 1583 487 I : 2.969 2.969 +S K ; ; : 1577 434 6 56 rc N 1580 434 M 1580 490 I : 2.969 2.969 +S K ; ; : N 1583 434 262 53 rp C 1 0 scol L ; 0 0 scol 1586 472 M (@clusterNa...)[40 20 9 22 19 11 22 13 28 22 11 11 0]xS 0.754 0 scol : 1583 484 265 6 rc N 1583 487 M 1848 487 I : 2.969 2.969 +S K ; ; : 1842 434 6 56 rc N 1845 434 M 1845 490 I : 2.969 2.969 +S K ; ; : N 1848 434 1194 53 rp C 1 0 scol L ; : 1848 484 1197 6 rc N 1848 487 M 3045 487 I : 2.969 2.969 +S K ; ; : 3039 434 6 56 rc N 3042 434 M 3042 490 I : 2.969 2.969 +S K ; ; : N 3045 434 47 53 rp C 1 0 scol L ; : N 3045 487 50 3 rp C 1 0 scol L ; : N 3092 434 3 53 rp C 1 0 scol L ; : N 3095 434 68 53 rp C 1 0 scol L ; : N 3095 487 68 3 rp C 1 0 scol L ; : 3160 434 6 56 rc N 3163 434 M 3163 490 I : 2.969 2.969 +S K ; ; : N 53 490 173 54 rp C 1 0 scol L ; : N 53 544 173 3 rp C 1 0 scol L ; : 223 490 6 57 rc N 226 490 M 226 547 I : 2.969 2.969 +S K ; ; : N 279 490 377 54 rp C 1 0 scol L ; : N 279 544 377 3 rp C 1 0 scol L ; : 653 490 6 57 rc N 656 490 M 656 547 I : 2.969 2.969 +S K ; ; : N 710 490 113 54 rp C 1 0 scol L ; : N 710 544 113 3 rp C 1 0 scol L ; : 820 490 6 57 rc N 823 490 M 823 547 I : 2.969 2.969 +S K ; ; : N 900 490 98 54 rp C 0.973 0 scol L ; : N 876 490 24 54 rp C 1 0 scol L ; : 897 490 7 54 rc N 900 490 M 900 544 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 962 529 M (2 )[22 0]xS 0.754 0 scol : 894 541 107 6 rc N 897 544 M 1001 544 I : 2.969 2.969 +S K ; ; : 995 490 6 57 rc N 998 490 M 998 547 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 541 28 6 rc N 876 544 M 900 544 I : 2.969 2.969 +S K ; ; : N 1001 490 345 54 rp C L ; 0 0 scol F0S26 Ji 1004 528 M (clusterXray)[20 9 22 19 11 22 13 25 13 22 0]xS 0.754 0 scol : 1001 541 348 6 rc N 1001 544 M 1349 544 I : 2.969 2.969 +S K ; ; : 1343 490 6 57 rc N 1346 490 M 1346 547 I : 2.969 2.969 +S K ; ; : N 1349 490 231 54 rp C 1 0 scol L ; 0 0 scol 1352 528 M (Jansky)[20 22 22 19 20 0]xS 0.754 0 scol : 1349 541 234 6 rc N 1349 544 M 1583 544 I : 2.969 2.969 +S K ; ; : 1577 490 6 57 rc N 1580 490 M 1580 547 I : 2.969 2.969 +S K ; ; : N 1583 490 262 54 rp C 1 0 scol L ; 0 0 scol 1586 528 M (@clusterXray)[40 20 9 22 19 11 22 13 25 13 22 0]xS 0.754 0 scol : 1583 541 265 6 rc N 1583 544 M 1848 544 I : 2.969 2.969 +S K ; ; : 1842 490 6 57 rc N 1845 490 M 1845 547 I : 2.969 2.969 +S K ; ; : N 1848 490 1194 54 rp C 1 0 scol L ; : 1848 541 1197 6 rc N 1848 544 M 3045 544 I : 2.969 2.969 +S K ; ; : 3039 490 6 57 rc N 3042 490 M 3042 547 I : 2.969 2.969 +S K ; ; : N 3045 490 47 54 rp C 1 0 scol L ; : N 3045 544 50 3 rp C 1 0 scol L ; : N 3092 490 3 54 rp C 1 0 scol L ; : N 3095 490 68 54 rp C 1 0 scol L ; : N 3095 544 68 3 rp C 1 0 scol L ; : 3160 490 6 57 rc N 3163 490 M 3163 547 I : 2.969 2.969 +S K ; ; : N 53 547 173 53 rp C 1 0 scol L ; : N 53 600 173 3 rp C 1 0 scol L ; : 223 547 6 56 rc N 226 547 M 226 603 I : 2.969 2.969 +S K ; ; : N 279 547 377 53 rp C 1 0 scol L ; : N 279 600 377 3 rp C 1 0 scol L ; : 653 547 6 56 rc N 656 547 M 656 603 I : 2.969 2.969 +S K ; ; : N 710 547 113 53 rp C 1 0 scol L ; : N 710 600 113 3 rp C 1 0 scol L ; : 820 547 6 56 rc N 823 547 M 823 603 I : 2.969 2.969 +S K ; ; : N 900 547 98 53 rp C 0.973 0 scol L ; : N 876 547 24 53 rp C 1 0 scol L ; : 897 547 7 53 rc N 900 547 M 900 600 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 962 586 M (3 )[22 0]xS 0.754 0 scol : 894 597 107 6 rc N 897 600 M 1001 600 I : 2.969 2.969 +S K ; ; : 995 547 6 56 rc N 998 547 M 998 603 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 597 28 6 rc N 876 600 M 900 600 I : 2.969 2.969 +S K ; ; : N 1001 547 345 53 rp C L ; 0 0 scol F0S26 Ji 1004 585 M (image)[9 33 22 22 0]xS 0.754 0 scol : 1001 597 348 6 rc N 1001 600 M 1349 600 I : 2.969 2.969 +S K ; ; : 1343 547 6 56 rc N 1346 547 M 1346 603 I : 2.969 2.969 +S K ; ; : N 1349 547 231 53 rp C 1 0 scol L ; 0 0 scol 1352 585 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1349 597 234 6 rc N 1349 600 M 1583 600 I : 2.969 2.969 +S K ; ; : 1577 547 6 56 rc N 1580 547 M 1580 603 I : 2.969 2.969 +S K ; ; : N 1583 547 262 53 rp C 1 0 scol L ; 0 0 scol 1586 585 M (@image)[40 9 33 22 22 0]xS 0.754 0 scol : 1583 597 265 6 rc N 1583 600 M 1848 600 I : 2.969 2.969 +S K ; ; : 1842 547 6 56 rc N 1845 547 M 1845 603 I : 2.969 2.969 +S K ; ; : N 1848 547 1194 53 rp C 1 0 scol L ; : 1848 597 1197 6 rc N 1848 600 M 3045 600 I : 2.969 2.969 +S K ; ; : 3039 547 6 56 rc N 3042 547 M 3042 603 I : 2.969 2.969 +S K ; ; : N 3045 547 47 53 rp C 1 0 scol L ; : N 3045 600 50 3 rp C 1 0 scol L ; : N 3092 547 3 53 rp C 1 0 scol L ; : N 3095 547 68 53 rp C 1 0 scol L ; : N 3095 600 68 3 rp C 1 0 scol L ; : 3160 547 6 56 rc N 3163 547 M 3163 603 I : 2.969 2.969 +S K ; ; : N 53 603 173 53 rp C 1 0 scol L ; : N 53 656 173 3 rp C 1 0 scol L ; : 223 603 6 56 rc N 226 603 M 226 659 I : 2.969 2.969 +S K ; ; : N 279 603 377 53 rp C 1 0 scol L ; : N 279 656 377 3 rp C 1 0 scol L ; : 653 603 6 56 rc N 656 603 M 656 659 I : 2.969 2.969 +S K ; ; : N 710 603 113 53 rp C 1 0 scol L ; : N 710 656 113 3 rp C 1 0 scol L ; : 820 603 6 56 rc N 823 603 M 823 659 I : 2.969 2.969 +S K ; ; : N 900 603 98 53 rp C 0.973 0 scol L ; : N 876 603 24 53 rp C 1 0 scol L ; : 897 603 7 53 rc N 900 603 M 900 656 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 962 642 M (4 )[22 0]xS 0.754 0 scol : 894 653 107 6 rc N 897 656 M 1001 656 I : 2.969 2.969 +S K ; ; : 995 603 6 56 rc N 998 603 M 998 659 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 653 28 6 rc N 876 656 M 900 656 I : 2.969 2.969 +S K ; ; : N 1001 603 345 53 rp C L ; 0 0 scol F0S26 Ji 1004 641 M (redshift)[13 22 22 19 22 9 12 0]xS 0.754 0 scol : 1001 653 348 6 rc N 1001 656 M 1349 656 I : 2.969 2.969 +S K ; ; : 1343 603 6 56 rc N 1346 603 M 1346 659 I : 2.969 2.969 +S K ; ; : N 1349 603 231 53 rp C 1 0 scol L ; 0 0 scol 1352 641 M (@czunits)[40 20 19 22 22 9 11 0]xS 0.754 0 scol : 1349 653 234 6 rc N 1349 656 M 1583 656 I : 2.969 2.969 +S K ; ; : 1577 603 6 56 rc N 1580 603 M 1580 659 I : 2.969 2.969 +S K ; ; : N 1583 603 262 53 rp C 1 0 scol L ; 0 0 scol 1586 641 M (@cz)[40 20 0]xS 0.754 0 scol : 1583 653 265 6 rc N 1583 656 M 1848 656 I : 2.969 2.969 +S K ; ; : 1842 603 6 56 rc N 1845 603 M 1845 659 I : 2.969 2.969 +S K ; ; : N 1848 603 1194 53 rp C 1 0 scol L ; : 1848 653 1197 6 rc N 1848 656 M 3045 656 I : 2.969 2.969 +S K ; ; : 3039 603 6 56 rc N 3042 603 M 3042 659 I : 2.969 2.969 +S K ; ; : N 3045 603 47 53 rp C 1 0 scol L ; : N 3045 656 50 3 rp C 1 0 scol L ; : N 3092 603 3 53 rp C 1 0 scol L ; : N 3095 603 68 53 rp C 1 0 scol L ; : N 3095 656 68 3 rp C 1 0 scol L ; : 3160 603 6 56 rc N 3163 603 M 3163 659 I : 2.969 2.969 +S K ; ; : N 53 659 173 54 rp C 1 0 scol L ; : N 53 713 173 3 rp C 1 0 scol L ; : 223 659 6 57 rc N 226 659 M 226 716 I : 2.969 2.969 +S K ; ; : N 279 659 377 54 rp C 1 0 scol L ; : N 279 713 377 3 rp C 1 0 scol L ; : 653 659 6 57 rc N 656 659 M 656 716 I : 2.969 2.969 +S K ; ; : N 710 659 113 54 rp C 1 0 scol L ; : N 710 713 113 3 rp C 1 0 scol L ; : 820 659 6 57 rc N 823 659 M 823 716 I : 2.969 2.969 +S K ; ; : N 900 659 98 211 rp C 0.973 0 scol L ; : N 876 659 24 211 rp C 1 0 scol L ; : 897 659 7 211 rc N 900 659 M 900 870 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 962 698 M (5 )[22 0]xS 0.754 0 scol : 876 867 125 6 rc N 876 870 M 1001 870 I : 2.969 2.969 +S K ; ; : 995 659 6 214 rc N 998 659 M 998 873 I : 2.969 2.969 +S K ; ; : N 1001 659 345 54 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1004 697 M (Number of Galaxi...)[28 22 33 22 22 13 11 22 12 11 30 22 9 22 18 9 11 11 0]xS 0.754 0 scol : 1340 710 9 6 rc N 1343 713 M 1349 713 I : 2.969 2.969 +S K ; ; : 1343 659 6 57 rc N 1346 659 M 1346 716 I : 2.969 2.969 +S K ; ; 1 0 scol : 1001 710 348 6 rc N 1001 713 M 1346 713 I : 2.969 2.969 +S K ; ; : N 1349 659 231 54 rp C L ; 0 0 scol 1352 697 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1574 710 9 6 rc N 1577 713 M 1583 713 I : 2.969 2.969 +S K ; ; : 1577 659 6 57 rc N 1580 659 M 1580 716 I : 2.969 2.969 +S K ; ; 1 0 scol : 1349 710 234 6 rc N 1349 713 M 1580 713 I : 2.969 2.969 +S K ; ; : N 1583 659 262 54 rp C L ; 0.754 0 scol : 1839 710 9 6 rc N 1842 713 M 1848 713 I : 2.969 2.969 +S K ; ; : 1842 659 6 57 rc N 1845 659 M 1845 716 I : 2.969 2.969 +S K ; ; 1 0 scol : 1583 710 265 6 rc N 1583 713 M 1845 713 I : 2.969 2.969 +S K ; ; : N 1859 668 27 193 rp C 0.91 0 scol L ; N 1859 861 M 1859 668 I : 2.969 2.969 +S K ; N 1859 668 M 1886 668 I : 2.969 2.969 +S K ; 0.496 0 scol N 1859 858 M 1883 858 I : 2.969 2.969 +S K ; N 1883 858 M 1883 668 I : 2.969 2.969 +S K ; : N 1856 665 33 3 rp C 0.91 0 scol L ; : N 1856 861 33 3 rp C 0.91 0 scol L ; : N 1856 668 3 193 rp C 0.91 0 scol L ; : N 1886 668 3 193 rp C 0.91 0 scol L ; : N 1848 659 8 211 rp C 1 0 scol L ; : N 1889 659 6 211 rp C 1 0 scol L ; : N 1848 659 47 6 rp C 1 0 scol L ; : N 1848 864 47 6 rp C 1 0 scol L ; : N 1871 677 M 1871 680 I 1868 680 I 1868 683 I 1865 683 I 1865 686 I 1862 686 I 1862 689 I 1883 689 I 1883 686 I 1880 686 I 1880 683 I 1877 683 I 1877 680 I 1874 680 I 1874 677 I C eoclip : N 1862 677 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1848 867 50 6 rc N 1848 870 M 1898 870 I : 2.969 2.969 +S K ; ; : N 1895 659 3 211 rp C 1 0 scol L ; : N 1898 659 1144 54 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1901 698 M (math)[35 22 13 0]xS 0.754 0 scol : 2100 710 945 6 rc N 2103 713 M 3045 713 I : 2.969 2.969 +S K ; ; : 3039 659 6 57 rc N 3042 659 M 3042 716 I : 2.969 2.969 +S K ; ; 1 0 scol : 1898 710 212 6 rc N 1898 713 M 2106 713 I : 2.969 2.969 +S K ; ; : N 3045 659 47 54 rp C L ; : N 3045 713 50 3 rp C L ; : N 3092 659 3 54 rp C L ; : N 3095 659 68 54 rp C L ; : N 3095 713 68 3 rp C L ; 0.754 0 scol : 3160 659 6 57 rc N 3163 659 M 3163 716 I : 2.969 2.969 +S K ; ; : N 53 716 173 50 rp C 1 0 scol L ; : N 53 766 173 3 rp C 1 0 scol L ; : 223 716 6 53 rc N 226 716 M 226 769 I : 2.969 2.969 +S K ; ; : N 279 716 377 50 rp C 1 0 scol L ; : N 279 766 377 3 rp C 1 0 scol L ; : 653 716 6 53 rc N 656 716 M 656 769 I : 2.969 2.969 +S K ; ; : N 710 716 113 50 rp C 1 0 scol L ; : N 710 766 113 3 rp C 1 0 scol L ; : 820 716 6 53 rc N 823 716 M 823 769 I : 2.969 2.969 +S K ; ; : N 1001 716 48 50 rp C 1 0 scol L ; : N 1001 766 50 3 rp C 1 0 scol L ; : N 1049 716 2 50 rp C 1 0 scol L ; : N 1051 716 295 50 rp C 1 0 scol L ; : N 1051 766 295 3 rp C 1 0 scol L ; : 1343 716 6 53 rc N 1346 716 M 1346 769 I : 2.969 2.969 +S K ; ; : N 1349 716 47 50 rp C 1 0 scol L ; : N 1349 766 50 3 rp C 1 0 scol L ; : N 1396 716 3 50 rp C 1 0 scol L ; : N 1399 716 181 50 rp C 1 0 scol L ; : N 1399 766 181 3 rp C 1 0 scol L ; : 1577 716 6 53 rc N 1580 716 M 1580 769 I : 2.969 2.969 +S K ; ; : N 1583 716 48 50 rp C 1 0 scol L ; : N 1583 766 51 3 rp C 1 0 scol L ; : N 1631 716 3 50 rp C 1 0 scol L ; : N 1634 716 211 50 rp C 1 0 scol L ; : N 1634 766 211 3 rp C 1 0 scol L ; : 1842 716 6 53 rc N 1845 716 M 1845 769 I : 2.969 2.969 +S K ; ; : N 1898 716 208 50 rp C 1 0 scol L ; : N 1898 766 208 3 rp C 1 0 scol L ; : 2103 716 6 53 rc N 2106 716 M 2106 769 I : 2.969 2.969 +S K ; ; : N 2121 725 27 136 rp C 0.91 0 scol L ; 1 0 scol N 2121 861 M 2121 725 I : 2.969 2.969 +S K ; N 2121 725 M 2148 725 I : 2.969 2.969 +S K ; 0.496 0 scol N 2121 858 M 2145 858 I : 2.969 2.969 +S K ; N 2145 858 M 2145 725 I : 2.969 2.969 +S K ; : N 2118 722 32 3 rp C 0.91 0 scol L ; : N 2118 861 32 3 rp C 0.91 0 scol L ; : N 2118 725 3 136 rp C 0.91 0 scol L ; : N 2148 725 2 136 rp C 0.91 0 scol L ; : N 2109 716 9 154 rp C 1 0 scol L ; : N 2150 716 6 154 rp C 1 0 scol L ; : N 2109 716 47 6 rp C 1 0 scol L ; : N 2109 864 47 6 rp C 1 0 scol L ; : N 2133 734 M 2133 737 I 2130 737 I 2130 740 I 2127 740 I 2127 743 I 2124 743 I 2124 746 I 2145 746 I 2145 743 I 2142 743 I 2142 740 I 2139 740 I 2139 737 I 2136 737 I 2136 734 I C eoclip : N 2124 734 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 2109 867 50 6 rc N 2109 870 M 2159 870 I : 2.969 2.969 +S K ; ; : N 2156 716 3 154 rp C 1 0 scol L ; : N 2159 716 883 50 rp C 1 0 scol L ; 0 0 scol : 2162 719 102 44 rc 2162 755 M (apply)[22 24 24 11 0]xS ; 0.754 0 scol : 2471 763 574 6 rc N 2474 766 M 3045 766 I : 2.969 2.969 +S K ; ; : 3039 716 6 53 rc N 3042 716 M 3042 769 I : 2.969 2.969 +S K ; ; 1 0 scol : 2159 763 322 6 rc N 2159 766 M 2477 766 I : 2.969 2.969 +S K ; ; : N 3045 716 47 50 rp C L ; : N 3045 766 50 3 rp C L ; : N 3092 716 3 50 rp C L ; : N 3095 716 68 50 rp C L ; : N 3095 766 68 3 rp C L ; 0.754 0 scol : 3160 716 6 53 rc N 3163 716 M 3163 769 I : 2.969 2.969 +S K ; ; : N 53 769 173 101 rp C 1 0 scol L ; : N 53 870 173 3 rp C 1 0 scol L ; : 223 769 6 104 rc N 226 769 M 226 873 I : 2.969 2.969 +S K ; ; : N 279 769 377 101 rp C 1 0 scol L ; : N 279 870 377 3 rp C 1 0 scol L ; : 653 769 6 104 rc N 656 769 M 656 873 I : 2.969 2.969 +S K ; ; : N 710 769 113 101 rp C 1 0 scol L ; : N 710 870 113 3 rp C 1 0 scol L ; : 820 769 6 104 rc N 823 769 M 823 873 I : 2.969 2.969 +S K ; ; : N 1001 769 48 101 rp C 1 0 scol L ; : 1001 867 50 6 rc N 1001 870 M 1052 870 I : 2.969 2.969 +S K ; ; : N 1049 769 2 101 rp C 1 0 scol L ; : N 1051 769 295 101 rp C 1 0 scol L ; : 1051 867 298 6 rc N 1052 870 M 1349 870 I : 2.969 2.969 +S K ; ; : 1343 769 6 104 rc N 1346 769 M 1346 873 I : 2.969 2.969 +S K ; ; : N 1349 769 47 101 rp C 1 0 scol L ; : 1349 867 50 6 rc N 1349 870 M 1399 870 I : 2.969 2.969 +S K ; ; : N 1396 769 3 101 rp C 1 0 scol L ; : N 1399 769 181 101 rp C 1 0 scol L ; : 1399 867 184 6 rc N 1399 870 M 1583 870 I : 2.969 2.969 +S K ; ; : 1577 769 6 104 rc N 1580 769 M 1580 873 I : 2.969 2.969 +S K ; ; : N 1583 769 48 101 rp C 1 0 scol L ; : 1583 867 51 6 rc N 1583 870 M 1634 870 I : 2.969 2.969 +S K ; ; : N 1631 769 3 101 rp C 1 0 scol L ; : N 1634 769 211 101 rp C 1 0 scol L ; : 1634 867 214 6 rc N 1634 870 M 1848 870 I : 2.969 2.969 +S K ; ; : 1842 769 6 104 rc N 1845 769 M 1845 873 I : 2.969 2.969 +S K ; ; : N 1898 769 208 101 rp C 1 0 scol L ; : 1898 867 211 6 rc N 1898 870 M 2109 870 I : 2.969 2.969 +S K ; ; : 2103 769 6 104 rc N 2106 769 M 2106 873 I : 2.969 2.969 +S K ; ; : N 2159 769 318 101 rp C 1 0 scol L ; : 2159 867 321 6 rc N 2159 870 M 2480 870 I : 2.969 2.969 +S K ; ; : 2474 769 6 104 rc N 2477 769 M 2477 873 I : 2.969 2.969 +S K ; ; : N 2480 769 48 101 rp C 1 0 scol L ; : 2483 772 45 39 rc : 16 13 8 16 48 39 2483 772 F F 3 [ 0 ] F X doNimage nc/Ug!5SU]s8W*G!5SO4rr Z ; ; : 2480 867 51 6 rc N 2480 870 M 2531 870 I : 2.969 2.969 +S K ; ; : N 2528 769 3 101 rp C 1 0 scol L ; : N 2531 769 258 101 rp C 1 0 scol L ; 0 0 scol F3S26 Ji 2534 807 M (ql:)[24 10 0]xS F2S26 Ji 2581 808 M (numberOf)[24 24 35 24 22 15 30 0]xS 0.754 0 scol : 2531 867 261 6 rc N 2531 870 M 2792 870 I : 2.969 2.969 +S K ; ; : 2786 769 6 104 rc N 2789 769 M 2789 873 I : 2.969 2.969 +S K ; ; : N 2792 769 250 101 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 2795 807 M (@galaxyNam)[40 22 22 9 22 18 19 28 22 0]xS 2795 852 M (e)S 0.754 0 scol : 2792 867 253 6 rc N 2792 870 M 3045 870 I : 2.969 2.969 +S K ; ; : 3039 769 6 104 rc N 3042 769 M 3042 873 I : 2.969 2.969 +S K ; ; : N 3045 769 47 101 rp C 1 0 scol L ; : 3045 867 50 6 rc N 3045 870 M 3095 870 I : 2.969 2.969 +S K ; ; : N 3092 769 3 101 rp C 1 0 scol L ; : N 3095 769 68 101 rp C 1 0 scol L ; : 3095 867 71 6 rc N 3095 870 M 3166 870 I : 2.969 2.969 +S K ; ; : 3160 769 6 104 rc N 3163 769 M 3163 873 I : 2.969 2.969 +S K ; ; : N 53 873 173 51 rp C 1 0 scol L ; : N 53 924 173 3 rp C 1 0 scol L ; : 223 873 6 54 rc N 226 873 M 226 927 I : 2.969 2.969 +S K ; ; : N 279 873 377 51 rp C 1 0 scol L ; : N 279 924 377 3 rp C 1 0 scol L ; : 653 873 6 54 rc N 656 873 M 656 927 I : 2.969 2.969 +S K ; ; : N 710 873 113 51 rp C 1 0 scol L ; : N 710 924 113 3 rp C 1 0 scol L ; : 820 873 6 54 rc N 823 873 M 823 927 I : 2.969 2.969 +S K ; ; : N 838 882 26 591 rp C 0.91 0 scol L ; 1 0 scol N 838 1473 M 838 882 I : 2.969 2.969 +S K ; N 838 882 M 864 882 I : 2.969 2.969 +S K ; 0.496 0 scol N 838 1470 M 861 1470 I : 2.969 2.969 +S K ; N 861 1470 M 861 882 I : 2.969 2.969 +S K ; : N 835 879 32 3 rp C 0.91 0 scol L ; : N 835 1473 32 3 rp C 0.91 0 scol L ; : N 835 882 3 591 rp C 0.91 0 scol L ; : N 864 882 3 591 rp C 0.91 0 scol L ; : N 826 873 9 609 rp C 1 0 scol L ; : N 867 873 6 609 rp C 1 0 scol L ; : N 826 873 47 6 rp C 1 0 scol L ; : N 826 1476 47 6 rp C 1 0 scol L ; : N 850 891 M 850 894 I 847 894 I 847 897 I 844 897 I 844 900 I 841 900 I 841 903 I 861 903 I 861 900 I 858 900 I 858 897 I 855 897 I 855 894 I 853 894 I 853 891 I C eoclip : N 841 891 20 12 rp C 0 0 scol L ; ; 0.754 0 scol : 826 1479 50 6 rc N 826 1482 M 876 1482 I : 2.969 2.969 +S K ; ; : N 873 873 3 609 rp C 1 0 scol L ; : N 876 873 2287 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 879 912 M (for-each)[13 24 15 13 22 22 22 0]xS 0.754 0 scol : 992 921 2174 6 rc N 995 924 M 3166 924 I : 2.969 2.969 +S K ; ; : 3160 873 6 54 rc N 3163 873 M 3163 927 I : 2.969 2.969 +S K ; ; 1 0 scol : 876 921 126 6 rc N 876 924 M 998 924 I : 2.969 2.969 +S K ; ; : N 53 927 173 53 rp C L ; : N 53 980 173 3 rp C L ; 0.754 0 scol : 223 927 6 56 rc N 226 927 M 226 983 I : 2.969 2.969 +S K ; ; : N 279 927 377 53 rp C 1 0 scol L ; : N 279 980 377 3 rp C 1 0 scol L ; : 653 927 6 56 rc N 656 927 M 656 983 I : 2.969 2.969 +S K ; ; : N 710 927 113 53 rp C 1 0 scol L ; : N 710 980 113 3 rp C 1 0 scol L ; : 820 927 6 56 rc N 823 927 M 823 983 I : 2.969 2.969 +S K ; ; : N 876 927 122 53 rp C 1 0 scol L ; : N 876 980 122 3 rp C 1 0 scol L ; : 995 927 6 56 rc N 998 927 M 998 983 I : 2.969 2.969 +S K ; ; : N 1001 927 48 53 rp C 1 0 scol L ; : 1004 930 45 38 rc : 16 13 8 16 47 38 1004 930 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; ; : 1001 977 50 6 rc N 1001 980 M 1052 980 I : 2.969 2.969 +S K ; ; : N 1049 927 2 53 rp C 1 0 scol L ; : N 1051 927 295 53 rp C 1 0 scol L ; 0 0 scol 1054 966 M (object)[24 24 11 22 22 0]xS 0.754 0 scol : 1051 977 298 6 rc N 1052 980 M 1349 980 I : 2.969 2.969 +S K ; ; : 1343 927 6 56 rc N 1346 927 M 1346 983 I : 2.969 2.969 +S K ; ; : N 1349 927 1814 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1352 965 M (@galaxyName)[40 22 22 9 22 18 19 28 22 33 0]xS 0.754 0 scol : 1349 977 1817 6 rc N 1349 980 M 3166 980 I : 2.969 2.969 +S K ; ; : 3160 927 6 56 rc N 3163 927 M 3163 983 I : 2.969 2.969 +S K ; ; : N 53 983 173 51 rp C 1 0 scol L ; : N 53 1034 173 3 rp C 1 0 scol L ; : 223 983 6 54 rc N 226 983 M 226 1037 I : 2.969 2.969 +S K ; ; : N 279 983 377 51 rp C 1 0 scol L ; : N 279 1034 377 3 rp C 1 0 scol L ; : 653 983 6 54 rc N 656 983 M 656 1037 I : 2.969 2.969 +S K ; ; : N 710 983 113 51 rp C 1 0 scol L ; : N 710 1034 113 3 rp C 1 0 scol L ; : 820 983 6 54 rc N 823 983 M 823 1037 I : 2.969 2.969 +S K ; ; : N 876 983 122 51 rp C 1 0 scol L ; : N 876 1034 122 3 rp C 1 0 scol L ; : 995 983 6 54 rc N 998 983 M 998 1037 I : 2.969 2.969 +S K ; ; : N 1013 992 27 481 rp C 0.91 0 scol L ; 1 0 scol N 1013 1473 M 1013 992 I : 2.969 2.969 +S K ; N 1013 992 M 1040 992 I : 2.969 2.969 +S K ; 0.496 0 scol N 1013 1470 M 1037 1470 I : 2.969 2.969 +S K ; N 1037 1470 M 1037 992 I : 2.969 2.969 +S K ; : N 1010 989 33 3 rp C 0.91 0 scol L ; : N 1010 1473 33 3 rp C 0.91 0 scol L ; : N 1010 992 3 481 rp C 0.91 0 scol L ; : N 1040 992 3 481 rp C 0.91 0 scol L ; : N 1001 983 9 499 rp C 1 0 scol L ; : N 1043 983 6 499 rp C 1 0 scol L ; : N 1001 983 48 6 rp C 1 0 scol L ; : N 1001 1476 48 6 rp C 1 0 scol L ; : N 1025 1001 M 1025 1004 I 1022 1004 I 1022 1007 I 1019 1007 I 1019 1010 I 1016 1010 I 1016 1013 I 1037 1013 I 1037 1010 I 1034 1010 I 1034 1007 I 1031 1007 I 1031 1004 I 1028 1004 I 1028 1001 I C eoclip : N 1016 1001 21 12 rp C 0 0 scol L ; ; 0.754 0 scol : 1001 1479 50 6 rc N 1001 1482 M 1052 1482 I : 2.969 2.969 +S K ; ; : N 1049 983 2 499 rp C 1 0 scol L ; : N 1051 983 2112 51 rp C 1 0 scol L ; 0 0 scol F2S26 Ji 1054 1022 M (field)[13 11 22 11 0]xS 0.5 0 scol F0S26 Ji 1135 1021 M ( \(7\))[11 13 22 0]xS 0.754 0 scol : 1242 1031 1924 6 rc N 1245 1034 M 3166 1034 I : 2.969 2.969 +S K ; ; : 3160 983 6 54 rc N 3163 983 M 3163 1037 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1031 201 6 rc N 1052 1034 M 1248 1034 I : 2.969 2.969 +S K ; ; : N 53 1037 173 50 rp C L ; : N 53 1087 173 3 rp C L ; 0.754 0 scol : 223 1037 6 53 rc N 226 1037 M 226 1090 I : 2.969 2.969 +S K ; ; : N 279 1037 377 50 rp C 1 0 scol L ; : N 279 1087 377 3 rp C 1 0 scol L ; : 653 1037 6 53 rc N 656 1037 M 656 1090 I : 2.969 2.969 +S K ; ; : N 710 1037 113 50 rp C 1 0 scol L ; : N 710 1087 113 3 rp C 1 0 scol L ; : 820 1037 6 53 rc N 823 1037 M 823 1090 I : 2.969 2.969 +S K ; ; : N 876 1037 122 50 rp C 1 0 scol L ; : N 876 1087 122 3 rp C 1 0 scol L ; : 995 1037 6 53 rc N 998 1037 M 998 1090 I : 2.969 2.969 +S K ; ; : N 1248 1037 98 50 rp C 0.973 0 scol L ; : N 1051 1037 197 50 rp C 1 0 scol L ; : 1245 1037 7 50 rc N 1248 1037 M 1248 1087 I : 2.969 2.969 +S K ; ; : 1242 1084 107 6 rc N 1245 1087 M 1349 1087 I : 2.969 2.969 +S K ; ; : 1343 1037 6 53 rc N 1346 1037 M 1346 1090 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1084 201 6 rc N 1052 1087 M 1248 1087 I : 2.969 2.969 +S K ; ; : N 1349 1037 47 50 rp C 0.973 0 scol L ; : 1351 1040 45 38 rc : 16 13 8 16 48 38 1351 1040 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; : 16 13 8 16 48 38 1351 1040 F F 3 [ 0 ] F X doNimage nbDYLnbDYLrqQ=:qtU0cqBc3Xr:p6cqS<%(nbE+YqBl+7rqQ=:!5SO-rV66)r:ogWnb<~> Z ; ; 0.754 0 scol : 1349 1084 50 6 rc N 1349 1087 M 1399 1087 I : 2.969 2.969 +S K ; ; : N 1396 1037 3 50 rp C 0.973 0 scol L ; : N 1399 1037 181 50 rp C 0.973 0 scol L ; 0 0 scol : 1402 1040 103 44 rc F2S26 Ji 1402 1076 M (name)[24 22 35 0]xS ; 0.754 0 scol : 1399 1084 184 6 rc N 1399 1087 M 1583 1087 I : 2.969 2.969 +S K ; ; : 1577 1037 6 53 rc N 1580 1037 M 1580 1090 I : 2.969 2.969 +S K ; ; : N 1583 1037 48 50 rp C 0.973 0 scol L ; : 1586 1040 45 38 rc : 16 13 8 16 48 38 1586 1040 F F 3 [ 0 ] F X doNimage nc/.Znc/.Zrr;gAqu?ZqqBc3Xr;Z`qqS<%/nc/UgqBl+>rr;gA!5SO4rVu`0r;Z Z ; : 16 13 8 16 48 38 1586 1040 F F 3 [ 0 ] F X doNimage nbDYLnbDYLrqQ=:qtU0cqBc3Xr:p6cqS<%(nbE+YqBl+7rqQ=:!5SO-rV66)r:ogWnb<~> Z ; ; : 1583 1084 51 6 rc N 1583 1087 M 1634 1087 I : 2.969 2.969 +S K ; ; : N 1631 1037 3 50 rp C 0.973 0 scol L ; : N 1634 1037 211 50 rp C 0.973 0 scol L ; 0 0 scol : 1637 1040 94 44 rc F2S26 Ji 1637 1076 M (units)[24 24 11 13 0]xS ; 0.754 0 scol : 1634 1084 214 6 rc N 1634 1087 M 1848 1087 I : 2.969 2.969 +S K ; ; : 1842 1037 6 53 rc N 1845 1037 M 1845 1090 I : 2.969 2.969 +S K ; ; : N 1848 1037 47 50 rp C 0.973 0 scol L ; : 1850 1040 45 38 rc : 16 13 8 16 48 38 1850 1040 F F 3 [ 0 ] F X doNimage nc/.Znc/Xhru;"PdQ)um\U)uglWs1eX7 !WO,=^^(mp)o2Im^`1)grs\oH_#G@h)o2Im^`1)grrrEA_#G@hrYkq=_#OERs8W-!!5SX7!Pna7 _#FB6^]=E)s7-*~> Z ; : 16 13 8 16 48 38 1850 1040 F F 3 [ 0 ] F X doNimage nbDYLnbE.Zru;"5!#t_.#P]85^`3%f_"ma/p`%$D)o2FlrqQL4s7cThr>PdQ)um\U)u(BIs1eX0 !VdW6^^(mp)o24f^`1)gp^Hp:_"\ka)o24f^`1)gp]^F3_"\karYkq6_"dpKs7lWh!5SX0!PnL0 _#F-/^]=0"q!n+~> Z ; ; : 1848 1084 50 6 rc N 1848 1087 M 1898 1087 I : 2.969 2.969 +S K ; ; : N 1895 1037 3 50 rp C 0.973 0 scol L ; : N 1898 1037 208 50 rp C 0.973 0 scol L ; 0 0 scol : 1901 1040 78 44 rc F1S26 Ji 1901 1076 M (Text)[24 22 20 0]xS ; 0.754 0 scol : 1898 1084 211 6 rc N 1898 1087 M 2109 1087 I : 2.969 2.969 +S K ; ; : 2103 1037 6 53 rc N 2106 1037 M 2106 1090 I : 2.969 2.969 +S K ; ; : N 2109 1037 47 50 rp C 1 0 scol L ; : N 2109 1087 50 3 rp C 1 0 scol L ; : N 2156 1037 3 50 rp C 1 0 scol L ; : N 2159 1037 318 50 rp C 1 0 scol L ; : N 2159 1087 321 3 rp C 1 0 scol L ; : N 2477 1037 3 50 rp C 1 0 scol L ; : N 2480 1037 48 50 rp C 1 0 scol L ; : N 2480 1087 51 3 rp C 1 0 scol L ; : N 2528 1037 3 50 rp C 1 0 scol L ; : N 2531 1037 258 50 rp C 1 0 scol L ; : N 2531 1087 261 3 rp C 1 0 scol L ; : N 2789 1037 3 50 rp C 1 0 scol L ; : N 2792 1037 48 50 rp C 1 0 scol L ; : N 2792 1087 51 3 rp C 1 0 scol L ; : N 2840 1037 3 50 rp C 1 0 scol L ; : N 2843 1037 199 50 rp C 1 0 scol L ; : N 2843 1087 202 3 rp C 1 0 scol L ; : N 3042 1037 3 50 rp C 1 0 scol L ; : N 3045 1037 47 50 rp C 1 0 scol L ; : N 3045 1087 50 3 rp C 1 0 scol L ; : N 3092 1037 3 50 rp C 1 0 scol L ; : N 3095 1037 68 50 rp C 1 0 scol L ; : N 3095 1087 68 3 rp C 1 0 scol L ; : 3160 1037 6 53 rc N 3163 1037 M 3163 1090 I : 2.969 2.969 +S K ; ; : N 53 1090 173 54 rp C 1 0 scol L ; : N 53 1144 173 3 rp C 1 0 scol L ; : 223 1090 6 57 rc N 226 1090 M 226 1147 I : 2.969 2.969 +S K ; ; : N 279 1090 377 54 rp C 1 0 scol L ; : N 279 1144 377 3 rp C 1 0 scol L ; : 653 1090 6 57 rc N 656 1090 M 656 1147 I : 2.969 2.969 +S K ; ; : N 710 1090 113 54 rp C 1 0 scol L ; : N 710 1144 113 3 rp C 1 0 scol L ; : 820 1090 6 57 rc N 823 1090 M 823 1147 I : 2.969 2.969 +S K ; ; : N 876 1090 122 54 rp C 1 0 scol L ; : N 876 1144 122 3 rp C 1 0 scol L ; : 995 1090 6 57 rc N 998 1090 M 998 1147 I : 2.969 2.969 +S K ; ; : N 1248 1090 98 54 rp C 0.973 0 scol L ; : N 1051 1090 197 54 rp C 1 0 scol L ; : 1245 1090 7 54 rc N 1248 1090 M 1248 1144 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1129 M (1 )[22 0]xS 0.754 0 scol : 1242 1141 107 6 rc N 1245 1144 M 1349 1144 I : 2.969 2.969 +S K ; ; : 1343 1090 6 57 rc N 1346 1090 M 1346 1147 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1141 201 6 rc N 1052 1144 M 1248 1144 I : 2.969 2.969 +S K ; ; : N 1349 1090 231 54 rp C L ; 0 0 scol F0S26 Ji 1352 1128 M (galaxyName)[22 22 9 22 18 19 28 22 33 0]xS 0.754 0 scol : 1349 1141 234 6 rc N 1349 1144 M 1583 1144 I : 2.969 2.969 +S K ; ; : 1577 1090 6 57 rc N 1580 1090 M 1580 1147 I : 2.969 2.969 +S K ; ; : N 1583 1090 262 54 rp C 1 0 scol L ; 0 0 scol 1586 1128 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1141 265 6 rc N 1583 1144 M 1848 1144 I : 2.969 2.969 +S K ; ; : 1842 1090 6 57 rc N 1845 1090 M 1845 1147 I : 2.969 2.969 +S K ; ; : N 1848 1090 258 54 rp C 1 0 scol L ; 0 0 scol 1851 1128 M (@galaxyNa...)[40 22 22 9 22 18 19 28 22 11 11 0]xS 0.754 0 scol : 1848 1141 261 6 rc N 1848 1144 M 2109 1144 I : 2.969 2.969 +S K ; ; : 2103 1090 6 57 rc N 2106 1090 M 2106 1147 I : 2.969 2.969 +S K ; ; : N 2109 1090 47 54 rp C 1 0 scol L ; : N 2109 1144 50 3 rp C 1 0 scol L ; : N 2156 1090 3 54 rp C 1 0 scol L ; : N 2159 1090 318 54 rp C 1 0 scol L ; : N 2159 1144 321 3 rp C 1 0 scol L ; : N 2477 1090 3 54 rp C 1 0 scol L ; : N 2480 1090 48 54 rp C 1 0 scol L ; : N 2480 1144 51 3 rp C 1 0 scol L ; : N 2528 1090 3 54 rp C 1 0 scol L ; : N 2531 1090 258 54 rp C 1 0 scol L ; : N 2531 1144 261 3 rp C 1 0 scol L ; : N 2789 1090 3 54 rp C 1 0 scol L ; : N 2792 1090 48 54 rp C 1 0 scol L ; : N 2792 1144 51 3 rp C 1 0 scol L ; : N 2840 1090 3 54 rp C 1 0 scol L ; : N 2843 1090 199 54 rp C 1 0 scol L ; : N 2843 1144 202 3 rp C 1 0 scol L ; : N 3042 1090 3 54 rp C 1 0 scol L ; : N 3045 1090 47 54 rp C 1 0 scol L ; : N 3045 1144 50 3 rp C 1 0 scol L ; : N 3092 1090 3 54 rp C 1 0 scol L ; : N 3095 1090 68 54 rp C 1 0 scol L ; : N 3095 1144 68 3 rp C 1 0 scol L ; : 3160 1090 6 57 rc N 3163 1090 M 3163 1147 I : 2.969 2.969 +S K ; ; : N 53 1147 173 53 rp C 1 0 scol L ; : N 53 1200 173 3 rp C 1 0 scol L ; : 223 1147 6 56 rc N 226 1147 M 226 1203 I : 2.969 2.969 +S K ; ; : N 279 1147 377 53 rp C 1 0 scol L ; : N 279 1200 377 3 rp C 1 0 scol L ; : 653 1147 6 56 rc N 656 1147 M 656 1203 I : 2.969 2.969 +S K ; ; : N 710 1147 113 53 rp C 1 0 scol L ; : N 710 1200 113 3 rp C 1 0 scol L ; : 820 1147 6 56 rc N 823 1147 M 823 1203 I : 2.969 2.969 +S K ; ; : N 876 1147 122 53 rp C 1 0 scol L ; : N 876 1200 122 3 rp C 1 0 scol L ; : 995 1147 6 56 rc N 998 1147 M 998 1203 I : 2.969 2.969 +S K ; ; : N 1248 1147 98 53 rp C 0.973 0 scol L ; : N 1051 1147 197 53 rp C 1 0 scol L ; : 1245 1147 7 53 rc N 1248 1147 M 1248 1200 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1186 M (2 )[22 0]xS 0.754 0 scol : 1242 1197 107 6 rc N 1245 1200 M 1349 1200 I : 2.969 2.969 +S K ; ; : 1343 1147 6 56 rc N 1346 1147 M 1346 1203 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1197 201 6 rc N 1052 1200 M 1248 1200 I : 2.969 2.969 +S K ; ; : N 1349 1147 231 53 rp C L ; 0 0 scol F0S26 Ji 1352 1185 M (gRA)[22 28 0]xS 0.754 0 scol : 1349 1197 234 6 rc N 1349 1200 M 1583 1200 I : 2.969 2.969 +S K ; ; : 1577 1147 6 56 rc N 1580 1147 M 1580 1203 I : 2.969 2.969 +S K ; ; : N 1583 1147 262 53 rp C 1 0 scol L ; 0 0 scol 1586 1185 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1197 265 6 rc N 1583 1200 M 1848 1200 I : 2.969 2.969 +S K ; ; : 1842 1147 6 56 rc N 1845 1147 M 1845 1203 I : 2.969 2.969 +S K ; ; : N 1848 1147 258 53 rp C 1 0 scol L ; 0 0 scol 1851 1185 M (@gRA)[40 22 28 0]xS 0.754 0 scol : 1848 1197 261 6 rc N 1848 1200 M 2109 1200 I : 2.969 2.969 +S K ; ; : 2103 1147 6 56 rc N 2106 1147 M 2106 1203 I : 2.969 2.969 +S K ; ; : N 2109 1147 47 53 rp C 1 0 scol L ; : N 2109 1200 50 3 rp C 1 0 scol L ; : N 2156 1147 3 53 rp C 1 0 scol L ; : N 2159 1147 318 53 rp C 1 0 scol L ; : N 2159 1200 321 3 rp C 1 0 scol L ; : N 2477 1147 3 53 rp C 1 0 scol L ; : N 2480 1147 48 53 rp C 1 0 scol L ; : N 2480 1200 51 3 rp C 1 0 scol L ; : N 2528 1147 3 53 rp C 1 0 scol L ; : N 2531 1147 258 53 rp C 1 0 scol L ; : N 2531 1200 261 3 rp C 1 0 scol L ; : N 2789 1147 3 53 rp C 1 0 scol L ; : N 2792 1147 48 53 rp C 1 0 scol L ; : N 2792 1200 51 3 rp C 1 0 scol L ; : N 2840 1147 3 53 rp C 1 0 scol L ; : N 2843 1147 199 53 rp C 1 0 scol L ; : N 2843 1200 202 3 rp C 1 0 scol L ; : N 3042 1147 3 53 rp C 1 0 scol L ; : N 3045 1147 47 53 rp C 1 0 scol L ; : N 3045 1200 50 3 rp C 1 0 scol L ; : N 3092 1147 3 53 rp C 1 0 scol L ; : N 3095 1147 68 53 rp C 1 0 scol L ; : N 3095 1200 68 3 rp C 1 0 scol L ; : 3160 1147 6 56 rc N 3163 1147 M 3163 1203 I : 2.969 2.969 +S K ; ; : N 53 1203 173 53 rp C 1 0 scol L ; : N 53 1256 173 3 rp C 1 0 scol L ; : 223 1203 6 56 rc N 226 1203 M 226 1259 I : 2.969 2.969 +S K ; ; : N 279 1203 377 53 rp C 1 0 scol L ; : N 279 1256 377 3 rp C 1 0 scol L ; : 653 1203 6 56 rc N 656 1203 M 656 1259 I : 2.969 2.969 +S K ; ; : N 710 1203 113 53 rp C 1 0 scol L ; : N 710 1256 113 3 rp C 1 0 scol L ; : 820 1203 6 56 rc N 823 1203 M 823 1259 I : 2.969 2.969 +S K ; ; : N 876 1203 122 53 rp C 1 0 scol L ; : N 876 1256 122 3 rp C 1 0 scol L ; : 995 1203 6 56 rc N 998 1203 M 998 1259 I : 2.969 2.969 +S K ; ; : N 1248 1203 98 53 rp C 0.973 0 scol L ; : N 1051 1203 197 53 rp C 1 0 scol L ; : 1245 1203 7 53 rc N 1248 1203 M 1248 1256 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1242 M (3 )[22 0]xS 0.754 0 scol : 1242 1253 107 6 rc N 1245 1256 M 1349 1256 I : 2.969 2.969 +S K ; ; : 1343 1203 6 56 rc N 1346 1203 M 1346 1259 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1253 201 6 rc N 1052 1256 M 1248 1256 I : 2.969 2.969 +S K ; ; : N 1349 1203 231 53 rp C L ; 0 0 scol F0S26 Ji 1352 1241 M (gDE)[22 28 0]xS 0.754 0 scol : 1349 1253 234 6 rc N 1349 1256 M 1583 1256 I : 2.969 2.969 +S K ; ; : 1577 1203 6 56 rc N 1580 1203 M 1580 1259 I : 2.969 2.969 +S K ; ; : N 1583 1203 262 53 rp C 1 0 scol L ; 0 0 scol 1586 1241 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1253 265 6 rc N 1583 1256 M 1848 1256 I : 2.969 2.969 +S K ; ; : 1842 1203 6 56 rc N 1845 1203 M 1845 1259 I : 2.969 2.969 +S K ; ; : N 1848 1203 258 53 rp C 1 0 scol L ; 0 0 scol 1851 1241 M (@gDE)[40 22 28 0]xS 0.754 0 scol : 1848 1253 261 6 rc N 1848 1256 M 2109 1256 I : 2.969 2.969 +S K ; ; : 2103 1203 6 56 rc N 2106 1203 M 2106 1259 I : 2.969 2.969 +S K ; ; : N 2109 1203 47 53 rp C 1 0 scol L ; : N 2109 1256 50 3 rp C 1 0 scol L ; : N 2156 1203 3 53 rp C 1 0 scol L ; : N 2159 1203 318 53 rp C 1 0 scol L ; : N 2159 1256 321 3 rp C 1 0 scol L ; : N 2477 1203 3 53 rp C 1 0 scol L ; : N 2480 1203 48 53 rp C 1 0 scol L ; : N 2480 1256 51 3 rp C 1 0 scol L ; : N 2528 1203 3 53 rp C 1 0 scol L ; : N 2531 1203 258 53 rp C 1 0 scol L ; : N 2531 1256 261 3 rp C 1 0 scol L ; : N 2789 1203 3 53 rp C 1 0 scol L ; : N 2792 1203 48 53 rp C 1 0 scol L ; : N 2792 1256 51 3 rp C 1 0 scol L ; : N 2840 1203 3 53 rp C 1 0 scol L ; : N 2843 1203 199 53 rp C 1 0 scol L ; : N 2843 1256 202 3 rp C 1 0 scol L ; : N 3042 1203 3 53 rp C 1 0 scol L ; : N 3045 1203 47 53 rp C 1 0 scol L ; : N 3045 1256 50 3 rp C 1 0 scol L ; : N 3092 1203 3 53 rp C 1 0 scol L ; : N 3095 1203 68 53 rp C 1 0 scol L ; : N 3095 1256 68 3 rp C 1 0 scol L ; : 3160 1203 6 56 rc N 3163 1203 M 3163 1259 I : 2.969 2.969 +S K ; ; : N 53 1259 173 54 rp C 1 0 scol L ; : N 53 1313 173 3 rp C 1 0 scol L ; : 223 1259 6 57 rc N 226 1259 M 226 1316 I : 2.969 2.969 +S K ; ; : N 279 1259 377 54 rp C 1 0 scol L ; : N 279 1313 377 3 rp C 1 0 scol L ; : 653 1259 6 57 rc N 656 1259 M 656 1316 I : 2.969 2.969 +S K ; ; : N 710 1259 113 54 rp C 1 0 scol L ; : N 710 1313 113 3 rp C 1 0 scol L ; : 820 1259 6 57 rc N 823 1259 M 823 1316 I : 2.969 2.969 +S K ; ; : N 876 1259 122 54 rp C 1 0 scol L ; : N 876 1313 122 3 rp C 1 0 scol L ; : 995 1259 6 57 rc N 998 1259 M 998 1316 I : 2.969 2.969 +S K ; ; : N 1248 1259 98 54 rp C 0.973 0 scol L ; : N 1051 1259 197 54 rp C 1 0 scol L ; : 1245 1259 7 54 rc N 1248 1259 M 1248 1313 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1298 M (4 )[22 0]xS 0.754 0 scol : 1242 1310 107 6 rc N 1245 1313 M 1349 1313 I : 2.969 2.969 +S K ; ; : 1343 1259 6 57 rc N 1346 1259 M 1346 1316 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1310 201 6 rc N 1052 1313 M 1248 1313 I : 2.969 2.969 +S K ; ; : N 1349 1259 231 54 rp C L ; 0 0 scol F0S26 Ji 1352 1297 M (Xray)[25 13 22 0]xS 0.754 0 scol : 1349 1310 234 6 rc N 1349 1313 M 1583 1313 I : 2.969 2.969 +S K ; ; : 1577 1259 6 57 rc N 1580 1259 M 1580 1316 I : 2.969 2.969 +S K ; ; : N 1583 1259 262 54 rp C 1 0 scol L ; 0 0 scol 1586 1297 M (@xrayUnits)[40 18 13 22 19 28 22 9 11 0]xS 0.754 0 scol : 1583 1310 265 6 rc N 1583 1313 M 1848 1313 I : 2.969 2.969 +S K ; ; : 1842 1259 6 57 rc N 1845 1259 M 1845 1316 I : 2.969 2.969 +S K ; ; : N 1848 1259 258 54 rp C 1 0 scol L ; 0 0 scol 1851 1297 M (@gXray)[40 22 25 13 22 0]xS 0.754 0 scol : 1848 1310 261 6 rc N 1848 1313 M 2109 1313 I : 2.969 2.969 +S K ; ; : 2103 1259 6 57 rc N 2106 1259 M 2106 1316 I : 2.969 2.969 +S K ; ; : N 2109 1259 47 54 rp C 1 0 scol L ; : N 2109 1313 50 3 rp C 1 0 scol L ; : N 2156 1259 3 54 rp C 1 0 scol L ; : N 2159 1259 318 54 rp C 1 0 scol L ; : N 2159 1313 321 3 rp C 1 0 scol L ; : N 2477 1259 3 54 rp C 1 0 scol L ; : N 2480 1259 48 54 rp C 1 0 scol L ; : N 2480 1313 51 3 rp C 1 0 scol L ; : N 2528 1259 3 54 rp C 1 0 scol L ; : N 2531 1259 258 54 rp C 1 0 scol L ; : N 2531 1313 261 3 rp C 1 0 scol L ; : N 2789 1259 3 54 rp C 1 0 scol L ; : N 2792 1259 48 54 rp C 1 0 scol L ; : N 2792 1313 51 3 rp C 1 0 scol L ; : N 2840 1259 3 54 rp C 1 0 scol L ; : N 2843 1259 199 54 rp C 1 0 scol L ; : N 2843 1313 202 3 rp C 1 0 scol L ; : N 3042 1259 3 54 rp C 1 0 scol L ; : N 3045 1259 47 54 rp C 1 0 scol L ; : N 3045 1313 50 3 rp C 1 0 scol L ; : N 3092 1259 3 54 rp C 1 0 scol L ; : N 3095 1259 68 54 rp C 1 0 scol L ; : N 3095 1313 68 3 rp C 1 0 scol L ; : 3160 1259 6 57 rc N 3163 1259 M 3163 1316 I : 2.969 2.969 +S K ; ; : N 53 1316 173 53 rp C 1 0 scol L ; : N 53 1369 173 3 rp C 1 0 scol L ; : 223 1316 6 56 rc N 226 1316 M 226 1372 I : 2.969 2.969 +S K ; ; : N 279 1316 377 53 rp C 1 0 scol L ; : N 279 1369 377 3 rp C 1 0 scol L ; : 653 1316 6 56 rc N 656 1316 M 656 1372 I : 2.969 2.969 +S K ; ; : N 710 1316 113 53 rp C 1 0 scol L ; : N 710 1369 113 3 rp C 1 0 scol L ; : 820 1316 6 56 rc N 823 1316 M 823 1372 I : 2.969 2.969 +S K ; ; : N 876 1316 122 53 rp C 1 0 scol L ; : N 876 1369 122 3 rp C 1 0 scol L ; : 995 1316 6 56 rc N 998 1316 M 998 1372 I : 2.969 2.969 +S K ; ; : N 1248 1316 98 53 rp C 0.973 0 scol L ; : N 1051 1316 197 53 rp C 1 0 scol L ; : 1245 1316 7 53 rc N 1248 1316 M 1248 1369 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1355 M (5 )[22 0]xS 0.754 0 scol : 1242 1366 107 6 rc N 1245 1369 M 1349 1369 I : 2.969 2.969 +S K ; ; : 1343 1316 6 56 rc N 1346 1316 M 1346 1372 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1366 201 6 rc N 1052 1369 M 1248 1369 I : 2.969 2.969 +S K ; ; : N 1349 1316 231 53 rp C L ; 0 0 scol F0S26 Ji 1352 1354 M (mType)[33 23 19 22 0]xS 0.754 0 scol : 1349 1366 234 6 rc N 1349 1369 M 1583 1369 I : 2.969 2.969 +S K ; ; : 1577 1316 6 56 rc N 1580 1316 M 1580 1372 I : 2.969 2.969 +S K ; ; : N 1583 1316 262 53 rp C 1 0 scol L ; 0 0 scol 1586 1354 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1366 265 6 rc N 1583 1369 M 1848 1369 I : 2.969 2.969 +S K ; ; : 1842 1316 6 56 rc N 1845 1316 M 1845 1372 I : 2.969 2.969 +S K ; ; : N 1848 1316 258 53 rp C 1 0 scol L ; 0 0 scol 1851 1354 M (@mType)[40 33 23 19 22 0]xS 0.754 0 scol : 1848 1366 261 6 rc N 1848 1369 M 2109 1369 I : 2.969 2.969 +S K ; ; : 2103 1316 6 56 rc N 2106 1316 M 2106 1372 I : 2.969 2.969 +S K ; ; : N 2109 1316 47 53 rp C 1 0 scol L ; : N 2109 1369 50 3 rp C 1 0 scol L ; : N 2156 1316 3 53 rp C 1 0 scol L ; : N 2159 1316 318 53 rp C 1 0 scol L ; : N 2159 1369 321 3 rp C 1 0 scol L ; : N 2477 1316 3 53 rp C 1 0 scol L ; : N 2480 1316 48 53 rp C 1 0 scol L ; : N 2480 1369 51 3 rp C 1 0 scol L ; : N 2528 1316 3 53 rp C 1 0 scol L ; : N 2531 1316 258 53 rp C 1 0 scol L ; : N 2531 1369 261 3 rp C 1 0 scol L ; : N 2789 1316 3 53 rp C 1 0 scol L ; : N 2792 1316 48 53 rp C 1 0 scol L ; : N 2792 1369 51 3 rp C 1 0 scol L ; : N 2840 1316 3 53 rp C 1 0 scol L ; : N 2843 1316 199 53 rp C 1 0 scol L ; : N 2843 1369 202 3 rp C 1 0 scol L ; : N 3042 1316 3 53 rp C 1 0 scol L ; : N 3045 1316 47 53 rp C 1 0 scol L ; : N 3045 1369 50 3 rp C 1 0 scol L ; : N 3092 1316 3 53 rp C 1 0 scol L ; : N 3095 1316 68 53 rp C 1 0 scol L ; : N 3095 1369 68 3 rp C 1 0 scol L ; : 3160 1316 6 56 rc N 3163 1316 M 3163 1372 I : 2.969 2.969 +S K ; ; : N 53 1372 173 54 rp C 1 0 scol L ; : N 53 1426 173 3 rp C 1 0 scol L ; : 223 1372 6 57 rc N 226 1372 M 226 1429 I : 2.969 2.969 +S K ; ; : N 279 1372 377 54 rp C 1 0 scol L ; : N 279 1426 377 3 rp C 1 0 scol L ; : 653 1372 6 57 rc N 656 1372 M 656 1429 I : 2.969 2.969 +S K ; ; : N 710 1372 113 54 rp C 1 0 scol L ; : N 710 1426 113 3 rp C 1 0 scol L ; : 820 1372 6 57 rc N 823 1372 M 823 1429 I : 2.969 2.969 +S K ; ; : N 876 1372 122 54 rp C 1 0 scol L ; : N 876 1426 122 3 rp C 1 0 scol L ; : 995 1372 6 57 rc N 998 1372 M 998 1429 I : 2.969 2.969 +S K ; ; : N 1248 1372 98 54 rp C 0.973 0 scol L ; : N 1051 1372 197 54 rp C 1 0 scol L ; : 1245 1372 7 54 rc N 1248 1372 M 1248 1426 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1411 M (6 )[22 0]xS 0.754 0 scol : 1242 1423 107 6 rc N 1245 1426 M 1349 1426 I : 2.969 2.969 +S K ; ; : 1343 1372 6 57 rc N 1346 1372 M 1346 1429 I : 2.969 2.969 +S K ; ; 1 0 scol : 1051 1423 201 6 rc N 1052 1426 M 1248 1426 I : 2.969 2.969 +S K ; ; : N 1349 1372 231 54 rp C L ; 0 0 scol F0S26 Ji 1352 1410 M (images)[9 33 22 22 22 0]xS 0.754 0 scol : 1349 1423 234 6 rc N 1349 1426 M 1583 1426 I : 2.969 2.969 +S K ; ; : 1577 1372 6 57 rc N 1580 1372 M 1580 1429 I : 2.969 2.969 +S K ; ; : N 1583 1372 262 54 rp C 1 0 scol L ; 0 0 scol 1586 1410 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1423 265 6 rc N 1583 1426 M 1848 1426 I : 2.969 2.969 +S K ; ; : 1842 1372 6 57 rc N 1845 1372 M 1845 1429 I : 2.969 2.969 +S K ; ; : N 1848 1372 258 54 rp C 1 0 scol L ; 0 0 scol 1851 1410 M (@@images)[40 40 9 33 22 22 22 0]xS 0.754 0 scol : 1848 1423 261 6 rc N 1848 1426 M 2109 1426 I : 2.969 2.969 +S K ; ; : 2103 1372 6 57 rc N 2106 1372 M 2106 1429 I : 2.969 2.969 +S K ; ; : N 2109 1372 47 54 rp C 1 0 scol L ; : N 2109 1426 50 3 rp C 1 0 scol L ; : N 2156 1372 3 54 rp C 1 0 scol L ; : N 2159 1372 318 54 rp C 1 0 scol L ; : N 2159 1426 321 3 rp C 1 0 scol L ; : N 2477 1372 3 54 rp C 1 0 scol L ; : N 2480 1372 48 54 rp C 1 0 scol L ; : N 2480 1426 51 3 rp C 1 0 scol L ; : N 2528 1372 3 54 rp C 1 0 scol L ; : N 2531 1372 258 54 rp C 1 0 scol L ; : N 2531 1426 261 3 rp C 1 0 scol L ; : N 2789 1372 3 54 rp C 1 0 scol L ; : N 2792 1372 48 54 rp C 1 0 scol L ; : N 2792 1426 51 3 rp C 1 0 scol L ; : N 2840 1372 3 54 rp C 1 0 scol L ; : N 2843 1372 199 54 rp C 1 0 scol L ; : N 2843 1426 202 3 rp C 1 0 scol L ; : N 3042 1372 3 54 rp C 1 0 scol L ; : N 3045 1372 47 54 rp C 1 0 scol L ; : N 3045 1426 50 3 rp C 1 0 scol L ; : N 3092 1372 3 54 rp C 1 0 scol L ; : N 3095 1372 68 54 rp C 1 0 scol L ; : N 3095 1426 68 3 rp C 1 0 scol L ; : 3160 1372 6 57 rc N 3163 1372 M 3163 1429 I : 2.969 2.969 +S K ; ; : N 53 1429 173 53 rp C 1 0 scol L ; : 53 1479 176 6 rc N 53 1482 M 229 1482 I : 2.969 2.969 +S K ; ; : 223 1429 6 56 rc N 226 1429 M 226 1485 I : 2.969 2.969 +S K ; ; : N 279 1429 377 53 rp C 1 0 scol L ; : 279 1479 380 6 rc N 279 1482 M 659 1482 I : 2.969 2.969 +S K ; ; : 653 1429 6 56 rc N 656 1429 M 656 1485 I : 2.969 2.969 +S K ; ; : N 710 1429 113 53 rp C 1 0 scol L ; : 710 1479 116 6 rc N 710 1482 M 826 1482 I : 2.969 2.969 +S K ; ; : 820 1429 6 56 rc N 823 1429 M 823 1485 I : 2.969 2.969 +S K ; ; : N 876 1429 122 53 rp C 1 0 scol L ; : 876 1479 125 6 rc N 876 1482 M 1001 1482 I : 2.969 2.969 +S K ; ; : 995 1429 6 56 rc N 998 1429 M 998 1485 I : 2.969 2.969 +S K ; ; : N 1248 1429 98 53 rp C 0.973 0 scol L ; : N 1051 1429 197 53 rp C 1 0 scol L ; : 1245 1429 7 53 rc N 1248 1429 M 1248 1482 I : 2.969 2.969 +S K ; ; 0 0 scol F2S26 Ji 1310 1468 M (7 )[22 0]xS 0.754 0 scol : 1051 1479 298 6 rc N 1052 1482 M 1349 1482 I : 2.969 2.969 +S K ; ; : 1343 1429 6 56 rc N 1346 1429 M 1346 1485 I : 2.969 2.969 +S K ; ; : N 1349 1429 231 53 rp C 1 0 scol L ; 0 0 scol F0S26 Ji 1352 1467 M (imageQual...)[9 33 22 22 22 30 22 22 9 11 11 0]xS 0.754 0 scol : 1349 1479 234 6 rc N 1349 1482 M 1583 1482 I : 2.969 2.969 +S K ; ; : 1577 1429 6 56 rc N 1580 1429 M 1580 1485 I : 2.969 2.969 +S K ; ; : N 1583 1429 262 53 rp C 1 0 scol L ; 0 0 scol 1586 1467 M (unitless)[22 22 9 11 9 22 19 0]xS 0.754 0 scol : 1583 1479 265 6 rc N 1583 1482 M 1848 1482 I : 2.969 2.969 +S K ; ; : 1842 1429 6 56 rc N 1845 1429 M 1845 1485 I : 2.969 2.969 +S K ; ; : N 1848 1429 258 53 rp C 1 0 scol L ; 0 0 scol 1851 1467 M (@@q)[40 40 0]xS 0.754 0 scol : 1848 1479 261 6 rc N 1848 1482 M 2109 1482 I : 2.969 2.969 +S K ; ; : 2103 1429 6 56 rc N 2106 1429 M 2106 1485 I : 2.969 2.969 +S K ; ; : N 2109 1429 47 53 rp C 1 0 scol L ; : 2109 1479 50 6 rc N 2109 1482 M 2159 1482 I : 2.969 2.969 +S K ; ; : N 2156 1429 3 53 rp C 1 0 scol L ; : N 2159 1429 318 53 rp C 1 0 scol L ; : 2159 1479 321 6 rc N 2159 1482 M 2480 1482 I : 2.969 2.969 +S K ; ; : N 2477 1429 3 53 rp C 1 0 scol L ; : N 2480 1429 48 53 rp C 1 0 scol L ; : 2480 1479 51 6 rc N 2480 1482 M 2531 1482 I : 2.969 2.969 +S K ; ; : N 2528 1429 3 53 rp C 1 0 scol L ; : N 2531 1429 258 53 rp C 1 0 scol L ; : 2531 1479 261 6 rc N 2531 1482 M 2792 1482 I : 2.969 2.969 +S K ; ; : N 2789 1429 3 53 rp C 1 0 scol L ; : N 2792 1429 48 53 rp C 1 0 scol L ; : 2792 1479 51 6 rc N 2792 1482 M 2843 1482 I : 2.969 2.969 +S K ; ; : N 2840 1429 3 53 rp C 1 0 scol L ; : N 2843 1429 199 53 rp C 1 0 scol L ; : 2843 1479 202 6 rc N 2843 1482 M 3045 1482 I : 2.969 2.969 +S K ; ; : N 3042 1429 3 53 rp C 1 0 scol L ; : N 3045 1429 47 53 rp C 1 0 scol L ; : 3045 1479 50 6 rc N 3045 1482 M 3095 1482 I : 2.969 2.969 +S K ; ; : N 3092 1429 3 53 rp C 1 0 scol L ; : N 3095 1429 68 53 rp C 1 0 scol L ; : 3095 1479 71 6 rc N 3095 1482 M 3166 1482 I : 2.969 2.969 +S K ; ; : 3160 1429 6 56 rc N 3163 1429 M 3163 1485 I : 2.969 2.969 +S K ; ; LH (%%[Page: 3]%%) = %%PageTrailer %%Trailer %%BoundingBox: 15 13 597 780 %%DocumentNeededResources: %%+ font Helvetica %%+ font Helvetica-Oblique %%+ font Helvetica-Bold %%+ font Helvetica-BoldOblique %%DocumentSuppliedResources: %%+ procset Pscript_WinNT_ErrorHandler 5.0 0 %%+ procset Pscript_FatalError 5.0 0 %%+ procset Pscript_Win_Basic 5.0 0 %%+ procset Pscript_Win_Utils_L2 5.0 0 %%+ procset Pscript_Win_Dib_L2 5.0 0 %%+ procset Pscript_Text 5.0 0 %%+ procset Pscript_Encoding256 5.0 0 %%+ procset Pscript_Win_Euro_L2 5.0 0 %%+ procset Pscript_Win_GdiObject 5.0 0 %%+ procset Pscript_Win_GdiObject_L2 5.0 0 Pscript_WinNT_Incr dup /terminate get exec ehsave restore %%Pages: 3 (%%[LastPage]%%) = %%EOF %-12345X@PJL EOJ %-12345X --------------010907070504070905090103-- From - Wed Mar 5 20:17:32 2003 X-UIDL: 3e5baf65000000d8 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h25JIEvK023923 for ; Wed, 5 Mar 2003 20:18:14 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h25JIEJ22496 for ; Wed, 5 Mar 2003 20:18:14 +0100 (MET) Received: from ntp2c.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAFlaG7R; Wed, 5 Mar 03 20:18:13 +0100 Received: from mail.star.le.ac.uk ([143.210.36.58]) by artemis.le.ac.uk with smtp (Exim 3.16 #1) id 18qeLU-0000iA-00 for voql@ivoa.net; Wed, 05 Mar 2003 19:14:28 +0000 Received: (qmail 20679 invoked from network); 5 Mar 2003 19:14:49 -0000 Received: from bunyip.star.le.ac.uk (HELO bunyip) (143.210.36.181) by mail.star.le.ac.uk with SMTP; 5 Mar 2003 19:14:49 -0000 Reply-To: From: "Tony Linde" To: "'voql'" Subject: RE: Splitting VOQL up Date: Wed, 5 Mar 2003 19:14:20 -0000 Organization: University of Leicester Message-ID: <00e401c2e34b$6c7ed920$b524d28f@bunyip> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E6636C0.30407@gsfc.nasa.gov> Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi Ed, <> That's clear. <> Hmm, not sure. If you're saying that the behaviour is associated with a particular object or property, I would think the ontology is the best place to store it. How else will the workflow know that when user asks for property XXX, it needs to pass the output of the job where the property is created or accessed to a cross-matching service? This would then depend on software which is constructing the workflow understanding that property XXX having the relationship '"requires cross-matching" with an object of type "yyy"' requires passing the output from one job to a cross-matching service (which might be stated in another part of the ontology or might simply be a requirement of implementing the ontology namespace which includes the relationship "requires cross-matching"). (Do I really understand what I just said? I feel a migraine coming on :) ) <> I agree this is always a good place to start - certainly my favourite. <> I didn't know there was an 'Astronomy Query Language': I thought we'd invented it. Do you have any refs or links to this? We've been using AQL as 'Astronomical Query Language' on AstroGrid almost since the start of the project. <> Now, *that* I can read and make some sense of. Your first AND clause is mixing variable assignments (var1=name), conditional selection (class='cluster...') and field inclusion selection (ie find records which include the fields, name, class etc). I'm not sure that is a good idea. Why is the OR clause following the Find and the Using clauses? Shouldn't all the conditional selections be in the same clause (as with the WHERE and HAVING clauses in SQL)? Anyway, this is why I wanted a human-readable format of the language - so it could be better read and interogated by people. I just came across a quote from an early consideration of XQuery: 'The need for clear and clean semantics for XQuery is probably best met by first producing a model for XML data that is independent of syntax (such as in DOM), and defining a logic or calculus over this model to serve as the formal basis to XQuery. Plunging right into syntax without a careful consideration of the underlying semantics is likely to give a language definition with ambiguity, gaps and hard-to-understand features.' (1) Maybe we should take this to heart and concentrate on the underlying model of data we're trying to query in each of the arenas: . PSL: the underlying DM is probably the whole ontology . WFL: need the DM for a workflow and its composite jobs, users and agents, services . RQL: this is the DM of the Registry . AQL: perhaps the generic structure of data sources, whether catalogs, image sets etc. Cheers, Tony. (1) 'Database Desiderata for an XML Query Language', David Maier, http://www.w3.org/TandS/QL/QL98/pp/maier.html -----Original Message----- From: Ed Shaya [mailto:edward.j.shaya.1@gsfc.nasa.gov] Sent: 05 March 2003 17:41 Cc: 'voql' Subject: Re: Splitting VOQL up ... From - Wed Mar 5 23:12:31 2003 X-UIDL: 3e5baf65000000db X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h25MBHvK016738 for ; Wed, 5 Mar 2003 23:11:17 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h25MBGw00344 for ; Wed, 5 Mar 2003 23:11:16 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAO9aiQa; Wed, 5 Mar 03 23:11:15 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h25MAEPT022778 for ; Wed, 5 Mar 2003 17:10:14 -0500 Message-ID: <3E667624.1030907@gsfc.nasa.gov> Date: Wed, 05 Mar 2003 17:11:48 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "'voql'" Subject: Re: Splitting VOQL up References: <00e401c2e34b$6c7ed920$b524d28f@bunyip> In-Reply-To: <00e401c2e34b$6c7ed920$b524d28f@bunyip> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Tony Linde wrote: ><ordinarily show up in ontology: "requires cross-matching", "requires >averaging over all return values", "may require a quality flag", "can be >in tables, but can also be derived from two other UCD types", "never in >tables, must use image service", etc.>> > >Hmm, not sure. If you're saying that the behaviour is associated with a >particular object or property, I would think the ontology is the best >place to store it. > I was thinking that the astronomy ontology was only astronomical in nature and not have database centric stuff. It would have things like V-band is subproperty of optical-band is subproperty of em-band is subproperty of band, and definition etc. To store things like "never in tables, must use image analysis service" would require something else. It just requires a simple lookup table. I suppose you could tack it onto the ontology. Or, it could be a table that is somehow derived from the ontology. It really doesn't matter to me. > ><Language, ADQL)>> > >I didn't know there was an 'Astronomy Query Language': > I didn't say there was, but AQL sounds like something at the level of VOQL or higher, not a subset of VOQL. ><AND these constraints {>> > >Now, *that* I can read and make some sense of. > >Your first AND clause is mixing variable assignments (var1=name), >conditional selection (class='cluster...') and field inclusion selection >(ie find records which include the fields, name, class etc). I'm not >sure that is a good idea. > I'm not sure it is a good idea, but I'm not sure it wouldn't work either. Perl and IDL permit assignment and declaration in the same statement and they not only work, but are very popular. It is indeed experimental. > >Why is the OR clause following the Find and the Using clauses? Shouldn't >all the conditional selections be in the same clause (as with the WHERE >and HAVING clauses in SQL)? > If at the top level one has an AND followed by an OR, then one should get back two logicals (true|false). What is the processor to do with these two? One could have an implicit AND at the top level, but we chose to be explicit. Ed From - Wed Mar 5 23:52:31 2003 X-UIDL: 3e5baf65000000dc X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h25Molsh021300 for ; Wed, 5 Mar 2003 23:50:48 +0100 (MET) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h25Mol201690 for ; Wed, 5 Mar 2003 23:50:47 +0100 (MET) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAqTaGsd; Wed, 5 Mar 03 23:50:46 +0100 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h25MnjPT024524 for ; Wed, 5 Mar 2003 17:49:45 -0500 Message-ID: <3E667F66.5050806@gsfc.nasa.gov> Date: Wed, 05 Mar 2003 17:51:18 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "'voql'" Subject: Re: Splitting VOQL up References: <00e401c2e34b$6c7ed920$b524d28f@bunyip> In-Reply-To: <00e401c2e34b$6c7ed920$b524d28f@bunyip> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Tony, > >Why is the OR clause following the Find and the Using clauses? Shouldn't >all the conditional selections be in the same clause (as with the WHERE >and HAVING clauses in SQL)? > > Oh. You are right. The structure should have been This shows how important it is to use XML validation. > > From - Tue Apr 1 13:16:48 2003 X-UIDL: 3e5baf6500000397 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h31BENl7005320 for ; Tue, 1 Apr 2003 13:14:24 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h31BENK05476 for ; Tue, 1 Apr 2003 13:14:23 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAYOa4Rk; Tue, 1 Apr 03 13:14:21 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3/3.7W00121514) with ESMTP id UAA08055; Tue, 1 Apr 2003 20:10:30 +0900 (JST) Message-Id: <5.0.2.5.2.20030401200019.01fe9ec8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Tue, 01 Apr 2003 20:10:29 +0900 To: voql , Ed Shaya , Hans-Martin Adorf , Gerard.Lemson@mpe.mpg.de, Jonas Haase , Clive Page , robyn@noao.edu, moore@postal.sdsc.edu, Patrick Dowler , Ray Plante , Niall Gaffney , Kirk Borne , David Barnes From: Masatoshi OHISHI Subject: Re: Splitting VOQL up In-Reply-To: <3E667F66.5050806@gsfc.nasa.gov> References: <00e401c2e34b$6c7ed920$b524d28f@bunyip> <00e401c2e34b$6c7ed920$b524d28f@bunyip> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Status: Dear VOQL friends, IVOA has decided to have a face-to-face WG to develop our VOs in Cambridge in the middle of May. During the week, several WGs are held, including WG on VOQL. I hope you to join the meetings. For details, see the quoted email below. Cheers, Masatoshi >Dear All, > > >please check http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 and >related links for emerging details as to the upcoming InterOp meetings in >Cambridge. > > >I provide details and links to hotels on the above page. I would advise >that you consider booking your accommodation as soon as possible. > > >The registration page will be open during the week. > > >Yours, Nic Walton > > > >======================================================================== >Dr N. A. Walton >(AstroGrid Project Scientist) Tel: +44 1223 337503 >Institute of Astronomy FAX: +44 1223 337523 >University of Cambridge WWW: http://www.astrogrid.org >Madingley Road WWW: http://www.ast.cam.ac.uk/~naw >Cambridge, CB3 0HA email: naw@ast.cam.ac.uk >======================================================================== From - Wed Apr 16 11:35:33 2003 X-UIDL: 3e5baf65000005c7 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3G9XIsN018727; Wed, 16 Apr 2003 11:33:19 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3G9XIY25758; Wed, 16 Apr 2003 11:33:18 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAijaOsY; Wed, 16 Apr 03 11:33:16 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3/3.7W00121514) with ESMTP id SAA23342; Wed, 16 Apr 2003 18:32:16 +0900 (JST) Message-Id: <5.0.2.5.2.20030416174532.01edaec8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 16 Apr 2003 18:32:15 +0900 To: voql , Ed Shaya , Hans-Martin Adorf , Gerard.Lemson@mpe.mpg.de, Jonas Haase , Clive Page , robyn@noao.edu, moore@postal.sdsc.edu, Patrick Dowler , Ray Plante , Niall Gaffney , Kirk Borne , David Barnes From: Masatoshi OHISHI Subject: Re: Splitting VOQL up Cc: ivoa@ivoa.net, naoki.yasuda@nao.ac.jp, mizumoto In-Reply-To: <5.0.2.5.2.20030401200019.01fe9ec8@133.40.4.4> References: <3E667F66.5050806@gsfc.nasa.gov> <00e401c2e34b$6c7ed920$b524d28f@bunyip> <00e401c2e34b$6c7ed920$b524d28f@bunyip> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Hi All, We need to make a preliminary agenda for our meeting in Cambridge. Here is a short list. Your comments and suggestions are welcome ! 1) Present status and planned future extension of JVOQL toward IVOQL 2) Science Use Cases to be implemented to IVOQL 3) What conditions are required to develop IVOQL, considering future extension 4) Language to be used to describe IVOQL 1) is to show an example of VOQL which is actually running, to kick off our discussion. I plan to ask to Naoki Yasuda to talk on this topic. 2) is to discuss what our IVOQL need to be able to do, based on astronomical requests. Do we restrict ourselves only to include "query" to DBs, or do we include other functions, foe example, "automatic analyses such as measurement of image parameters" as the IVOQL, and so on ? 3) is to discuss what the key elements are in developing IVOQL. This is based on Ed Shaya's kick off dated February 27. 4) is famous another issue. Do we use XML, simple text to describe IVOQL ? I want to ask Ed to talk on item 3) or 4). How do you think ? Any volunteer to talk on other topics ? Cheers, Masatoshi From - Wed Apr 16 16:40:34 2003 X-UIDL: 3e5baf65000005d9 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3GEcq1M029601 for ; Wed, 16 Apr 2003 16:38:52 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3GEcqg08568 for ; Wed, 16 Apr 2003 16:38:52 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAuya4Uq; Wed, 16 Apr 03 16:38:51 +0200 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h3GEblx15530 for ; Wed, 16 Apr 2003 09:37:47 -0500 Date: Wed, 16 Apr 2003 09:37:47 -0500 (CDT) From: Ray Plante Reply-To: Ray Plante To: voql Subject: VOQL Cambridge agenda In-Reply-To: <5.0.2.5.2.20030416174532.01edaec8@133.40.4.4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Wed, 16 Apr 2003, Masatoshi OHISHI wrote: > 1) Present status and planned future extension of JVOQL toward IVOQL > 2) Science Use Cases to be implemented to IVOQL > 3) What conditions are required to develop IVOQL, considering future extension > 4) Language to be used to describe IVOQL This looks good. Is 3) basically about developing requirements (or is this part of 2)). This is essential for evaluating alternatives and recognizing where complementary features from different efforts can be merged. Perhaps we should generalize 1) to be "Status of current VOQL prototyping efforts". We can hear both about JVOQL, the Goddard effort, and perhaps someone from the skyquery team can show something. cheers, Ray From - Wed Apr 16 17:05:33 2003 X-UIDL: 3e5baf65000005db X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3GF3pB8011412; Wed, 16 Apr 2003 17:03:51 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3GF3oR09846; Wed, 16 Apr 2003 17:03:50 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAchaGot; Wed, 16 Apr 03 17:03:49 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3/3.7W00121514) with ESMTP id AAA17927; Thu, 17 Apr 2003 00:02:48 +0900 (JST) Message-Id: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 17 Apr 2003 00:02:45 +0900 To: voql , Ed Shaya , Hans-Martin Adorf , Gerard.Lemson@mpe.mpg.de, Jonas Haase , Clive Page , robyn@noao.edu, moore@postal.sdsc.edu, Patrick Dowler , Ray Plante , Niall Gaffney , Kirk Borne , David Barnes , naoki.yasuda@nao.ac.jp, mizumoto From: Masatoshi OHISHI Subject: Re: VOQL Cambridge agenda Cc: ivoa@ivoa.net In-Reply-To: References: <5.0.2.5.2.20030416174532.01edaec8@133.40.4.4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Ray, Thank you for your quick response. At 09:37 03/04/16 -0500, Ray Plante wrote: >On Wed, 16 Apr 2003, Masatoshi OHISHI wrote: > > 1) Present status and planned future extension of JVOQL toward IVOQL > > 2) Science Use Cases to be implemented to IVOQL > > 3) What conditions are required to develop IVOQL, considering future > extension > > 4) Language to be used to describe IVOQL > >This looks good. Is 3) basically about developing requirements (or is >this part of 2)). This is essential for evaluating alternatives and >recognizing where complementary features from different efforts can be >merged. > >Perhaps we should generalize 1) to be "Status of current VOQL prototyping >efforts". We can hear both about JVOQL, the Goddard effort, and perhaps >someone from the skyquery team can show something. Do you have any candidates on the Goddard effort and on skyquery ? On Skyquery I will ask Alex to talk on it. Cheers, Masatoshi From - Wed Apr 16 17:50:14 2003 X-UIDL: 3e5baf65000005de X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3GFgvpe000433; Wed, 16 Apr 2003 17:42:57 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3GFgvA12748; Wed, 16 Apr 2003 17:42:57 +0200 (MEST) Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAl_aa5y; Wed, 16 Apr 03 17:42:55 +0200 Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h3GFfLj15905; Wed, 16 Apr 2003 10:41:21 -0500 Date: Wed, 16 Apr 2003 10:41:21 -0500 (CDT) From: Ray Plante Reply-To: Ray Plante To: Masatoshi OHISHI cc: voql , Ed Shaya , Hans-Martin Adorf , , Jonas Haase , Clive Page , , , Patrick Dowler , Niall Gaffney , Kirk Borne , David Barnes , , mizumoto , Subject: Re: VOQL Cambridge agenda In-Reply-To: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Thu, 17 Apr 2003, Masatoshi OHISHI wrote: > Do you have any candidates on the Goddard effort I am refering to Shaya's work. cheers, Ray PS: I would recommend that anyone who has received this message and is interested in this activity but is not on the voql mailing list to subscribe. You can do so by sending email to majordomo@ivoa.net with "subscribe voql" as the sole contents of the message body. From - Tue Apr 29 11:59:49 2003 X-UIDL: 3e5baf6500000745 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3T9vLWg025037 for ; Tue, 29 Apr 2003 11:57:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3T9vL023119 for ; Tue, 29 Apr 2003 11:57:21 +0200 (MEST) Received: from rly-ip05.mx.aol.com(64.12.138.9) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAhAayjT; Tue, 29 Apr 03 11:57:20 +0200 Received: from logs-tkp-tb.proxy.aol.com (logs-tkp-tb.proxy.aol.com [198.81.1.173]) by rly-ip05.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN9-0429055310; Tue, 29 Apr 2003 05:53:10 -0500 Received: from Cassiopeia.mtk.nao.ac.jp (ACCD70F6.ipt.aol.com [172.205.112.246]) by logs-tkp-tb.proxy.aol.com (8.12.9/8.12.9) with ESMTP id h3T9k3JW015160 for ; Tue, 29 Apr 2003 09:46:04 GMT Message-Id: <5.0.2.5.2.20030429184423.02058ec8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Tue, 29 Apr 2003 18:46:03 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Agenda for the Cambridge meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Apparently-From: Ohishi42@aol.com X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear All, Here is the agenda for the coming Cambridge meeting: 1) Present status and planned future extension of some National VOQLs toward IVOQL by Naoki Yasuda (Japan), Ed Shaya (US) and Wil O'Mullane (US) 2) Science Use Cases to be implemented to IVOQL by Masahiro Tanaka (Japan) 3) What conditions are required to develop IVOQL, considering future extension by Masatoshi Ohishi (Japan) 4) Language to be used to describe IVOQL by Ed Shaya (US) 5) Discussion on Work Plan toward IVOQL ALL For items 1) through 4), the tasks of presenters are to kick off our discussion. I look forward to your participation and good discussion. Best regards, Masatoshi ********************************************** Masatoshi OHISHI National Astronomical Observatory of Japan 2-21-1, Osawa, Mitaka, Tokyo, 181-8588 JAPAN phone :+81-422-34-3575 (office) +81-90-3574-9474 (mobile) fax :+81-422-34-3840 e-mail:masatoshi.ohishi@nao.ac.jp ********************************************** From - Tue May 20 18:00:20 2003 X-UIDL: 3e5baf6500000a65 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KFwBC6004790 for ; Tue, 20 May 2003 17:58:11 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4KFwAE27127 for ; Tue, 20 May 2003 17:58:10 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAQMaO_0; Tue, 20 May 03 17:58:09 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.14) id 19I9RY-00005z-17 for voql@ivoa.net; Tue, 20 May 2003 16:54:24 +0100 Received: (qmail 2053 invoked from network); 20 May 2003 15:54:45 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 20 May 2003 15:54:45 -0000 Date: Tue, 20 May 2003 16:54:23 +0100 (BST) From: Clive Page To: voql@ivoa.net Subject: RE: MyUCDs & Registry In-Reply-To: <009a01c31ee3$9fce9030$1001a8c0@brolga> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: (-------------------------) -25.3 X-Scanner: exiscan for exim4 *19I9RY-00005z-17*aAlGuJlldIM* X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Tue, 20 May 2003, Tony Linde wrote: > The column names have to be inserted into the query before it is sent out. > It may start out as generic but, in order to be resolved at the dataset end, > it must have some specificity added. Tony et al This was discussed at some length in the VOQL group (and maybe also in the registry group?). We are assuming that we have some generic queries, such as a cone search with added constraints (e.g. V_magnitude > 20) which can be sent out meaningfully to multiple sites. Clearly the only way to specify these is to use UCDs, since column names will vary. Somewhere the UCD has to be translated into a specific column name. This _could_ be done by the Registry, if it has the requisite information, but it may not, because not everyone is yet convinced that the fine-grained Registry is the way to go, so not all of them may ingest the necessary data. It can _always_ be translated by the end data centre, since it knows the names of its own columns. If information on the UCDs of each column is not present at the end data centre, then it will almost certainly not be present in the Registry, since where else can it come from? So we concluded that the most reliable way to do the translation is at the data centre. This simplifies the Registry and workflow, without significantly complicating the data centre interface (which has to be handle UCDs and columns anyhow). > PS: Sorry about the cross-post. This seems to be more of a VOQL question > now, so shall we continue the discussion on that list ?? That's what I've done. Sorry if Registry folks have to read the VOQL archive to see this posting. -- Clive Page, Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From - Tue May 20 17:30:18 2003 X-UIDL: 3e5baf6500000a5d X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KFQIC6023432 for ; Tue, 20 May 2003 17:26:18 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4KFQH125381 for ; Tue, 20 May 2003 17:26:17 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAADLayKX; Tue, 20 May 03 17:26:16 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.14) id 19I8wg-0006Xe-BP for registry@ivoa.net; Tue, 20 May 2003 16:22:30 +0100 Received: (qmail 29709 invoked from network); 20 May 2003 15:22:51 -0000 Received: from brolga.star.le.ac.uk (HELO brolga) (143.210.36.204) by mail.star.le.ac.uk with SMTP; 20 May 2003 15:22:51 -0000 Reply-To: From: "Tony Linde" To: , "'voql'" Subject: RE: MyUCDs & Registry Date: Tue, 20 May 2003 16:22:28 +0100 Organization: University of Leicester Message-ID: <009a01c31ee3$9fce9030$1001a8c0@brolga> 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 In-Reply-To: <3ECA39EA.6090809@nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: (------) -6.5 X-Scanner: exiscan for exim4 *19I8wg-0006Xe-BP*PJctWEw0BE.* 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 h4KFQSC6023461 Status: Hi Tom, > I find this unconvincing. How is a 'generic' query to be > able to do anything with column names? The column names have to be inserted into the query before it is sent out. It may start out as generic but, in order to be resolved at the dataset end, it must have some specificity added. > We have no standardized mechanism for specifying > the names of columns (and as far as I know we have not even > begun an effort to define such) so manifestly it is currently > impossible to use column names for a generic query. That's why we have these working groups :) I've proposed a possible approach to inclusion of names in my original discourse: http://www.ivoa.net/twiki/bin/view/IVOA/TonyOnUCDs where the tag modifies the generic tag of which it is a part. > This doesn't mean > that someone couldn't make a query against the observation > centers, but that would be a 'manual' query. But they are both queries and the query mechanism needs to cater for both possibilities. > How does any kind of > automated program pick between 'ra_usno' and 'ra_sdss'? It certainly cannot and I wasn't proposing that it could. In this case the workflow should either stop and flag the user that he needs to intervene in the workflow and resolve the duplication or just picks one and goes ahead (this option should be set by the user at the beginning of the workflow). But where the query is specified at the outset of constructing the workflow, the workflow engine can consult the registry to determine if any duplication conflicts occur and ask the user to resolve them before the job is submitted. > To my mind UCD's provide precisely the information that is > useful in making automated decisions about which column to > query. They identify the kind of information that is in the I agree completely but we need to provide mechanisms for those situations where UCDs do not solve the problem. Cheers, Tony. PS: Sorry about the cross-post. This seems to be more of a VOQL question now, so shall we continue the discussion on that list ?? > -----Original Message----- > From: Tom McGlynn [mailto:Thomas.A.McGlynn@nasa.gov] > Sent: 20 May 2003 15:22 > To: registry@ivoa.net > Subject: Re: MyUCDs & Registry > > > > 5. Should the Registry store the column names and units used in a > > catalog or data table? I would say 'definitely' for the > column names > > and 'probably' for the units. The column names are essential to > > resolve duplicate UCDs before a generic query is farmed out. > > Hi Tony, > > I find this unconvincing. How is a 'generic' query to be > able to do anything with column names? > > Generic queries must use some standardized mechanism > to identify the elements used in the query (else they aren't > generic). We have no standardized mechanism for specifying > the names of columns (and as far as I know we have not even > begun an effort to define such) so manifestly it is currently > impossible to use column names for a generic query. > > However, I believe that the currently planned implementation > of UCDs will in practice be adequate virtually all of the time. > > The putative problem with UCD's is that multiple columns > in a given table may share the same UCD. Let's look at some > scenarios in more detail. One example given in Cambridge was > an object catalog whose entries contained not only the object > postition but the center of the image on which the object was > detected. This is precisely the kind of case the 'main' UCD > qualifier would (and does) address. It is easily be handled > using either the current or proposed UCD frameworks. A user > querying this table is getting objects, and the position of > the object should be the 'main' position. This doesn't mean > that someone couldn't make a query against the observation > centers, but that would be a 'manual' query. > > There are cases where the 'main' column is not obvious. > E.g., we might have a table which is the cross-correlation > between the SDSS and USNO-B object catalogs. This contains > two positions neither really subordinate to the other. Which > should be used in querying the table? > > I'll grant the UCD's do not magically solve this problem, but > the column names don't really help. How does any kind of > automated program pick between 'ra_usno' and 'ra_sdss'? > > In practice in this case I would expect the creators of this > table to pick one of the sets of position -- perhaps the one > with the smallest error -- and suggest that this is the > primary set of positions. How might they do this most > easily? The 'main' qualifier in the UCD descriptions is > again the obvious candidate. The choice here is a bit > arbitrary, but so would any automated choice based on > position be. Regardless it will not matter very much, since > the positions will be very close to one another. > > For a third scenario let's consider a catalog of gamma-ray > bursts where the position of each burst is given as a > quadralateral in the sky with four bounding positions. Here > it's clearly impossible to pick any > one of these positions over the other. The best resolution of this > problem is probably to define a UCD for the group of columns > the define the bounding box. Again having column names > doesn't help automated software pick a column -- this table > just isn't easily searchable using simple cone-search > techniques. Fortunately this is a relatively rare sort of table. > > > > To my mind UCD's provide precisely the information that is > useful in making automated decisions about which column to > query. They identify the kind of information that is in the > column in a standard way. When there are multiple columns > that have the same kind of information I don't think it's > reasonable to expect automated choices to be made unless > there is a hint from the creator of the table. > > This doesn't mean that we don't want to have column names in > the registry. They may be helpful for directed (rather than > automated queries), for textual matches, and to help the user > understand what is in a table before actually running a query. > > > I agree with you about units. Basically they are an > implementation detail and the registry should not be exposing > this implementation choice. > > Tom McGlynn > From - Tue May 20 20:17:00 2003 X-UIDL: 3e5baf6500000a78 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KIGOC6023970 for ; Tue, 20 May 2003 20:16:24 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4KIGNX04022 for ; Tue, 20 May 2003 20:16:23 +0200 (MEST) Received: from lheapop.gsfc.nasa.gov(128.183.16.62) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAzkaO2h; Tue, 20 May 03 20:16:22 +0200 Received: from nasa.gov (silk2.gsfc.nasa.gov [128.183.19.104]) by milkyway.gsfc.nasa.gov (8.12.8/8.12.8) with ESMTP id h4KIDBe4018079 for ; Tue, 20 May 2003 14:13:11 -0400 Message-ID: <3ECA702A.9000105@nasa.gov> Date: Tue, 20 May 2003 14:12:58 -0400 From: Tom McGlynn User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: MyUCDs & Registry References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Clive Page wrote: > On Tue, 20 May 2003, Tony Linde wrote: > > >>The column names have to be inserted into the query before it is sent out. >>It may start out as generic but, in order to be resolved at the dataset end, >>it must have some specificity added. > > > Tony et al > > This was discussed at some length in the VOQL group (and maybe also in the > registry group?). > > We are assuming that we have some generic queries, such as a cone search > with added constraints (e.g. V_magnitude > 20) which can be sent out > meaningfully to multiple sites. Clearly the only way to specify these is > to use UCDs, since column names will vary. Somewhere the UCD has to be > translated into a specific column name. ... Clive, This sounds right to me. If I understand it we have a sequence of - query to the registry to find resources of interest - explosion of a 'generic' query to selected resources - translation of the generic query to local query syntax Here the registry query may involve terms separate from the generic query. E.g., this might be 'Find me all the catalogs with proper motions'. The syntax of this query would need to be expressible in VOQL and the basic registry service is to satisfy such queries. The explosion of the generic query to the selected sites is the responsibility of whatever VO service the ultimate user is communicating with. I don't think I would define it as a registry function, though I can certainly imagine building services that combine registries and exploders. The generic query might be something like a cone search in the Hyades region. The generic query is sent to each of the selected services and translated into local terms separately at each of them. Our example cone search might be translated into a nasty bit of SQL constraints on the coordinates. So for a generic query, the user needn't know of the actual column names until getting the results back. Presumably VOQL also needs to support queries where the specific column names are specified too -- but these would be 'manual' queries where the user already knows the structure of the table to be queried. So getting these names from the registry doesn't seem particularly vital -- though I'd want the protocol for returning data from the registry to define how column names are returned if a registry chooses to include them. The astronomers original query may have been: "Find me the proper motion of all stars in the Hyades region." The specification of the desired outputs defines distinct elements of the registry query. We'd probably also want to pass along the elements of the generic query too, since the registry may be fine-grained enough to use them. E.g., the registry can filter out proper motion catalogs that don't cover the Hyades region. However a given registry may choose to ignore any or all of the generic query constraints. Tom From - Tue May 20 23:30:34 2003 X-UIDL: 3e5baf6500000a8d X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4KLUZcF019402 for ; Tue, 20 May 2003 23:30:35 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4KLUZM13237 for ; Tue, 20 May 2003 23:30:35 +0200 (MEST) Received: from mta07-svc.ntlworld.com(62.253.162.47) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAjVaq2z; Tue, 20 May 03 23:30:29 +0200 Received: from brolga ([213.105.123.90]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030520212848.QKDM25105.mta07-svc.ntlworld.com@brolga> for ; Tue, 20 May 2003 22:28:48 +0100 Reply-To: From: "Tony Linde" To: Subject: RE: MyUCDs & Registry Date: Tue, 20 May 2003 22:28:37 +0100 Organization: University of Leicester Message-ID: <00aa01c31f16$cbfe0630$1001a8c0@brolga> 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 In-Reply-To: <3ECA702A.9000105@nasa.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal 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 h4KLUmcF019442 Status: Tom, > - query to the registry to find resources of interest > - explosion of a 'generic' query to selected resources > - translation of the generic query to local query syntax This is one scenario. > Here the registry query may involve terms separate from the > generic query. E.g., this might be 'Find me all the catalogs > with proper motions'. The syntax of this query would need to > be expressible in VOQL and the basic registry service is to > satisfy such queries. The question of whether it makes sense for the registry query to be the same format as the more specific VOQL is still open. Your example is one difference between them. Another is that the registry query will need to specify the metadata formats (subsets of metadata) to be returned, though this could be in a separate region of the xml query document from the actual registry query. Does VOQL need to cater for image queries etc? > The explosion of the generic query to the selected sites > is the responsibility of whatever Yes. In AstroGrid it will be the responsibility of one of the components of the job controller (to which the workflow engine submits jobs). > of SQL constraints on the coordinates. So for a generic > query, the user needn't know of the actual column names until > getting the results back. > > Presumably VOQL also needs to support queries where the > specific column names are specified too -- but these would be > 'manual' queries where the user already knows the structure But the VOQL should also support the creation of hybrid queries to satisfy the scenario I described. > "Find me the proper motion of all stars in the Hyades region." I think it is safer to say this was the astronomer's original intention. In order to understand the intention, the astronomer will have to go through whatever interface his/her portal of choice puts up: in the case of AstroGrid, it'll be drop-down lists, checkboxes etc. I think we're some way off being able to type in the above phrase - next project, I hope :) Cheers, Tony. > -----Original Message----- > From: Tom McGlynn [mailto:Thomas.A.McGlynn@nasa.gov] > Sent: 20 May 2003 19:13 > To: voql@ivoa.net > Subject: Re: MyUCDs & Registry > > > > > Clive Page wrote: > > On Tue, 20 May 2003, Tony Linde wrote: > > > > > >>The column names have to be inserted into the query before > it is sent > >>out. It may start out as generic but, in order to be > resolved at the > >>dataset end, it must have some specificity added. > > > > > > Tony et al > > > > This was discussed at some length in the VOQL group (and > maybe also in > > the registry group?). > > > > We are assuming that we have some generic queries, such as a cone > > search with added constraints (e.g. V_magnitude > 20) which can be > > sent out meaningfully to multiple sites. Clearly the only way to > > specify these is to use UCDs, since column names will vary. > Somewhere > > the UCD has to be translated into a specific column name. > > ... > > Clive, > > This sounds right to me. If I understand it we have a sequence of > > - query to the registry to find resources of interest > - explosion of a 'generic' query to selected resources > - translation of the generic query to local query syntax > > Here the registry query may involve terms separate from the > generic query. E.g., this might be 'Find me all the catalogs > with proper motions'. The syntax of this query would need to > be expressible in VOQL and the basic registry service is to > satisfy such queries. > > The explosion of the generic query to the selected sites > is the responsibility of whatever > VO service the ultimate user is communicating with. I don't > think I would define it as a registry function, though I can > certainly imagine building services that combine registries > and exploders. The generic query might be something like a > cone search in the Hyades region. > > The generic query is sent to each of the selected services > and translated into local terms separately at each of them. > Our example cone search might be translated into a nasty bit > of SQL constraints on the coordinates. So for a generic > query, the user needn't know of the actual column names until > getting the results back. > > Presumably VOQL also needs to support queries where the > specific column names are specified too -- but these would be > 'manual' queries where the user already knows the structure > of the table to be queried. So getting these names from the > registry doesn't seem particularly vital -- though I'd want > the protocol for returning data from the registry to define > how column names are returned if a registry chooses to include them. > > > > The astronomers original query may have been: > > "Find me the proper motion of all stars in the Hyades region." > > The specification of the desired outputs defines distinct > elements of the registry query. We'd probably also want to > pass along the elements of the generic query too, since the > registry may be fine-grained enough to use them. E.g., the > registry can filter out proper motion catalogs that don't > cover the Hyades region. However a given registry may choose > to ignore any or all of the generic query constraints. > > > Tom > > > From - Wed May 21 05:41:25 2003 X-UIDL: 3e5baf6500000aa1 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4L3bwcF007623 for ; Wed, 21 May 2003 05:37:59 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4L3bwB23280 for ; Wed, 21 May 2003 05:37:58 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAApCaODT; Wed, 21 May 03 05:37:57 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id MAA05033 for ; Wed, 21 May 2003 12:34:14 +0900 (JST) Message-Id: <5.0.2.5.2.20030521122937.04e04aa8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Wed, 21 May 2003 12:34:10 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Cambridge meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: Dear VOQL friends, Many people attended the Cambridge meeting, and the presentation files are uploaded (two more !) in http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003VOQL We agreed to develop our VOQL based on extended SQL as the first step, and then power-up VOQL based on XML. My report to the plenary meeting on 15th explains the background, and the meeting minutes in the above page (prepared by Bob Mann) has the details. Therefore I recommend you all to read all relevant materials. The first stage will be lead by Wil O'mullane (US) and Naoki Yasuda (J), with your great support. With best wishes, Masatoshi From - Thu May 22 18:16:28 2003 X-UIDL: 3e5baf6500000b1b X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4MGGS3S016498 for ; Thu, 22 May 2003 18:16:28 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4MGGSt19091 for ; Thu, 22 May 2003 18:16:28 +0200 (MEST) Received: from mercury.ex.ac.uk(144.173.6.26) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAGkaqsL; Thu, 22 May 03 18:16:27 +0200 Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root) by mercury.ex.ac.uk with esmtp (Exim 4.14) id 19Isil-00Tn5c-4G for voql@ivoa.net; Thu, 22 May 2003 17:15:11 +0100 Received: from localhost by dastardly.astro.ex.ac.uk; Thu, 22 May 2003 17:15:10 +0100 Date: Thu, 22 May 2003 17:15:10 +0100 (BST) From: Alasdair Allan To: VOQL List Subject: RTML In-Reply-To: <5.0.2.5.2.20030521122937.04e04aa8@133.40.4.4> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: All, Masatoshi OHISHI wrote: > We agreed to develop our VOQL based on extended SQL as the first > step, and then power-up VOQL based on XML. During the morning session I mentioned RTML, and how the robotic telescope community is using it to make data requests, some interest was shown by various people at the meeting, so... I thought I'd throw some links at you so that you can have a look a this stuff in your own time, the main RTML page can be found at http://sunra.lbl.gov/rtml/ the RTML version the eSTAR (www.estar.org.uk) project is using is an extended version of RTML v2.1, and was "officially" adopted as RTML v2.2 at the end of 2002, it provides a fair bit more functionality than RTML v2.1 but preserves the syntax (ie. its backwards compatible). A summary of the syntax can be found at http://sunra.lbl.gov/rtml/estar.html the DTD for v2.2 can be found here http://www.astro.ex.ac.uk/estar/documents/rtml2.1.dtd and also here http://alpha.uni-sw.gwdg.de/~hessman/RTML/RTML2.2/RTML-2.2.dtd and some simple RTML v2.2 examples at http://www.astro.ex.ac.uk/estar/documents/rtml_examples.tar.gz Cheers, Al. -- Dr. A. Allan, School of Physics, University of Exeter From - Fri May 23 10:56:28 2003 X-UIDL: 3e5baf6500000b55 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4N8uJSG023083 for ; Fri, 23 May 2003 10:56:19 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4N8uJA23864 for ; Fri, 23 May 2003 10:56:19 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAYza4MU; Fri, 23 May 03 10:56:18 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.20) id 19J8Hw-0003WP-F0 for voql@ivoa.net; Fri, 23 May 2003 09:52:32 +0100 Received: (qmail 564 invoked from network); 23 May 2003 08:52:54 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 23 May 2003 08:52:54 -0000 Date: Fri, 23 May 2003 09:52:32 +0100 (BST) From: Clive Page To: VOQL List Subject: Re: RTML In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Status: On Thu, 22 May 2003, Alasdair Allan wrote: > During the morning session I mentioned RTML, and how the robotic > telescope community is using it to make data requests, some interest > was shown by various people at the meeting, so... Alasdair et al I'm not convinced there's much commonality - if you compare the RTML schema with what is required in a data archive request (say look in SIAP or the cone-search prototypes, or ASU) just about the only elements in common are RA, and DEC. There's something called "epoch" which might be intended to be "equinox" (people often confuse them), since equinox is obviously essential (not every archive uses J2000). But I see no way of specifying even a cone-radius or image size. With so little in common, I don't see much advantage to it. -- Clive Page, Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Mon Aug 4 20:21:18 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 h74IKnqG009109 for ; Mon, 4 Aug 2003 20:20:49 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h74IKnVd009108 for voql-outgoing; Mon, 4 Aug 2003 20:20:49 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h74IKhqG009050 for ; Mon, 4 Aug 2003 20:20:43 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h74IKgj29121 for ; Mon, 4 Aug 2003 20:20:42 +0200 (MEST) Received: from po4.wam.umd.edu(128.8.10.166) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARFaa44; Mon, 4 Aug 03 20:20:41 +0200 Received: from gsfc.nasa.gov (atlas.physics.umd.edu [129.2.41.47]) by po4.wam.umd.edu (8.9.3p2/8.9.3) with ESMTP id OAA12585; Mon, 4 Aug 2003 14:20:25 -0400 (EDT) Message-ID: <3F2EA29E.3020809@gsfc.nasa.gov> Date: Mon, 04 Aug 2003 14:14:54 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'voql'" , Shenping Huang Subject: The issue of conflicting data in a destributed data system 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We were taking a stab at formalizing what a high level VOQL does when we came across several issues that should be brought forth to this discussion group. These issues come about because in a set of distributed repositories of scientific data there is going to be conflicting data with regard to constraints on property values and we wish to properly deal with these conflicts in a manner that maintains the scientific integrity of the results even if it requires some extra processing. Suppose that a query is made for objects of Class C with propertyType A with value in range R1 to R2. Symbolically, O(C=c,P(A)=[R1:R2]). Suppose that some repositories have data on a specific object that indicate property A is within range, but at other repositories it is out of range. This could come about because different repositories have determinations from different astronomers or taken at different times or by different methods. And, let's not yet bring up error-bar issues, but just deal with the bare measurement value. The response from the various repositories is to either have or not have this object in the list of satisfying objects. This amounts to a bias in results and this bias could be severe. For example, a measurement taken years ago when some observing technique was new may have resulted in this object making the cut, but all subsequent observations of higher quality could clearly show that it is not in the range. The absence of the contrary information results in misinformation and bias. It behooves us to present the full picture, but on the other hand, each repository responded fairly with the best of its (limited) knowledge. Let's examine a one pass solution and a two pass solution to this. In a one pass solution one starts with a much wider range to include the maximum reasonable error, e. Symbolically (O(C=c,P(A)=[R1-e:R2+e]) and when all of the data are returned, the user can process this as he/she wishes; either taking a weighted average, or throwing out outliers and then averaging, or taking the latest or best, and then compares the result to the desired range of the query. The two pass system has the query as earlier, with range [R1:R2], and when there is at least one hit, resend the query with no range set O(C=c,Id=I,P(A)) to bring back what every repository contains on this object's P(A). There are pros and cons to either. The one-pass is faster and it also returns well for cases where the data straddle on either side of the range but the average is in range. However, it suffers from the need to know a priori what the reasonable range in errors is for every measurement. Who's responsibility would it be to add that error to the range? Does the user do it or does a very smart system do it? But, the critical problem here is, what if early measurements were within the enlarged range, but best recent measurements are outside? We are back to the original problem. It appears therefore that we are forced to a two pass system as it is the only way that one can get a complete response to constrained queries. In fact one must combine the two methods and allow an error-bar (for the case of straddling points) on the first search and follow it up with a second query on P(A) without range. One might argue isn't it still possible to have points straddle just outside the extended range but have an average inside the desired range? Here, one does have to rely on error bars working sensibly; if they do, then this would very rarely happen. The alternative to this would be to require all data on P(A) for all Objects of class C to be returned and the range be applied only after a full gathering of data. At this point the whole concept of distributed repositories falls apart and one would be better off with a super-repository with all of the data in one place. Our conclusion is that a query consisting of several constraints on properties coupled together by logical operators (and,or) must be broken down into atomized requests for properties one at a time. First receiving O(C=c,P(A)=[R1-e:R2+e]) and later receiving O(C=c,Id=I,P(A)). There should not be, in the initial simple implementation of VOQL, logical operations sent to individual repositories of the form O(C=c,P(A)=[R1:R2] AND P(B)=[R3:R4]). A given repository can not know the ultimate outcome on P(A) or P(B) so it can not apply the logic. Ed From owner-voql@eso.org Mon Aug 4 21:17:09 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 h74JH2qG003121 for ; Mon, 4 Aug 2003 21:17:02 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h74JH2q8003120 for voql-outgoing; Mon, 4 Aug 2003 21:17:02 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h74JGtqG003079 for ; Mon, 4 Aug 2003 21:16:55 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h74JGsJ01757 for ; Mon, 4 Aug 2003 21:16:54 +0200 (MEST) Received: from lheapop.gsfc.nasa.gov(128.183.16.62) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAWDaqBd; Mon, 4 Aug 03 21:16:52 +0200 Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.9/8.12.9) with ESMTP id h74JGilj026253; Mon, 4 Aug 2003 15:16:44 -0400 Message-ID: <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> Date: Mon, 04 Aug 2003 15:16:58 -0400 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Shaya CC: "'voql'" , Shenping Huang Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> In-Reply-To: <3F2EA29E.3020809@gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'm confused, no doubt in part because I don't have the context for the problem, but... It sounds like you are concluding that the only queries on single property at a time need to be supported by VOQL. While I don't fully follow the discussion, I'd suggest that all you can conclude is that there are some query services that need to work the way you are discussing, but I think these are very complex queries, not the bread and butter queries that I'd expect astronomers need. Could we make this a little more concrete and perhaps you can help me understand where I've gone wrong. In the brown dwarf demo we did a correlation of very red SDSS objects with very red 2MASS objects. This involved a query of the form (more or less) select from xxx where reddest_color is not null and bluer_colors are null on both of these tables and then a join between the sets of results. According to what you are saying this wouldn't be doable using VOQL, we'd have to query on each on of the criteria separately?? But this is what I'd expect to see all the time. It sounds like you're assuming all queries have to marshall results from a host of constiuent tables -- doing some kind of union of various sources. But I think that joins between tables are more likely at least in the early stages of the VO. I think the early VO is going to much more about users being able to easily find and combine resources, with the users still explicitly choosing them, then about the VO doing lots of automated stuff and making substantial decisions on behalf of the user. Tom Ed Shaya wrote: > We were taking a stab at formalizing what a high level VOQL does > when we came across several issues that should be brought forth > to this discussion group. These issues come about because in a > set of distributed repositories of scientific data there is going > to be conflicting data with regard to constraints on property values > and we wish to properly deal with these conflicts in a manner that > maintains the scientific integrity of the results even if it requires > some extra processing. > > > Suppose that a query is made for objects of Class C with propertyType > A with value in range R1 to R2. Symbolically, O(C=c,P(A)=[R1:R2]). > > Suppose that some repositories have data on a specific object that > indicate property A is within range, but at other repositories it is > out of range. This could come about because different repositories > have determinations from different astronomers or taken at different > times or by different methods. And, let's not yet bring up error-bar > issues, but just deal with the bare measurement value. The response > from the various repositories is to either have or not have this object > in the list of satisfying objects. This amounts to a bias in results > and this bias could be severe. For example, a measurement taken > years ago when some observing technique was new may have resulted in > this object making the cut, but all subsequent observations of higher > quality could clearly show that it is not in the range. The absence > of the contrary information results in misinformation and bias. It > behooves us to present the full picture, but on the other hand, each > repository responded fairly with the best of its (limited) knowledge. > > Let's examine a one pass solution and a two pass solution to this. > In a one pass solution one starts with a much wider range to include > the maximum reasonable error, e. Symbolically (O(C=c,P(A)=[R1-e:R2+e]) > and when all of the data are returned, the user can process this > as he/she wishes; either taking a weighted average, or throwing out > outliers and then averaging, or taking the latest or best, and then > compares the result to the desired range of the query. The two pass > system has the query as earlier, with range [R1:R2], and when there is > at least one hit, resend the query with no range set O(C=c,Id=I,P(A)) > to bring back what every repository contains on this object's P(A). > There are pros and cons to either. > > The one-pass is faster and it also returns well for cases where the > data straddle on either side of the range but the average is in range. > However, it suffers from the need to know a priori what the reasonable > range in errors is for every measurement. Who's responsibility > would it be to add that error to the range? Does the user do it or > does a very smart system do it? But, the critical problem here is, > what if early measurements were within the enlarged range, but best > recent measurements are outside? We are back to the original problem. > It appears therefore that we are forced to a two pass system as it > is the only way that one can get a complete response to constrained > queries. In fact one must combine the two methods and allow an > error-bar (for the case of straddling points) on the first search and > follow it up with a second query on P(A) without range. > > One might argue isn't it still possible to have points straddle just > outside the extended range but have an average inside the desired > range? Here, one does have to rely on error bars working sensibly; > if they do, then this would very rarely happen. The alternative to > this would be to require all data on P(A) for all Objects of class C > to be returned and the range be applied only after a full gathering > of data. At this point the whole concept of distributed repositories > falls apart and one would be better off with a super-repository with > all of the data in one place. > > Our conclusion is that a query consisting of several constraints > on properties coupled together by logical operators (and,or) must be > broken down into atomized requests for properties one at a time. First > receiving O(C=c,P(A)=[R1-e:R2+e]) and later receiving > O(C=c,Id=I,P(A)). There should not be, in the initial simple > implementation of VOQL, logical operations sent to individual > repositories of the form O(C=c,P(A)=[R1:R2] AND P(B)=[R3:R4]). > A given repository can not know the ultimate outcome on P(A) or > P(B) so it can not apply the logic. > > Ed > > From owner-voql@eso.org Mon Aug 4 23:44:51 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 h74LiTnB025499 for ; Mon, 4 Aug 2003 23:44:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h74LiTo0025498 for voql-outgoing; Mon, 4 Aug 2003 23:44:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h74LiPnB025478 for ; Mon, 4 Aug 2003 23:44:25 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h74LiOQ08572 for ; Mon, 4 Aug 2003 23:44:25 +0200 (MEST) Received: from po4.wam.umd.edu(128.8.10.166) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAvyaqVq; Mon, 4 Aug 03 23:44:23 +0200 Received: from gsfc.nasa.gov (atlas.physics.umd.edu [129.2.41.47]) by po4.wam.umd.edu (8.9.3p2/8.9.3) with ESMTP id RAA27686; Mon, 4 Aug 2003 17:44:22 -0400 (EDT) Message-ID: <3F2ED268.2020605@gsfc.nasa.gov> Date: Mon, 04 Aug 2003 17:38:48 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas McGlynn CC: "'voql'" , Shenping Huang Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> In-Reply-To: <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tom, The brown dwarf query as you specify it would be categorized as an ADQL (Astronomical Data Query Lanaguage) query according to our discussions at the IVO meeting in Cambridge. Instead of broadcasting a query to the distributed system, this is specifying that property A is to come from data center X and propery B is to come from data center Y. Data center X has only one stored value for A and data center Y has only one stored value of B. So, of course, since this is arranged to not have any conflicts, then there are no conflicts. But this is a very restrictive query. It is artificially constructed, as all demos are, to give a reasonable result easily. But, what if one wanted to do this outside of the area covered by SDSS where there are several competing photometry catalogs (A2, DSS1, DSS2, HD, etc)? What if 2MASS goes much deeper than SDSS so that even in the area covered by Sloan you needed it to be supplemented with the HDF and the Groth Deep Survey? After all a color derived from a null on a quick shallow survey is not very meaningful and one might draw the wrong conclusion here. Seen in another light, there was an enormous amount of knowledge that you drew from to even know to build this query. You knew the coverage of SDSS was large enough to get a few brown dwarfs (because several had been published). You knew 2MASS and SDSS where reasonably well matched in depth so that a null in the blue and a not null in the red would be meaningful. Stepping back, you knew that SDSS was a large survey in optical light and 2MASS was an even larger survey in the near infrared. You knew that it was organized so that you don't get a magnitude for each pass, or yearly. It is good that you knew all of these things so that you could build a great demo. And, it is true that if one did not know all of these things one could formulate a long list of ADQL queries to learn these things. First you query on coverage of sky surveys in optical and infrared. Then, for the overlapping ones, you find pairs that go deep enough. Then you check if they average all passes to give a single best magnitude. Finally, you arbitrarily throw out all surveys except for one blue and one red one that overlap. Hopefully, you have chosen the "best" pair. Then you can do the real query. The idea behind VOQL is that the user does not have pre-existing knowledge of the surveys or catalogs. The user need not know or query for how the data are arranged nor which ones are considered the best. It is my experience that users think they know which are the best catalogs and they are usually 5-10 years out of date. A problem that increases as the rate of data collection increases. It turns out that the brown dwarf problem is an unusual one in that it relies totally on autocorrelation and, even more unusually, the signal is in the nulls of an autocorrelaion. Let me use, as an example, a more typical type of query but along the same lines. We want brown dwarfs that are nearby enough that we do have a reasonable V magnitude (because we want to do optical spectroscopy) of say 20. Then we insist on V-K > 5, so K will be atleast 15 [I actually have no idea what the V-K should be, but you can adjust this to reality as needed]. Now we can ask O(C=star,P(K)<15 AND P(V-K)>5). This can be turned into a search, first, for all stars with K<15. Certainly several catalogs are consulted. At this point for each star with purported K<15 a second pass is required to obtain the Kmag from each catalog that did not respond positively for that star. Then with full information about the K band measurements, weighted averaging gives the final list of bright K stars. Then their ID's are sent to all optical stellar catalogs to get their V mag. One does not query for V-K>5 for each star (one could pass the K mags to each site) because the V mag will be obtained only after a proper weighting algorithm (by the user). There does not need to be another pass on the V mag because, in this case, the first pass queries for full V band info. So, this is a bit messier than my original example with simple constraints on each property, but it ends up with 2 passes on K band and 1 pass on V-band of very simple query. A final note on Ids. Rather than sending Ids for V-mag one could have sent ra,decs but I am assuming that when a new catalogs comes online to the VO that an autocorrelation will be made to some master id catalogs so that a proper identification can be made once and for all. Perhaps a topic for the metadata group? Ed Thomas McGlynn wrote: > I'm confused, no doubt in part because I don't > have the context for the problem, but... > > It sounds like you are concluding that the only queries > on single property at a time need to be supported by VOQL. > While I don't fully follow the discussion, I'd suggest that > all you can conclude is that there are some query services > that need to work the way you are discussing, but I think > these are very complex queries, not the bread and butter > queries that I'd expect astronomers need. > > Could we make this a little more concrete and perhaps you > can help me understand where I've gone wrong. > > In the brown dwarf demo we did a correlation of very red > SDSS objects with very red 2MASS objects. This involved a query > of the form (more or less) > select from xxx where reddest_color is not null and > bluer_colors are null > on both of these tables and then a join between the sets of results. > > According to what you are saying this wouldn't be doable using > VOQL, we'd have to query on each on of the criteria separately?? > But this is what I'd expect to see all the time. > > It sounds like you're assuming all queries have to marshall results > from a host of constiuent tables -- doing some kind of union > of various sources. But I think that joins between tables > are more likely at least in the early stages of the VO. I think > the early VO is going to much more about users being able to easily > find and combine resources, with the users still explicitly > choosing them, then about the VO doing lots of automated stuff and > making substantial decisions on behalf of the user. > > > Tom > > Ed Shaya wrote: > >> We were taking a stab at formalizing what a high level VOQL does >> when we came across several issues that should be brought forth >> to this discussion group. These issues come about because in a >> set of distributed repositories of scientific data there is going >> to be conflicting data with regard to constraints on property values >> and we wish to properly deal with these conflicts in a manner that >> maintains the scientific integrity of the results even if it requires >> some extra processing. >> >> >> Suppose that a query is made for objects of Class C with propertyType >> A with value in range R1 to R2. Symbolically, O(C=c,P(A)=[R1:R2]). >> >> Suppose that some repositories have data on a specific object that >> indicate property A is within range, but at other repositories it is >> out of range. This could come about because different repositories >> have determinations from different astronomers or taken at different >> times or by different methods. And, let's not yet bring up error-bar >> issues, but just deal with the bare measurement value. The response >> from the various repositories is to either have or not have this object >> in the list of satisfying objects. This amounts to a bias in results >> and this bias could be severe. For example, a measurement taken >> years ago when some observing technique was new may have resulted in >> this object making the cut, but all subsequent observations of higher >> quality could clearly show that it is not in the range. The absence >> of the contrary information results in misinformation and bias. It >> behooves us to present the full picture, but on the other hand, each >> repository responded fairly with the best of its (limited) knowledge. >> >> Let's examine a one pass solution and a two pass solution to this. >> In a one pass solution one starts with a much wider range to include >> the maximum reasonable error, e. Symbolically (O(C=c,P(A)=[R1-e:R2+e]) >> and when all of the data are returned, the user can process this >> as he/she wishes; either taking a weighted average, or throwing out >> outliers and then averaging, or taking the latest or best, and then >> compares the result to the desired range of the query. The two pass >> system has the query as earlier, with range [R1:R2], and when there is >> at least one hit, resend the query with no range set O(C=c,Id=I,P(A)) >> to bring back what every repository contains on this object's P(A). >> There are pros and cons to either. >> >> The one-pass is faster and it also returns well for cases where the >> data straddle on either side of the range but the average is in range. >> However, it suffers from the need to know a priori what the reasonable >> range in errors is for every measurement. Who's responsibility >> would it be to add that error to the range? Does the user do it or >> does a very smart system do it? But, the critical problem here is, >> what if early measurements were within the enlarged range, but best >> recent measurements are outside? We are back to the original problem. >> It appears therefore that we are forced to a two pass system as it >> is the only way that one can get a complete response to constrained >> queries. In fact one must combine the two methods and allow an >> error-bar (for the case of straddling points) on the first search and >> follow it up with a second query on P(A) without range. >> >> One might argue isn't it still possible to have points straddle just >> outside the extended range but have an average inside the desired >> range? Here, one does have to rely on error bars working sensibly; >> if they do, then this would very rarely happen. The alternative to >> this would be to require all data on P(A) for all Objects of class C >> to be returned and the range be applied only after a full gathering >> of data. At this point the whole concept of distributed repositories >> falls apart and one would be better off with a super-repository with >> all of the data in one place. >> >> Our conclusion is that a query consisting of several constraints >> on properties coupled together by logical operators (and,or) must be >> broken down into atomized requests for properties one at a time. First >> receiving O(C=c,P(A)=[R1-e:R2+e]) and later receiving >> O(C=c,Id=I,P(A)). There should not be, in the initial simple >> implementation of VOQL, logical operations sent to individual >> repositories of the form O(C=c,P(A)=[R1:R2] AND P(B)=[R3:R4]). >> A given repository can not know the ultimate outcome on P(A) or >> P(B) so it can not apply the logic. >> >> Ed >> >> > > From owner-voql@eso.org Tue Aug 5 19:34:51 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 h75HYXbT006381 for ; Tue, 5 Aug 2003 19:34:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h75HYX5J006380 for voql-outgoing; Tue, 5 Aug 2003 19:34:33 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h75HYTbT006368 for ; Tue, 5 Aug 2003 19:34:29 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h75HYSC27377 for ; Tue, 5 Aug 2003 19:34:28 +0200 (MEST) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA95aOD1; Tue, 5 Aug 03 19:34:27 +0200 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h75HYNIJ012208; Tue, 5 Aug 2003 13:34:23 -0400 Message-ID: <3F2FEAED.6090509@gsfc.nasa.gov> Date: Tue, 05 Aug 2003 13:35:41 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas.A.McGlynn@nasa.gov CC: "'voql'" , Shenping Huang Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> In-Reply-To: <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mail630.gsfc.nasa.gov id h75HYNIJ012208 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 h75HYWbT006376 Sender: owner-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thomas McGlynn wrote: > I think > the early VO is going to much more about users being able to easily > find and combine resources, with the users still explicitly > choosing them, then about the VO doing lots of automated stuff and > making substantial decisions on behalf of the user. Exactly right. The ADQL which is suppose to be ready right away (a month or two was the plan at the last meeting) is about users explicitly choosing resources and explicitly selecting components from the resources. The VOQL which allows expressions that are science-centric rather than data-centric with "lots of automated stuff making substantial decisions on behalf of the user" is to be developed over the next two years or so. We will be presenting the underlying basics of this over the next few weeks. Ed *T**urn-of-the-century architect and urban planner Daniel H. Burnham, whose Chicago-based firm helped make the Windy City skyline famous, said: “Make no little plans; they have no magic to stir men’s blood ... Make big plans, aim high in hope and work.*” From owner-voql@eso.org Tue Aug 5 20:19:23 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 h75IJFbT020308 for ; Tue, 5 Aug 2003 20:19:15 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h75IJFfK020307 for voql-outgoing; Tue, 5 Aug 2003 20:19:15 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h75IJ8bT020257 for ; Tue, 5 Aug 2003 20:19:09 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h75IJ8c00011 for ; Tue, 5 Aug 2003 20:19:08 +0200 (MEST) Received: from lheapop.gsfc.nasa.gov(128.183.16.62) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAALgaiba; Tue, 5 Aug 03 20:19:07 +0200 Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.9/8.12.9) with ESMTP id h75IIqlj019980; Tue, 5 Aug 2003 14:18:52 -0400 Message-ID: <3F2FF51A.8070803@lheapop.gsfc.nasa.gov> Date: Tue, 05 Aug 2003 14:19:06 -0400 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Shaya CC: Thomas.A.McGlynn@nasa.gov, "'voql'" , Shenping Huang Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> <3F2FEAED.6090509@gsfc.nasa.gov> In-Reply-To: <3F2FEAED.6090509@gsfc.nasa.gov> Content-Type: text/plain; charset=windows-1252; format=flowed X-Scanned-By: MIMEDefang 2.35 X-MIME-Autoconverted: from 8bit to quoted-printable by milkyway.gsfc.nasa.gov id h75IIqlj019980 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 h75IJEbT020304 Sender: owner-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Still confused... Are you saying that VOQL and ADQL are completely distinct? My understanding was that this was a multistage development process, so that VOQL needs to support everything that ADQL has, but provides additional facilities. So VOQL needs to be able to support what you are calling ADQL queries. Putting it in concrete terms: surely VOQL must be able to support he brown dwarf demo query, even if only to provide some kind of common transport protocol to the participating sites to whom the query is presented in ADQL terms. [By the by, I used the term 'we' in discussing the brown dwarf demo not to suggest that I personnally had anything to do with it, but just reflecting its role as an NVO demo.] One possible root of my confusion... Is VOQL a language, as its name suggests, or is it a service as I'm sensing from your comments? It seems to me there is a big difference between a query specification -- which is what I'd have taken VOQL to be -- and the services that use that specification and resolve it. All of the original posting seemed to be about how someone might actually resolve a query, not about how a user would present it to the system. E.g., in your posting last night you suggested that someone might want to find all stars with K<20 and V-K > 5. So we need VOQL to encapsulate a query specification something like the SQL select * from object_catalogs where object_type='star' and V is not null and K is not null and K < 20 and V-K > 5 Doubtless the actual specification will be very different but it seems to me that that defines the limit of what VOQL needs to worry about. It doesn't need to worry about how this query is satisfied, just how the user specifies it. There is a very distinct question of how services interpret a VOQL request and return to the user the relevant information. It doesn't seem to me that there needs to be a single answer to this. A simple VOQL interpreter might take this and look only for single catalogs that can satisfy all of the constraints simultaneously. A second VOQL service might try to merge tables together in the ways that I think you've been envisaging. The user will choose which service to use. The first might be faster, the second more complete. Regardless I wouldn't want to limit today how this query is going to be implemented. All the VOQL effort needs to do is to address how this query is to be specified. Or at least that's what I understood. Tom Ed Shaya wrote: > Thomas McGlynn wrote: > >> I think >> the early VO is going to much more about users being able to easily >> find and combine resources, with the users still explicitly >> choosing them, then about the VO doing lots of automated stuff and >> making substantial decisions on behalf of the user. > > > Exactly right. The ADQL which is suppose to be ready right away (a month > or two was the plan at the last meeting) is about users explicitly > choosing resources and explicitly selecting components from the > resources. The VOQL which allows expressions that are science-centric > rather than data-centric with "lots of automated stuff making > substantial decisions on behalf of the user" is to be developed over the > next two years or so. We will be presenting the underlying basics of > this over the next few weeks. > > Ed > > > *T**urn-of-the-century architect and urban planner Daniel H. > Burnham, whose Chicago-based firm helped make the Windy City > skyline famous, said: “Make no little plans; they have no magic to > stir men’s blood ... Make big plans, aim high in hope and work.*” > > > > > From owner-voql@eso.org Tue Aug 5 20:48:20 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 h75ImAbT006944 for ; Tue, 5 Aug 2003 20:48:10 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h75ImASC006943 for voql-outgoing; Tue, 5 Aug 2003 20:48:10 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h75Im3bT006884 for ; Tue, 5 Aug 2003 20:48:03 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h75Im3j02513 for ; Tue, 5 Aug 2003 20:48:03 +0200 (MEST) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_Baa5e; Tue, 5 Aug 03 20:48:01 +0200 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h75IlwIJ015871; Tue, 5 Aug 2003 14:47:58 -0400 Message-ID: <3F2FFC45.8080200@gsfc.nasa.gov> Date: Tue, 05 Aug 2003 14:49:41 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas.A.McGlynn@nasa.gov CC: "'voql'" Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> <3F2FEAED.6090509@gsfc.nasa.gov> <3F2FF51A.8070803@lheapop.gsfc.nasa.gov> In-Reply-To: <3F2FF51A.8070803@lheapop.gsfc.nasa.gov> Content-Type: text/plain; charset=windows-1252; 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thomas McGlynn wrote: > Still confused... > > Are you saying that VOQL and ADQL are completely > distinct? My understanding was that this was a multistage > development process, so that VOQL needs to support > everything that ADQL has, but provides additional > facilities. So VOQL needs to be able to support what > you are calling ADQL queries. > > Putting it in concrete terms: surely VOQL must > be able to support he brown dwarf demo query, even > if only to provide some kind of common transport > protocol to the participating sites to whom the > query is presented in ADQL terms. I suppose there are three things here, a query language that allow queries on astronomical objects and one that allows queries on data objects and one that is the combination of both. The one on astronomical objects must transform into part of the one on data objects. The one on data objects is called ADQL and I guess it is unclear whether VOQL refers to the one on astronomical objects or the sum of the two. Either way we are missing one name. Maybe the one on astronomical objects should be called AOQL and VOQL should refer to the whole. > > > [By the by, I used the term 'we' in discussing the > brown dwarf demo not to suggest that I personnally > had anything to do with it, but just reflecting its > role as an NVO demo.] That's right, you mostly worked on the GRB response demo. Too bad we didn't use that one as an example. > > > One possible root of my confusion... > > Is VOQL a language, as its name suggests, or is it a > service as I'm sensing from your comments? It seems > to me there is a big difference between a query specification > -- which is what I'd have taken VOQL to be -- and the > services that use that specification and resolve it. > > All of the original posting seemed to be about how someone > might actually resolve a query, not about how a user would > present it to the system. I think you need to go to the VOQL archive and see the whole discussion on the language. We created a tentative XML schema and everything. People said "Great, but how in the world are you going to implement it?" So, now we are working on the service that could make use of the language. > >> >> > > From owner-voql@eso.org Tue Aug 5 22:37:48 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 h75KbWbT001842 for ; Tue, 5 Aug 2003 22:37:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h75KbWmk001841 for voql-outgoing; Tue, 5 Aug 2003 22:37:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h75KbRbT001806 for ; Tue, 5 Aug 2003 22:37:27 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h75KbQO18835 for ; Tue, 5 Aug 2003 22:37:26 +0200 (MEST) Received: from lheapop.gsfc.nasa.gov(128.183.16.62) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA_9a4XK; Tue, 5 Aug 03 22:37:25 +0200 Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.9/8.12.9) with ESMTP id h75KbHlj028666; Tue, 5 Aug 2003 16:37:17 -0400 Message-ID: <3F30158B.6090008@lheapop.gsfc.nasa.gov> Date: Tue, 05 Aug 2003 16:37:31 -0400 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Shaya CC: "'voql'" Subject: Re: The issue of conflicting data in a destributed data system References: <3F2EA29E.3020809@gsfc.nasa.gov> <3F2EB12A.5070709@lheapop.gsfc.nasa.gov> <3F2FEAED.6090509@gsfc.nasa.gov> <3F2FF51A.8070803@lheapop.gsfc.nasa.gov> <3F2FFC45.8080200@gsfc.nasa.gov> In-Reply-To: <3F2FFC45.8080200@gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ed Shaya wrote: ... > > I think you need to go to the VOQL archive and see the whole discussion > on the language. We created a tentative XML schema and everything. > People said "Great, but how in the world are you going to implement it?" > So, now we are working on the service that could make use of the language. ... That helps a lot. However I'd be a lot more comfortable with a tiny change... "Now we are working on [a] service that ...." since I really don't feel we should be locking ourselves into how we're going resolve queries right now when we don't even fully understand the issues involved in ADQL. If I understand this properly, the original problem was not in VOQL itself but implementation issues in the resolution of certain classes of queries. Tom From owner-dm@eso.org Wed Aug 6 21:53:37 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 h76Jr65L000713 for ; Wed, 6 Aug 2003 21:53:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h76Jr6Mf000711 for dm-outgoing; Wed, 6 Aug 2003 21:53:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h76Jr15L000640; Wed, 6 Aug 2003 21:53:01 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h76Jr0719997; Wed, 6 Aug 2003 21:53:00 +0200 (MEST) Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAGbaadN; Wed, 6 Aug 03 21:52:59 +0200 Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100]) by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h76JqvD9026800; Wed, 6 Aug 2003 15:52:57 -0400 (EDT) From: Arnold Rots Received: (from arots@localhost) by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id h76JqvRO009174; Wed, 6 Aug 2003 15:52:57 -0400 (EDT) Message-Id: <200308061952.h76JqvRO009174@xebec.cfa.harvard.edu> Subject: Space-Time metadata To: dm@ivoa.net, dal@ivoa.net, registry@ivoa.net, voql@ivoa.net, votable@ivoa.net Date: Wed, 6 Aug 2003 15:52:57 -0400 (EDT) CC: cfa_nvo@head-cfa.cfa.harvard.edu X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-dm@eso.org Precedence: bulk Reply-To: Arnold Rots X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I put pdf and ps copies of my IAU poster on my website: http://hea-www.harvard.edu/~arots/nvometa/STC.pdf http://hea-www.harvard.edu/~arots/nvometa/STC.ps be careful, it's 36 x 56 inches (91.5 x 142.2 cm). Also, I made an update to one of the schemas (including a reference direction to the time frame element). The schemas are at: http://hea-www.harvard.edu/~arots/nvometa/stc.xsd http://hea-www.harvard.edu/~arots/nvometa/coords.xsd http://hea-www.harvard.edu/~arots/nvometa/region.xsd To summarize: these schemas specify the metadata structure for the interwined space, time, redshift, and spectral coordinates, describing the coordinate space volume taken up by a dataset, catalog, query, or resource. Apologies if you get more than one copy of this message; it did not seem to fit one single mailing list. - Arnold -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots@head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-voql@eso.org Fri Aug 8 00:30:04 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 h77MTO94006436 for ; Fri, 8 Aug 2003 00:29:24 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h77MTOdh006435 for voql-outgoing; Fri, 8 Aug 2003 00:29:24 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h77MTJ94006395 for ; Fri, 8 Aug 2003 00:29:19 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h77MTHa01265 for ; Fri, 8 Aug 2003 00:29:17 +0200 (MEST) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA56aODc; Fri, 8 Aug 03 00:29:16 +0200 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h77MT4IJ018190 for ; Thu, 7 Aug 2003 18:29:12 -0400 Message-ID: <3F32D2EF.4060508@gsfc.nasa.gov> Date: Thu, 07 Aug 2003 18:30:07 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql Subject: A symbolic description of VOOQL Content-Type: multipart/mixed; boundary="------------030804000900050806020109" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------030804000900050806020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We have been asked to work on another topic for the next few months, so we wanted to summarize some development we had been working on before it was forgotten. We were headed towards showing that the software for object query could in fact be independent of the scientific field. Just the names of object properties, aggregates, and classes and a set of transforming functions between properties for a given field is needed to make a single package of software and a single query language run for any given field. It is not clear if we got there or not, but we were certainly getting close. Ed --------------030804000900050806020109 Content-Type: text/plain; name="VOOQLsymbolics.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="VOOQLsymbolics.txt" VOOQL (Virtual Observatory Object Query Language) A formal description of a generic query system for distributed data about the property of objects. For the objects and properties here, I have in mind astronomical objects and their physical properties right now, but everything here can hold for data objects (say tables with the properties mostly refering to the various columns) or for medical illnesses and their statistical properties, etc. This is truly a metadata independent system. This symbolic description should help us to discuss query issues, user scenarios, describe use cases, and begin work on implementation issues. VOQL could use VOOQL as a basis for astronomical object and data object query. A general object query contains a logical function, L (and, or, etc) of a boolean grand propery P and a boolean grand function F: Q = L(P,F) The grand property may be a logical function of other grand properties, or it may be the return status of an atomic property array (p_i), or it may be the return status of an atomic aggegate property array (a_i). P = L(P,P) or P = return_stat(p_i) or P = return_stat(a_i). The return status is 0 if no object satisfies the constraints and 1 if one or more do. An atomic property (a property, not derived from other properties) has arguments: input object array (O_i), a property type (pType), a set of modifiers (M) consistent with the pType, a range of values allowed for the pType, an output object array (Ovar_i) which lists all of the objects with pType in range. It returns a status and an array variable for the values from all responding resources (r) of the values of the pType for the array of objects Ovar_i. p_i = p(O_j,pType,M,range_j,Ovar_i) = var_i^r The response can be an array of rational numbers, integers, or strings. On query, the range_i (rational or integer) can be expressed as [R_j1:R_j2] (although usually it is constant range for each member of the array, [R1:R2]) or, for strings, it is a regular expression. The d superscript on var refers to another dimension of the array for results from various data centers. For range >R, we have [R:]. For range 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 h783I694011044 for ; Fri, 8 Aug 2003 05:18:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h783I6CI011043 for voql-outgoing; Fri, 8 Aug 2003 05:18:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h783Hv94011004 for ; Fri, 8 Aug 2003 05:17:58 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h783HvH10818 for ; Fri, 8 Aug 2003 05:17:57 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAxwaiiv; Fri, 8 Aug 03 05:17:55 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id MAA19642 for ; Fri, 8 Aug 2003 12:17:56 +0900 (JST) Message-Id: <5.0.2.5.2.20030808121338.037c7ec8@133.40.4.4> X-Sender: ohishims@133.40.4.4 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Fri, 08 Aug 2003 12:17:55 +0900 To: voql From: Masatoshi OHISHI Subject: Re: A symbolic description of VOOQL In-Reply-To: <3F32D2EF.4060508@gsfc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear All, This discussion group is for VOQL, not for VOOQL. It is beyond our scope, I am afraid. At 18:30 03/08/07 -0400, Ed Shaya wrote: >VOOQL (Virtual Observatory Object Query Language) Wil, Vivek and Naoki are working very hard for the first draft of ADQL which describes queries from a VO portal and individual databases. We also are working to consolidate the SkyQuery and the JVOQL to define SQL-based VOQL. I think these drafts will be distributed to the WG around the end of this month. Cheers, Masatoshi From owner-voql@eso.org Fri Aug 8 18:31:44 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 h78GVQZp021257 for ; Fri, 8 Aug 2003 18:31:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h78GVQop021256 for voql-outgoing; Fri, 8 Aug 2003 18:31:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h78GVKZp021218 for ; Fri, 8 Aug 2003 18:31:20 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h78GVKg16121 for ; Fri, 8 Aug 2003 18:31:20 +0200 (MEST) Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAljayEF; Fri, 8 Aug 03 18:31:18 +0200 Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h78GV9IJ029487; Fri, 8 Aug 2003 12:31:10 -0400 Message-ID: <3F33D069.3040302@gsfc.nasa.gov> Date: Fri, 08 Aug 2003 12:31:37 -0400 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Masatoshi OHISHI CC: voql Subject: Re: A symbolic description of VOOQL References: <5.0.2.5.2.20030808121338.037c7ec8@133.40.4.4> In-Reply-To: <5.0.2.5.2.20030808121338.037c7ec8@133.40.4.4> 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Masatoshi, Sorry, I should not have introduced the new term VOOQL without explaining where it sits in the VOQL architecture that we agreed to at the Cambridge meeting. VOOQL is simply a new name for the high level language that would be developed over the next 2 years or so. I am simply introducing a new symbolism for the VOQL.xsd schema that we came up with several months ago. VOQL should allow users to do both VOOQL and ADQL. But, VOQL will depend on ADQL to bridge the gap to the data center native query language. -------- VOOQL ---- ADQL VOQL ---- -------- resource native query language -------- ADQL I look forward to seeing the ADQL specifications. Ed Masatoshi OHISHI wrote: > Dear All, > > This discussion group is for VOQL, not for VOOQL. It is beyond our > scope, I am afraid. > > At 18:30 03/08/07 -0400, Ed Shaya wrote: > >> VOOQL (Virtual Observatory Object Query Language) > > > Wil, Vivek and Naoki are working very hard for the first draft of ADQL > which describes queries from a VO portal and individual databases. > We also are working to consolidate the SkyQuery and the JVOQL > to define SQL-based VOQL. > > I think these drafts will be distributed to the WG around the end of > this month. > > Cheers, > > Masatoshi From owner-voql@eso.org Tue Aug 26 23:27:39 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 h7QLQRIt023300 for ; Tue, 26 Aug 2003 23:26:27 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h7QLQR2s023298 for voql-outgoing; Tue, 26 Aug 2003 23:26:27 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h7QLPfIt022922 for ; Tue, 26 Aug 2003 23:25:48 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h7QLPdQ22475 for ; Tue, 26 Aug 2003 23:25:39 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAKiai5R; Tue, 26 Aug 03 23:25:38 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h7QLPa620534; Tue, 26 Aug 2003 17:25:36 -0400 Date: Tue, 26 Aug 2003 17:25:36 -0400 From: "Wil O'Mullane" To: openskyquery@eta.pha.jhu.edu Cc: voql@ivoa.net, Edward.J.Shaya.1@gsfc.nasa.gov, szalay@pha.jhu.edu Subject: SkyNodeIterface version 0.4 Message-ID: <20030826172536.A20315@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I have tried to incorporate many of the comments from the weekend in this version.. Some of the requirements have been renumbered - I think this is OK until we get v1 then they should not change anymore of course. I still need to add text about MYDB and authorization etc.. not sure if i get to that before Victoria. We should also discuss the string representation of Regions at Victoria. pick up 0.4 from http://skyservice.pha.jhu.edu/develop/vo/adql/ wil From owner-voql@eso.org Tue Aug 26 23:33:44 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 h7QLXfIt027384 for ; Tue, 26 Aug 2003 23:33:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h7QLXfYK027378 for voql-outgoing; Tue, 26 Aug 2003 23:33:41 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h7QLX3It027134 for ; Tue, 26 Aug 2003 23:33:03 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h7QLX3N23884 for ; Tue, 26 Aug 2003 23:33:03 +0200 (MEST) Received: from spacemsg3.dom1.jhuapl.edu(128.244.198.38) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAkKayPU; Tue, 26 Aug 03 23:33:02 +0200 Received: by spacemsg3.dom1.jhuapl.edu with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 17:33:01 -0400 Message-ID: <69252A37C3A6A844930C8C8AC4116DE95CAF9D@spacemsg3.dom1.jhuapl.edu> From: "Weiss, Michele" To: "'voql@ivoa.net'" Subject: Special Session at the Fall 2003 AGU Date: Tue, 26 Aug 2003 17:32:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36C19.9F516640" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Weiss, Michele" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36C19.9F516640 Content-Type: text/plain Call for papers for the U06 Special Union Session at the Fall 2003 AGU. Papers are solicted for a special Union Session U06: Virtual Observatories in Space and Earth Sciences. This is an area of particular interest to the VO community because of the need to deal with diverse and widely distributed data sets. Abstracts are due electronically by September 4, 2003 at 1400 UT. Description: During the next decade, progress in Earth and space science will benefit from an integrated data environment. That integrated data environment should ideally offer easy and simultaneous access to multiple sources of high-quality observations, long-term geophysical records, model output, and data services across traditional discipline boundaries as well as enable the use of tools that facilitate the use of those data. The ready availability of cheap, powerful microprocessors means that we can revisit the concept of a data "archive": We can form "virtual observatories" that enable users, in principle, to meet many of their data requirements through one interface. Within the AGU community, there are many approaches to addressing all or part of the virtual observatory concept. We solicit abstracts from science users, information technologists, and current service providers to (1) highlight achievements and lessons learned from current systems and services, (2) identify the scientific, technical, and programmatic data challenges facing the Earth and space science community, and (3) describe emerging architectural and technical solutions. Convener: Larry Paxton The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd Laurel, MD20723USA 240 228 6871 larry.paxton@jhuapl.edu Peter Cornillon Univ Rhode IslandGraduate School Oceanography Narragansett, RI02882USA 401 874 6283 pcornillon@gso.uri.edu Tim Ahern IRIS Data Management Center 1408 NE 45th Street #201 Seattle, WA98105USA 206 547 0393 x 118 tim@iris.washington.edu Michele Weiss 240-228-4806 The Johns Hopkins University Applied Physics Laboratory Laurel, MD 20723-6099 ------_=_NextPart_001_01C36C19.9F516640 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Special Session at the Fall 2003 AGU

Call for papers for = the U06 Special Union Session at the Fall 2003 AGU.

Papers are solicted = for a special Union Session U06:  Virtual Observatories in Space = and Earth Sciences.  This is an area of particular interest to the = VO community because of the need to deal with diverse and widely = distributed data sets.  Abstracts are due electronically by = September 4, 2003 at 1400 UT.

Description:

        During the next decade, progress in Earth and space = science will benefit from an integrated data environment. That = integrated data environment should ideally offer easy and simultaneous = access to multiple sources of high-quality observations, long-term = geophysical records, model output, and data services across traditional = discipline boundaries as well as enable the use of tools that = facilitate the use of those data. The ready availability of cheap, = powerful microprocessors means that we can revisit the concept of a = data "archive": We can form "virtual observatories" = that enable users, in principle, to meet many of their data = requirements through one interface. Within the AGU community, there are = many approaches to addressing all or part of the virtual observatory = concept. We solicit abstracts from science users, information = technologists, and current service providers to (1) highlight = achievements and lessons learned from current systems and services, (2) = identify the scientific, technical, and programmatic data challenges = facing the Earth and space science community, and (3) describe emerging = architectural and technical solutions. 

Convener: =       Larry = Paxton
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd
Laurel, MD20723USA
240 228 6871
larry.paxton@jhuapl.edu

Peter Cornillon
Univ Rhode IslandGraduate = School Oceanography
Narragansett, RI02882USA
401 874 6283
pcornillon@gso.uri.edu

Tim Ahern
IRIS Data Management = Center
1408 NE 45th Street #201
Seattle, WA98105USA
206 547 0393 x 118
tim@iris.washington.edu



Michele Weiss
240-228-4806
The Johns Hopkins University Applied = Physics Laboratory
Laurel, MD  20723-6099

------_=_NextPart_001_01C36C19.9F516640-- From owner-voql@eso.org Mon Sep 22 23:29:46 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 h8MLTUBi018779 for ; Mon, 22 Sep 2003 23:29:30 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8MLTUcD018778 for voql-outgoing; Mon, 22 Sep 2003 23:29:30 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8MLTRBi018751 for ; Mon, 22 Sep 2003 23:29:27 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8MLTRU25213 for ; Mon, 22 Sep 2003 23:29:27 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAX3aGpX; Mon, 22 Sep 03 23:29:25 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h8MLTOA13111; Mon, 22 Sep 2003 17:29:24 -0400 Date: Mon, 22 Sep 2003 17:29:24 -0400 From: "Wil O'Mullane" To: voql@ivoa.net, openskyquery@eta.pha.jhu.edu Subject: SkyNode Interface Version 0.5 Message-ID: <20030922172924.A12215@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: There has been a suggestion to close OpenSkyQuery mailing list and move this to VOQL. As of This mail please use VOQL@ivoa.net to comment on the SkyNode specification. The Latest Spec0.5 is now posted on the twiki at http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL We will work on producing some precise WSDL for the SkyNode next. As always more comments are welcome. wil From owner-voql@eso.org Wed Sep 24 03:58:32 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 h8O1viB2028135 for ; Wed, 24 Sep 2003 03:57:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8O1vib8028134 for voql-outgoing; Wed, 24 Sep 2003 03:57:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8O1vBB2028049 for ; Wed, 24 Sep 2003 03:57:11 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8O1vBU07588 for ; Wed, 24 Sep 2003 03:57:11 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAeyay0o; Wed, 24 Sep 03 03:57:05 +0200 Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id KAA23314 for ; Wed, 24 Sep 2003 10:57:03 +0900 (JST) Message-Id: <5.0.2.7.2.20030924105131.00d3d7e8@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 24 Sep 2003 10:56:59 +0900 To: voql From: Masatoshi OHISHI Subject: A Working document has been submitted In-Reply-To: References: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear VOQL friends, Our first working document toward VOQL has been submitted by Wil O'Mullane (JHU) yesterday, and please download it from our TWiKi page. In the coming Strasboug meeting we have a half-day slot for VOQL, and I hope to discuss intensively on this document. I also hope to ask several people to provide brief report on their progress toward future XML-based VOQL. Cheers, Masatoshi OHISHI From owner-voql@eso.org Wed Sep 24 12:12: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 h8OACDKm019954 for ; Wed, 24 Sep 2003 12:12:13 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8OACDdw019953 for voql-outgoing; Wed, 24 Sep 2003 12:12:13 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8OABaKm019734 for ; Wed, 24 Sep 2003 12:11:36 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8OABZL28972 for ; Wed, 24 Sep 2003 12:11:35 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAb6a4K4; Wed, 24 Sep 03 12:11:34 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.21) id 1A26bo-0006KC-6Q for voql@ivoa.net; Wed, 24 Sep 2003 11:10:56 +0100 Received: (qmail 16863 invoked from network); 24 Sep 2003 10:11:07 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 24 Sep 2003 10:11:07 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" , , Subject: RE: SkyNode Interface Version 0.5 Date: Wed, 24 Sep 2003 11:10:50 +0100 Organization: University of Leicester Message-ID: <007101c38284$2184ef80$6124d28f@gnowee> 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: <20030922172924.A12215@skysrv.pha.jhu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Also, all the schema pictures are unreadable - it might be better to just include http pointers. *Real* comments to follow :) Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 22 September 2003 22:29 > To: voql@ivoa.net; openskyquery@eta.pha.jhu.edu > Subject: SkyNode Interface Version 0.5 > > > There has been a suggestion to close OpenSkyQuery mailing > list and move this to VOQL. As of This mail please use > VOQL@ivoa.net to comment on the SkyNode specification. > > The Latest Spec0.5 is now posted on the twiki at > http://www.ivoa.net/twiki/bin/view/IVOA/Iv> oaVOQL > > We will > work on producing some precise WSDL for the > SkyNode next. > > As always more comments are welcome. > > wil > From owner-voql@eso.org Wed Sep 24 12:31:51 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 h8OAVfKo025941 for ; Wed, 24 Sep 2003 12:31:43 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8OA4TcL017390 for voql-outgoing; Wed, 24 Sep 2003 12:04:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8OA3JKm017002 for ; Wed, 24 Sep 2003 12:03:19 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8OA3JG28454 for ; Wed, 24 Sep 2003 12:03:19 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAsSaqK3; Wed, 24 Sep 03 12:03:18 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.21) id 1A26UN-0005yf-PW for voql@ivoa.net; Wed, 24 Sep 2003 11:03:15 +0100 Received: (qmail 14985 invoked from network); 24 Sep 2003 10:03:35 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 24 Sep 2003 10:03:35 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" , , Subject: RE: SkyNode Interface Version 0.5 Date: Wed, 24 Sep 2003 11:03:18 +0100 Organization: University of Leicester Message-ID: <006a01c38283$141e42c0$6124d28f@gnowee> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006B_01C3828B.75E2AAC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20030922172924.A12215@skysrv.pha.jhu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C3828B.75E2AAC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Wil, When I try to load the schema into XmlSpy I get an error message - see attached. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 22 September 2003 22:29 > To: voql@ivoa.net; openskyquery@eta.pha.jhu.edu > Subject: SkyNode Interface Version 0.5 > > > There has been a suggestion to close OpenSkyQuery mailing > list and move this to VOQL. As of This mail please use > VOQL@ivoa.net to comment on the SkyNode specification. > > The Latest Spec0.5 is now posted on the twiki at > http://www.ivoa.net/twiki/bin/view/IVOA/Iv> oaVOQL > > We will > work on producing some precise WSDL for the > SkyNode next. > > As always more comments are welcome. > > wil > ------=_NextPart_000_006B_01C3828B.75E2AAC0 Content-Type: image/jpeg; name="error.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="error.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCACbA5gDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDA+Jfx M1X4g67LqDXdx/Ygn3WGnyZWONFLBC8YYgyYJ3Nk9SAduAOc/tP/AKh9h/35/wDr1h6Ahj0u2Eqn GNxAPJBJPX6Gvez8KNG8dR6L4h+Hsy2Wj3TCHVraacyPpsirlzluWH49SpHB+X97niMHlWHpRqR5 IW3tomlfXzfTu/O1/wA3lSrYutNxfNK+3V69PQ8g/tP/AKh9h/35/wDr0f2n/wBQ+w/78/8A169O 8A+HPA/jr41x6RoGmTDwtY2zGRpbiQvqARcGbPBTc7LwMDC5GN2K6DwN8HNO1bx1480+/snisdNL 22mhpGYRySZaJ8qwLbU2naT/ABjPNcdbiPAUE3VjJNQU7Na2bSWl99Vp2ZtDKcRN2i0/e5d+tr/d pueI/wBp/wDUPsP+/P8A9ej+0/8AqH2H/fn/AOvXSx+HtPHwSm8TTWkqaqPEAslkLnHleRuK4ztP zdxzx1xXFV7OExGHxfP7LXlfK/WyenlZo4a9CpQ5efS6v+LX5o0P7T/6h9h/35/+vR/af/UPsP8A vz/9eu0+DXgey8SjVte1mDUrvSNEjSWax02Fpbq9ds7YY1Xnnacnjr1XlltfFDSfD13f6HpPg34a +LvDWpX1w0QXWAYkuM7QqoHkcltzDJyoAPOcjHHPNcLDGfVLNyW7W0dL663210T8zeGBrSoe3uku nd9NDgf7T/6h9h/35/8Ar0f2n/1D7D/vz/8AXrqdY+EfxE0i2iuL/wANTJFLOlurJcQyfO7bVBCO cAnAycDkc8ism08D+K7vxdP4Tg0eVtatwxlti6LsCjJJYnbjBBBzg5GM5FdUMZgakXKFWLSu21Ja Jbvfp1MJYevFqMoNN+T67feZn9p/9Q+w/wC/P/16P7T/AOofYf8Afn/69ZysrKGUhlIyCDwRS12e yh2MLs0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8/ /XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UP sP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69 H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofY f9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P 7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9l DsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9 es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w /wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f 2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/ 35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/t P/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UO wczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16 z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/ AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/a f/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/f n/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/ +ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7B zM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrP oo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8A vz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/ 9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f /r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6 h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHM zQ/tP/qH2H/fn/69H9p/9Q+w/wC/P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+i j2UOwczND+0/+ofYf9+f/r0f2n/1D7D/AL8//XrPoo9lDsHMzQ/tP/qH2H/fn/69H9p/9Q+w/wC/ P/16z6KPZQ7BzM0P7T/6h9h/35/+vR/af/UPsP8Avz/9es+ij2UOwczND+0/+ofYf9+f/r10fgLw 9rXjO/mttK07So44FDT3NxEwiiznaCVBJJwcAAngnoCRxlevfs8XZtI75vtHkJLq1lE2X2h8219t U+uW24HrjvXgcU46plWUV8ZQSc4K6vdrdLuu56WU4WOMxkKNR6O97eSb/Qpn4dasDg3Ohf8Ago1L /wCRazJvDdtDM8M3iXwfHLGxV0ezvwykcEEG34NfQPi2JvHPh69j8B6wbTWNLkMN5ZRsI2lKnpvI DKcg4YEKeQfUcZ460Xwz4I8Ez2HiNhr/AIz1aNWMrSlmtccKwY8hVxj1fGPujj8mocd5zNc0+Sz2 sn+v5f8ABt93DhfL27Pmv2v/AMA8r8P/ABE1v4SeOrEtdNcaNcus1xa2bM1rc2zkK80SMVHmfu8A nawZCrYG5SVyXxwjUWngqXJ3Nokin0wL+7/xNFfaPAYfOaVPFYiNpuKvy6XPITlgJzoUneKb3KWg Qfao9PtvOhg84Rx+bM22NM4G5j2A6k+le3WfxE8HeBLqDwV4bsbPxF4dZmTxHqcsayf2kWBUpFzt aNMnk5B5AzksfIvDXhfxLqmkQzaZ4e1e+iRVjd7eykkVW2g7SVBwcEHHuK0v+EF8b/8AQneIf/BZ N/8AE19VmGGwmOUKeIq2it43Su+jfXTou+vQ+bw9Wth3KVKF29nbZdbep6ZBeeEfAGl/EOfwn4z0 i6vLqKG10hbe43zokrZdV7syBuSpYDaC+CCK6rxp8ZNCh1DwTLot7bGa8vItT8Qi2kz5SeUIjHLj +L5twB5/cjI5FeE/8IL43/6E7xD/AOCyb/4mj/hBfG//AEJ3iH/wWTf/ABNeRUyHAYiqquIxCnLr qldKKVt+65vU7I5hiKcOSlS5Vr33b3+7T9T2a+07wF4g8I6v4XHxL8K+H7WPxVPf28i3MMkU0DRD aqbpEGAXGSpIBQrXjfxD0LQ/DmvR6doPi/TvFEDWyzPdWRUpGxZhsO13Gflz1zz0HGW/8IL43/6E 7xD/AOCyb/4mj/hBfG//AEJ3iH/wWTf/ABNduVYSnl0rRxalDqvd1dkr336GWNryxa1oNS6PXRXb tbbqd98DDotvod7eW3xV/wCEE8QGfy5Dd+Q1tNBgFSEmwrPnfzkkDPAzmu+vviBpJuvDvg4eM4fH +vSa9azvqcVpFFb2sayI2FaIbCxX5cKzH5m3EDivA/8AhBfG/wD0J3iH/wAFk3/xNa/grw34w0Lx dpOs3HgjxJPDZXcc8kaabMGZVYEgfL1xXHmWU4XFVpYh4hN7pe5e62XN8VvK+2hrhMbWo0lSVJ9r +9bXrba57D8Stf0rwhpfjtZviOfEmo665tbXREu97aYWZt3y+Y/lhVbn5UB2AdSoFDxj4v05fgkP GT2XkeLPFen/ANiTS42tKibklnGMY+UZDDjcY1PQV5R4p8OeONf8S6nrZ8CeIrX7fdy3Hkmwmcxh 2JCk7BkjNanju18feKbfQLI/D/XbGy0LTlsraJbCdyzHb5khOwYLbE+XnG3rya8nD5HQ9jh1Oabb i5u8VyxUfgsnrdpJvd7s762YVPbVXGLsr8ujd25aS8rbpbdDzZVVVCqAqgYAA4Apa6L/AIQXxv8A 9Cd4h/8ABZN/8TR/wgvjf/oTvEP/AILJv/ia/QPr2F/5+R+9Hy/1et/K/uZztFdF/wAIL43/AOhO 8Q/+Cyb/AOJo/wCEF8b/APQneIf/AAWTf/E0fXsN/wA/I/eg+r1v5H9zOdorov8AhBfG/wD0J3iH /wAFk3/xNH/CC+N/+hO8Q/8Agsm/+Jo+vYb/AJ+R+9B9XrfyP7mc7RXRf8IL43/6E7xD/wCCyb/4 mj/hBfG//QneIf8AwWTf/E0fXsN/z8j96D6vW/kf3M52iui/4QXxv/0J3iH/AMFk3/xNH/CC+N/+ hO8Q/wDgsm/+Jo+vYb/n5H70H1et/I/uZztFdF/wgvjf/oTvEP8A4LJv/iaP+EF8b/8AQneIf/BZ N/8AE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/wBCd4h/8Fk3/wATR/wgvjf/AKE7xD/4LJv/AImj 69hv+fkfvQfV638j+5nO0V0X/CC+N/8AoTvEP/gsm/8AiaP+EF8b/wDQneIf/BZN/wDE0fXsN/z8 j96D6vW/kf3M52iui/4QXxv/ANCd4h/8Fk3/AMTR/wAIL43/AOhO8Q/+Cyb/AOJo+vYb/n5H70H1 et/I/uZztFdF/wAIL43/AOhO8Q/+Cyb/AOJo/wCEF8b/APQneIf/AAWTf/E0fXsN/wA/I/eg+r1v 5H9zOdorov8AhBfG/wD0J3iH/wAFk3/xNH/CC+N/+hO8Q/8Agsm/+Jo+vYb/AJ+R+9B9XrfyP7mc 7RXRf8IL43/6E7xD/wCCyb/4mj/hBfG//QneIf8AwWTf/E0fXsN/z8j96D6vW/kf3M52iui/4QXx v/0J3iH/AMFk3/xNH/CC+N/+hO8Q/wDgsm/+Jo+vYb/n5H70H1et/I/uZztFdF/wgvjf/oTvEP8A 4LJv/iaP+EF8b/8AQneIf/BZN/8AE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/wBCd4h/8Fk3/wAT R/wgvjf/AKE7xD/4LJv/AImj69hv+fkfvQfV638j+5nO0V0X/CC+N/8AoTvEP/gsm/8AiaP+EF8b /wDQneIf/BZN/wDE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/ANCd4h/8Fk3/AMTR/wAIL43/AOhO 8Q/+Cyb/AOJo+vYb/n5H70H1et/I/uZztFdF/wAIL43/AOhO8Q/+Cyb/AOJo/wCEF8b/APQneIf/ AAWTf/E0fXsN/wA/I/eg+r1v5H9zOdorov8AhBfG/wD0J3iH/wAFk3/xNH/CC+N/+hO8Q/8Agsm/ +Jo+vYb/AJ+R+9B9XrfyP7mc7RXRf8IL43/6E7xD/wCCyb/4mj/hBfG//QneIf8AwWTf/E0fXsN/ z8j96D6vW/kf3M52iui/4QXxv/0J3iH/AMFk3/xNH/CC+N/+hO8Q/wDgsm/+Jo+vYb/n5H70H1et /I/uZztFdF/wgvjf/oTvEP8A4LJv/iaP+EF8b/8AQneIf/BZN/8AE0fXsN/z8j96D6vW/kf3M52i ui/4QXxv/wBCd4h/8Fk3/wATR/wgvjf/AKE7xD/4LJv/AImj69hv+fkfvQfV638j+5nO0V0X/CC+ N/8AoTvEP/gsm/8AiaP+EF8b/wDQneIf/BZN/wDE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/ANCd 4h/8Fk3/AMTR/wAIL43/AOhO8Q/+Cyb/AOJo+vYb/n5H70H1et/I/uZztFdF/wAIL43/AOhO8Q/+ Cyb/AOJo/wCEF8b/APQneIf/AAWTf/E0fXsN/wA/I/eg+r1v5H9zOdorov8AhBfG/wD0J3iH/wAF k3/xNH/CC+N/+hO8Q/8Agsm/+Jo+vYb/AJ+R+9B9XrfyP7mc7RXRf8IL43/6E7xD/wCCyb/4mj/h BfG//QneIf8AwWTf/E0fXsN/z8j96D6vW/kf3M52iui/4QXxv/0J3iH/AMFk3/xNH/CC+N/+hO8Q /wDgsm/+Jo+vYb/n5H70H1et/I/uZztFdF/wgvjf/oTvEP8A4LJv/iaP+EF8b/8AQneIf/BZN/8A E0fXsN/z8j96D6vW/kf3M52iui/4QXxv/wBCd4h/8Fk3/wATR/wgvjf/AKE7xD/4LJv/AImj69hv +fkfvQfV638j+5nO0V0X/CC+N/8AoTvEP/gsm/8AiaP+EF8b/wDQneIf/BZN/wDE0fXsN/z8j96D 6vW/kf3M52iui/4QXxv/ANCd4h/8Fk3/AMTR/wAIL43/AOhO8Q/+Cyb/AOJo+vYb/n5H70H1et/I /uZztFdF/wAIL43/AOhO8Q/+Cyb/AOJo/wCEF8b/APQneIf/AAWTf/E0fXsN/wA/I/eg+r1v5H9z Odorov8AhBfG/wD0J3iH/wAFk3/xNH/CC+N/+hO8Q/8Agsm/+Jo+vYb/AJ+R+9B9XrfyP7mc7RXR f8IL43/6E7xD/wCCyb/4mj/hBfG//QneIf8AwWTf/E0fXsN/z8j96D6vW/kf3M52iui/4QXxv/0J 3iH/AMFk3/xNH/CC+N/+hO8Q/wDgsm/+Jo+vYb/n5H70H1et/I/uZztFdF/wgvjf/oTvEP8A4LJv /iaP+EF8b/8AQneIf/BZN/8AE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/wBCd4h/8Fk3/wATR/wg vjf/AKE7xD/4LJv/AImj69hv+fkfvQfV638j+5nO0V0X/CC+N/8AoTvEP/gsm/8AiaP+EF8b/wDQ neIf/BZN/wDE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/ANCd4h/8Fk3/AMTR/wAIL43/AOhO8Q/+ Cyb/AOJo+vYb/n5H70H1et/I/uZztFdF/wAIL43/AOhO8Q/+Cyb/AOJo/wCEF8b/APQneIf/AAWT f/E0fXsN/wA/I/eg+r1v5H9zOdorov8AhBfG/wD0J3iH/wAFk3/xNH/CC+N/+hO8Q/8Agsm/+Jo+ vYb/AJ+R+9B9XrfyP7mc7RXRf8IL43/6E7xD/wCCyb/4mj/hBfG//QneIf8AwWTf/E0fXsN/z8j9 6D6vW/kf3M52iui/4QXxv/0J3iH/AMFk3/xNH/CC+N/+hO8Q/wDgsm/+Jo+vYb/n5H70H1et/I/u ZztFdF/wgvjf/oTvEP8A4LJv/iaP+EF8b/8AQneIf/BZN/8AE0fXsN/z8j96D6vW/kf3M52iui/4 QXxv/wBCd4h/8Fk3/wATR/wgvjf/AKE7xD/4LJv/AImj69hv+fkfvQfV638j+5nO0V0X/CC+N/8A oTvEP/gsm/8AiaP+EF8b/wDQneIf/BZN/wDE0fXsN/z8j96D6vW/kf3M52iui/4QXxv/ANCd4h/8 Fk3/AMTR/wAIL43/AOhO8Q/+Cyb/AOJo+vYb/n5H70H1et/I/uZztFdF/wAIL43/AOhO8Q/+Cyb/ AOJo/wCEF8b/APQneIf/AAWTf/E0fXsN/wA/I/eg+r1v5H9zOdrsvCn/ACTzXv8AsLad/wCib2s/ /hBfG/8A0J3iH/wWTf8AxNbfhjQfGOmQ3VjqHgHxNe6bdvHJLDFaSwyCSMOEdXMbAECRwQVIIY8A 4I8TiP2eOy2rh6M4uTtb3ktmn38j1MllLCY6nWqxfKt9H1TR6/Z3Ph74N+FIrq1ms9a8W6rbh0eN 98UcTYIII/5Z9D2LkdgPlp+PofDHxH8GXPjzTJ4NK1zT41/tO2lfAk7KPcngI38XCnnpwf8AYsn/ AESj4gf+BX/3FR/Ysn/RKPiB/wCBX/3FX5F/qvmPZf8AgcP/AJL+vQ/QlnmAT5uaV/8ADL7tjh/j PGr+GfCrEnMekFhj1+33Y/rRSfF208Sf2PHc6p4Z1XRtNtY0s7Jbq2kUKvmNJtMjKu9yzSMeB1OA AAAV+o4Kg8Pg6NKTTaik7O6vr1Pj6lZV69Wok7OTavpofSn7Kf8AyT2+/wCwl/7bW9eu15F+yn/y T2+/7CX/ALbW9eu1+WcS/wDI1r+v6H0mUf7lT9Aooorwz0gooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooA8L/bb/5I/bf9hiH/ANFy0Uftt/8AJH7b/sMQ/wDo uWiv1ThX/kWx9X+Z8tmX+8y+X5Gv+yn/AMk9vv8AsJf+21vXrteRfsp/8k9vv+wl/wC21vXrtfD8 S/8AI1r+v6Hr5R/uVP0CqOs3Jt7UBGAkkO1eefcj/Per1cN43uNSvdN1mTRJQl7FZTRae5xjz9jb W5yPvY68Yr8+4qzX+z8C1CSjOo+WLeiV95PsorW/oezh6XtJeS1E1vxFe+HLnTLyQxtoz3S2+olx zAkh2pMpyAAJCgbORtYnjbz3VfM/7Mr6/wCJfAOvQeLrq91TT7yUxQ/bZzKzo0eJFBYlgCCpx05y OpNewfBvX7rVPDc2j6u7HXNAnOn329stLtGYp+eSJIyrbsDJ3ccUuHlUwNbE5LXqqpUwzXvJ3vGW vXX3W+V32vFE1GpwjVStzdDuKKKK+mMgooooAKK4zW/EGuXPjweD/D8ulWM8WnjUJ7u/he43KXKB I4VeMnnBL78LkAr8wNaH9tz+HtDgl8ZXlm99LcNDF/ZdnM5uCSxQRwDzJC2wZZV3Ywxzgca+ybim t3suu9vz+fkZuok2n0/4c6OiuZn8eeFYNGt9Wm1Qpa3F19jTdbSiQT9PKaPbvR/9llB5HqKpx/E3 wc/2pVvdQ8yzfZeQnSLsS2vyhg00Zi3RIQQQ7gKcHB4OHHD1ZXtF6eT/AK6r7xupBbs7KisLxN4t 0Dw5FFJqt5IvnRvKiW1tLcyGNBl5NkSswRQRlyNoyMnkVrWN3a31lBe2VxFc2s8ayQzROGSRCMhl I4II71DhJR5mtBqUW7Jk9Fc5F438My6wNKjv5TM07WyS/Y5hbPMvWJZ9nlM4II2hicgjGQRXM/DX xTfeK/FuuzzajrVvbWd9Lb2unHS2jtTFGka7nmeAN5pcs2wSAgY+XANaRw9SSbtZJX67afnf0JdW OlnfW39fcek0VwHjm+8ZQa/JHoZvhaBtNVfKsllTEl4FuGyUJOIs55+UEnjgixpvjq0tLPUbvxNq mmpCutyabZGxt7gk4VdsbhlyZd24fKNpyoGTUQpuceaPmrddGl+LasNzSk0+ltemqb/BLU7eisPT PFmgahpd/qcV+YLbTmZb43kElq9sQoc+YkqqyfKwbJAyDmuU8QeP4bvUNCtvD1zfwPLq9pDex3el zWzPBNvxgTxqSDsblemOoqlQqOSja2qXpfa4e0jZtPo39256PRWDL4w8OxaRe6tJqOLKxujaXMnk yfJMCFK425PLDkAjnrUfibxdo+izyWE0t7Nfi3M3k2WnT3jxqchWcQo+wEg4LYB2tjODjPkna6i3 6ddL6fLX0G5RW7/rY6KivPfCXj+xtPhn4Z1nxXqMsmoahpaXU3kWUk0jgIGklMcCEqgyMttCjIGR kVH4q1nxTPqaXPha5ubjSpl0treW1tUnhkSW7AncPtO4CHkkHCqS3HBG08NOFX2cv5uW/S6dt+xk sRGVL2i10Tt11t/mejUVU1bULfTLF7y6W4aNMZW3tpJ5D7KkaszH6A1gD4heERpupahPqctpFpjI t8l3ZT281vvxsZopEVwrZ4bbg4PPBxlGnKSvFX6fNmzklozqqKxNB8U6Jrdzd2tjcXC3FoiSTRXV nNbOqNu2uFlVSyHa2GGRwea5PWPiBb33ifwjY+HLq+a11DVXiuZm0uZLe5hFvMw8ueSMI4LKpBjY 5AyCRmtI4arKXLyu/pt6mU68IR5rno9Fcja6/cf8Jn4lkvrsWfh7RbSBHkmMax+cwaSVyfvAKnl8 kgfMeOM1asPHHhu8t72dLu6gFlb/AGqeO7sLi2lEP/PRY5UVnXjqoIzxUOnK3NbRavyv3LU03Y6S isfw34k0fxHE0+jTz3VuESRbj7LKkMiuMjy5GUJJjGCFJ2nhsHiuV1DUPGcfjaKKFrxdJOtCKTNk piW1FjJITv2Z2mYKC2eoCg84KdOUZOM9GlfX5f5idRcvNHX0PQqK4XQPiBYR+G9HufEmpWcuo6ob g2yaTZXUqXAjkYARoUMhYIBkY5IYjirmm/EjwfqJi+x6jdSrJcG1Z/7NuQkE2/Z5czGPEL7uNshU 8g9CCdPq1XW0W+mz9AdSC3Z11FctrHxA8KaTe39jd6hO11pwVryG3sZ7h4UZSwdljRiEwOX+6DgE gkCreq+L/D2nW1jPLeyXK6hF51othbS3jzRYBMipCrsY8Mvz42/MvPIzCpVGk+V67ab9dPlqNzir 3ZvUVzd5468KWsGmzS6ujLqiO9gIoZJGuNoyyoqqSX7bMbieACeK5GP4j3ur3vi7SdKsdUS6srcH SmGhXaOXMLOfN8yPapyvyhgu7oA2apYeq4ykouyTb07Oz/H9QU43SutT1KiuV8A3HiKe616PXnum igvYo7Ez2yxFovssDMwKqoYGRpMnsQRxjAn13xt4e0O5eHVpr+1jjZVkum0y5NrGWIA33AjMSjJG SWAHfFJ0Zc6hHV2T09E/wvqTCqpQ53p6nR0Vyur/ABC8J6VfXtleajP52nqr3vk2FxMtsjDcHkZE KomM/MSF4PPFaOveJ9G0VrWO8nuJJrsM0EFnaTXc0irjc4jhVm2DIy2MAsozyMpUajtaL120366f Ip1IK93sbNFeW6X401u4+D+teIY3nutU/tC9tNNVoFhfd9qeG3RldVC4+QHeMjB3ZOa67VfFuieH Gh0/WNQup7yO2WW4aCxlnKJ082XyUKxKxDYLbQcNj7pxcsPNS5ba9uu1393UiNeElzdP6X4nSUVz mp+N/DOn6hHp82ovNeTWou4be0tZbmSaEnAeNYlYuOcnbnA5PHNS+OZ9Wh8P79DNwt29zAm6GESO sbSqHO1lI4UtyRx1rPkkrXVk3b8bfh1NOZa26f8ADm9RXB+H/GS6TpscPja+nt9UvNR1BLGB7JxJ NDFPII1RETLkxhCoALPkY3E86ur+PfC2kG3GpahPa+dDHO3mWU4+zRyNtR7j5P8AR1J4zLs5Df3T ilRm2lFXv2/H7tfuJVWNrt29Tp6K53xL4v0bRpnsZZb2e++zmcQ2Onz3jxochXcQo+wEg4LYB2tj ODjn/CXj+xtPhn4Z1nxXqMsmoahpaXU3kWUk0jgIGklMcCEqgyMttCjIGRkU4YepOHOlpdL1vzbd 7cruS60FPkv/AFp/mehUV5drvjWXU/iPp3h/SNZ1Sy0s6Z9t+2abpxulunkeMRZcwSIsG3eTICBy PmGK19A+IFhH4b0e58SalZy6jqhuDbJpNldSpcCORgBGhQyFggGRjkhiOKp4aoop236a36//ACLK VSLb8v8Agf5o7qisKPxd4ek8MnxGuoY01XMZdoZFk8wP5Zi8or5nmbxt2bdxbgDNY194nk12HS7j whd3UkQ1R7bUVWzZZYNkbkxyxypuiO4J94KcMMdQaylTnFNuL0dnpsxqpFrR9LnbUVgfD241e58B aHd+IjKNWl0+GS+86EQuspQFwyAAKQc5GBj0rF174kaLb6JqlzpRvZ7u1sZrq38zSbsQTiMhSyP5 YWVdzLyjHg5zjmnOlKMpRWvL2HCSmova/c7miuO0Px9pt34Y07Vbu01sS3MKGRINAvnIfYrMVURF tmW4flTzgnBrK1P4o6aniHwzHpZm1HR9XguJZJ7XTLq4kGxeFURqSGDAhlKllwcha1eErKfJyu92 vmk2/wAmQq0HHmv/AEz0aiudvPG3hiz16PRLnUjHeSTJb5NvKYUmddyRPMF8tJGGCEZgxyuB8wzQ vfib4JspJxdavLHHbXf2O5uDY3Bt7ebcF2yzBPLj5YcswGDnOOazjQqyaUYt31WnT+mU6kErtnY0 VjaF4m0fWprmGylukltlV5UurKa2bY2cOBKillO0/MMjjrWfYfEHwhfG8Fvqx/0S1N4xe1mjEtuC QZoSyDzo8j78e4cjnkZTpTV7p6b+XqNTi2knudTRXLad498NaoWj027uppDZtewBtPuEFzCuMvCW QCYDcv3N3UVj+BPiXYav4Ktda1iK9t7p22PHDo93iVy7hVhXYWmOFywTdtwScCr+rVVe8Xpbp3ul +Ka9dCfawez/AKX/AA56DRVDQdXsdc01dQ05p2gZ3j/fW8kDqyMUZWSRVZSGUjBA6Vw3gz4h2hud WsvEWpTmePXpbG3kFjIYYlLKsUbyonloSWwN7AnI65FTCjOcnCK1XTrul+o5TjGPM3p/wG/0PSKK 5zXfG3h7Q7l4dWmv7WONlWS6bTLk2sZYgDfcCMxKMkZJYAd8U/UfGWgWGrLpk89405kiiZ4NPuJo Y3lYKivKiGNCSy8Mw4YE8EUlSm0movXbzG5xW7OgorO8R63pfh3R5tX1m7W0sYMebMyswXJAGcAn qaq6D4p0TW7m7tbG4uFuLREkmiurOa2dUbdtcLKqlkO1sMMjg80lCTi5paLdg5JNJvc26K53Q/Gv hvWtQjsdOvpnlmRnt2ls5oY7pV6tDI6BJh3zGWGOenNaOva1p+h2a3WoyTBXkEcccFvJPLIx/hSO NWdj1PAOACTwDTlTnGSi003/AMMCnFq6eho0VzreNPDy6HBrDXN2Le4uGtoYjYXH2mSZWZWjW32e aWBRsgJkBSegzXKRfEmybx/sF5qEmiS6Q00VtHpM7T+clwY3YxCLzgF2kHIwOD3FVGhUk7Jd/vSb a9bITqRSbvtb8XY9NorDu/Fvh+20Kx1pr8zWeoBPsRtoJJ5Lncu4COONS7naCSApIAJOADVF/iF4 QFlpl5HqzXEeqq7WK21rNNJOU++ojRC29ecoRuBBBHBwvY1NuV7226729QVSD6nVUVyOm/EjwfqJ i+x6jdSrJcG1Z/7NuQkE2/Z5czGPEL7uNshU8g9CCbeu+NvD2h3Lw6tNf2scbKsl02mXJtYyxAG+ 4EZiUZIySwA74p+wq83Lyu/oCqQaumdHRXM+GfEF3qni/wATaRNHbi20p7dbd4wdzCSMsdxJIPI4 wBU/iHxj4f0G8+x6jdXHnrF58q29lNc+RGSQHlMSMIlJBwz4B2tjocSqcm1FK7aT+9X/ACG5xSu2 b9FYet+K9C0hLRrm7lna8QyW0djay3kksYAJkCQq7FBlcvjaNy88jOfc/ETwrbWsF5c3Oow2U8cU q3smkXa2qrJt2F5jF5cY+YZ3MNuecU40aktov7uwuePc6yivNx8R5H1/xdpPlGA6TGrWVxLpd2YA fJZ2M8iqVC5Xjpu/h3Eit+LxhYaf4e0S4166WXUdQsknMWl2Vxc+YdimR44kRpRECw+ZgMblBwTT 9hU003Sa+auvwQOpFbvv+Gn6nU0VzV7478LWkGmTPqbTLqqM9ittbSzvcbRlgqRqzFhzlcZ4PHBr V8P6zpuvaWmpaVcGe2d3TLRtGyujFWVkcBlYMCCGAIIqXSnFczi7Apxbtc0KK5zXfG3h7Q7l4dWm v7WONlWS6bTLk2sZYgDfcCMxKMkZJYAd8VyGq/FRrG/8Z2hsbtzo0aGxaPRbyVHYxlj5ropULkDB yoIycnrTjQqTV4xb0vturpad90PminZvrY9SoriNG+JPh+XQtHutVuLqyvdRhzHBJplzG08qxK7r CjJukHzfLt3builiDWD418daxbaL4pvtP1LT7aDThYNan7LLHcwCU5k+0LOgUZUrgAZX5t2DWjwt WNTkatrby3UfzZEasJR5k/P8LnqtFczbePPC1xNfwpqMiSWFqbyZZrSaItbg4M0W9B50ef449w5X n5hm1eeKtFgjscXTvJqNq91ZIlvI7TIqbyQFXP3SDg4J6YzWM4ThfmT0/wAm/wAk38mXGSlaz3/r 9UblFcD4C+I9jrHgNPEWt+dYPGP9IJ025iiZmkZEWHev75jgDbGWO4gYyQK6rw14g0nxFZS3ekXT TJDM0EySQvDLDKp+ZJI3AdGHBwwBwQehFXVw9Sk5KS2dn6kxqQlaz3NSiuc13xt4e0O5eHVpr+1j jZVkum0y5NrGWIA33AjMSjJGSWAHfFQav8QvCelX17ZXmoz+dp6q975NhcTLbIw3B5GRCqJjPzEh eDzxSjRqStyxbvtpv/VxucY3u9jqqKxte8T6NorWsd5PcSTXYZoILO0mu5pFXG5xHCrNsGRlsYBZ RnkZyPhHrt94j8Kz6nfzyTP/AGpfQxGSDyXWJLiRI1KbVIIUAEMN3HPOaFRm4OdtCXVjzKN9X/w5 2FFc0fHXhVdItNVfVClpeah/ZsLPbyqxufMMfllSu5TvUjLAAeuKp+JvF62+r2mlaRe2CXa6ta2d 8t9bXG0pL8xSJ0XaZdgJGTtGRuxkZSpTbSt1t+X+a+9F80e/n+f+TOxorya38YeIn+y7tRzv8atp bfuY+bUY/d/d/wDHvve9dV8YNbvvDvgG+1fTrtbS4geL98yqwVTIobO4EdCetUqMny/3ml96i/8A 25fiJySbXa/4Nr9GdfRWBovjDw9rGq3Gl2N8/wBsgh+0GOe2lg8yHO3zYzIqiWPOPnQsvK8/MMt8 O+NPDXiDUn07StRM1ysP2hFe3liE8O4r5sLOoE0eRjfGWXkc8jMujUV7xenkCqRfU6Giud1vWL20 8aeH9It7jTEt7/7Q1zFOkpuHVIyR5JUbBhtud5HGcc1VvfiL4Qs74WlxqNyCbtbJZ10+4e3ecuE8 pZ1jMbMGOCA3BDZxg4IUpztyJu/b1t+YSnGPxO39XOsorlB8Q/CJv3shqU5eO8FjLILGcwxXBYKI 3l2eWhJZQNzDORjOaueIfGPh/Qbz7HqN1ceesXnyrb2U1z5EZJAeUxIwiUkHDPgHa2Ohw1RqO1ov XbTfS+ny19AdSCum9jfornNT8b+GdP1CPT5tRea8mtRdw29pay3Mk0JOA8axKxcc5O3OByeOaW88 beGLPXo9EudSMd5JMlvk28phSZ13JE8wXy0kYYIRmDHK4HzDIqNR7RfXp23+7qDqQW7/AK3Oiorz /wCK3j6z0Lwt4ki0m6vTrVhYSOklrpk1zFbTeWWQSyLG0SH7rYcjAIJGCKseB/Fup6z478R+HryK 1FtpVpYywyIhEjtMjl95zg8qMYA79atYao6bqW0/rb7yPbw5+TqcH+23/wAkftv+wxD/AOi5aKP2 2/8Akj9t/wBhiH/0XLRX6Zwr/wAi2Pq/zPnMy/3mXy/I1/2U/wDknt9/2Ev/AG2t69dryL9lP/kn t9/2Ev8A22t69dr4fiX/AJGtf1/Q9fKP9yp+hn6/e/YtOdlOJX+RPqe/4VyiTCF44FQHb/rCfXv+ X9K0vHjTWluNUZJ5La2TLCCF5nU56hEBZu3QHpXnmp63pmoaZd6fPp/ilYrqB4HMfh+/VgrqVJB8 ng4PWvwXjHLs2zbMuWGHqSpQsk4wlJa2beitfyv0Wx9ThKuGpUvfmk33aRN8K7ew0fwq0Ol6nZat E2oXMhuba7E6spkPlqWHAYR+WCBwMcVNf3Nv4Q+I2n+LTKItK1SNdL1Vt21I9zZtp3AH8L7oiTjA lXkAGuQ+GOn6F4F0SbTrOx8S3Ek8vmTXDeG9QVpMZ25HllRjJHygcYyM8nW8b67aan4M1TTB4f8A E9+Z7WSNLdfD16C7MMDlogBg4OcjGMjnFdNDL82wPFEsZh6NarTnOzlKlKPNGfxXTVla91eyTSeh i6mHq4RQnOMZJdJJ2a2/rtoe80VgfDqfWrnwFoU/iKLytXewiN4uMHzNoySMAKx6lQMAkgZAzW/X 6vOPLJxvex5kXdJhRRRUlHE+O5vCk+qx2niTwpqt9LbQiWz1C20We6MTMxyIZrdWkhkUopyCh5Uq SQccd4Ss/Emjy6L4q16012+02K6v1t4LiKS71CxtbgoYWlQB5XIKsuASyrKAw+Vsez0V0wrqEVG3 46a3vZdHq9dTGVLmd7njU2latfaxBrsWj6hFa6h4ztr2KOS2kSVYEt44jNKh5jBZD94LwFJAzWnf 6XqbXPxSK6deEX1rCtoRA3+kEW7AhOPm5OOM816lRUSq3pumlpa3ytBf+2L7y4R5ZKXb/OT/APbj xuXSNV0zUtE1a6u/E2l2U/hy2sJJNI0yO7mhmjGTHLEbeWRQwY8gAAphsErn0fwfp0Nj4K0/TbOS /eBLQJC1/GI7jaR8vmKFXa2COCoI6EZzW7RVYiv7eDi1a7fbq2+19Lvr8r6kUqXs3e/b8kv0PHre 21CXwTofw/GhanHq9hqVp9oleykW0CQXKytcC4CrE25V3hVO7c20qDkDrfhNZXllZ+IVvLSe2Muv 3UsYljKb0O3DDPVT2PSu0oolXvzWXxXv6vlvby91afiEaXLbXa34X/zCvF7XRdYH2TOk342+Pmu2 zbvxBx+96fc/2unvXtFFRRqOlPmXl+ElL9DSceaPL/WzX6nkeveHtav9R8fG20uebzbrTrm3jkUI t6sOHeNGcbTnbt9MnkjrV7xXq7eKtR8NrpWieIVSw1yznuJLvSLi2UK3mZx5iKSF2/McYG5eea9O oqo1kuW6+Fxa+SS19eVdrEuF767pr77/AOZ4Tr9trEHhHxd4YXw3rtxf3GvteQmGxd4ZLdpYiJFl +43ugJcYJ24BNdet0+geNvFiXXh3VZZNX+zvY3dlp8lwtyPKMflNIilYtjZ/1rKo3k5xk16PRROr GdL2bWlrb+UV/wC2r8fkcj5nK/W/4t/qeC+FND1rRdM8L6hqE/irR7eXwxb2Ex0vS0up4Jkyxjli a2lkUMG6gAAphsErn2DwPYwab4R0uxtZNQkt4rdRE1/GI7gp1G9Qq7WwRwVBHQgHNbVFaYjFOve6 tdt9Orb7X0u+vyvqZ0aHsra30S+5Jfocx8T5tet/Bt3N4ca5W9R4mc2sSyziHzF84xIwYNJ5e7aM HJxwa8f1rRbm8ufF8mg6N4vns5tP0yKCXVYb2Sa4kS5lMmz7RmTABBIwAOTjByfoeilh8S6C0XVP 7raPy007XfcdWgqj1Z5l4x0TVtS8deIPsdjO6XXhOS1hlKlY3mMhxHvPy7vYms+TUG1Wf4dxWHhj XNPi0e9R76KXSpbeKxUWU6BNzKqsAfl3JlBxyNy59dqtqdla6lp1xp97F5ttcxtFKm4ruVhgjIwR x6VEK/JFK2q2++T/APbvwQ6tJVL3e/8Akl+h5dYaNqOt/B241O3tIbvUtZvxrbwJKG+0xiZXji3u MEmCOOPnA9CBzR4wN34u1C71TSNG1hLay8N31q7XenT20ss05iKRRxyKrP8A6skkKRnaAea9VtYI bW1itbeNYoYUEcaKMBVAwAPYCpaJVIvmSXe3lePL/wCk2t28xxptNN+V/VO/5mR4Lhlt/B2iQTxP FNHp8CSRupVlYRqCCD0IPatK6Ba1lABJKEAD6VLRWVeXtpSk+t/xLpx9nFJdDxvwBo2r2118ODc6 VfQizg1IXJkt3XyCxbaHyPlznjPWo9S0XWH+F/i+zTSb9rm48SSTQwi3cvJGZYiHVcZK4BORxwa9 ooro+tP2ntLf1z8/56EezXLy/wBfDynk2n6/b6P8RvH8M2naxeSTm08lbHTprkO3ksNpaNSIzyOX Kg54PBw7wtYXvgS+0m91jR72W3fw9b2DnTbN7w2k8TFmj2QoX2tuwHA25jGcZGfSLDR9OsdTv9Tt bfy7vUCjXUm9j5hQbV4JwMA9gKv1KqxXLp0Sfyi46dt336aWumSpuTev9XT/AE/rc8g8I6FrNp4o 8I3lzpV1BE91rF5IvlsRbJcO7xrIeQjEMCQTwxI7V0Phv7RpXxY8Tw3unaisWr/ZZbK6jtJJLdwk TBw0igrGQR0crnIxnNd9RSda+ltLNffLm/O3qvvCNPlWnr+Fgrw74wRazqEHjXTtTtfF99I9oU8P WukwXP2R0eHDGRoAEdvMDZWZj8u3avzHPuNFKhV9lPn/AK6bfdb0bXUdSHOrM8li0nVRbfEgHTL0 G80+2S1HkN+/YWzKQnHzEHjA71Lory+GPEOj6rqvh7VZIJvC1taLdWmmy3UlvLGQXgZIkaRN2VOS AuUwTkceq0Vf1i8m2t7fhFx/UlUrQUU9r/mn+h4r4Rs9Qubjw94d1DTpbJZPEOq61dW15lJDFFcu 0OEGQ372WF8524XIJyK6Wa5m8LeKPFMl9o2rXqayY57GawsJLoSFYhGYWMaHyyCNwMhCnzDhuDju E0rT01qTWltl/tCSAWzTZJPlhiwUDOAMnPHXj0FXamdWNTSS0aaaXnbbftH7iYUeTZ7PT/g/ezyv 4YeHdY0LxZpFvqNjJGLTwhb2csqKzQrMsi5jVzkEj65wM16pRRSq1nVd35/i2/1NIU1BWXl+CS/Q 4vxPZXk3xU8H3sVpPJbW8V6JpljJSMtEAu5ugyemetcn4p0a4tfFfihNV1LxdZ6XriRvGdD0qO9S ZRH5bxOVtZZI2GMjJAIfg5DY9gop063JZNXVmumzfN1TW/kwlBvVO2t/wseY6bI/hfxP4ktbvw/r VxJqcVr9ivbfT2uDdBYfL8uSSJdkRVgT+8KKPMJGBk1yfhTQ9a0XTPC+oahP4q0e3l8MW9hMdL0t LqeCZMsY5YmtpZFDBuoAAKYbBK596orSGJUW243va/yUo9V2l56+Whk8Pe1na3+af6HlvgrQ5tN8 aQm0t9Yk0xPCqwQXN/beXIx87cEfCKFfaR8uAw7gHNZvgDRtXtrr4cG50q+hFnBqQuTJbuvkFi20 PkfLnPGeteyUVKxDXTv+PP8A/Jv7jT2a/L8OX/5E8Tl8Pa6dCuryO31a0Nj4xn1BxbWyNctbkbfN hjljcSY3bwApJ2kLk4Fd78NrS2jGrahb6j4kv3vLlWml1rTxZuXWNR8kfkQnbt2jO3BI4OQa6+il 7f8Adezt2106KK7X+ynuvmHs/wB5z3/q7f6jJwpgkDIXUqcqOrDHSvGNO0jWFg1Xw34WvPElz4aO iXkaafrGlm2W0uGYGKKGaWNHdcF1C5dVUcsPlr2qis4T5Yyj3Vunn5eemzXfctxvKMl0PHjqWo3G i+Eba5tfGFhoEFkbXV4LHTbuK7F1HFGY1JiTzvK4kBeI7SwUbiCQcbwTZaloTeFdcu9A8Qx6fbar rPnI1lPcXUCTSSGFpIwGlbcMfMA3JyTzmveqK6njd9N276973+dnZPoku2vOsMlbXbb5f1f7zxi2 0G4t9R1HQta1TxnbLc62b22i07SYprS4DyrJG7Ti1by8NhWEkikbM/dINJqWi6w/wv8AF9mmk37X Nx4kkmhhFu5eSMyxEOq4yVwCcjjg17RRWaxPK4tLZLt0cXfRf3V38rbGnst7vdt/fzf/ACR5n4v0 DVdY8ea/DaQTRR3vhR7OG6ZCIhK0nC7yCM98c/Sufj0ubUPD86yXPji41iz0G5tl0+90eOG3hLIq tEkkdrGsp3BQvlu2QMjIzXtlFQq1qTp23Vr6d5eX95r9d704XqKpfb/7X/5FHmMOlak2ufDlvsF0 qWukTRXLmFgsDm2VQrnHynPGD3rF0GytH+GulaJr1l4v0fVdBvjKlzYaTPJLbzebKVeMrFIkqMhI O0Ou18NjNe0UVo8U5O7XW/8A5NKX/tzX3ejlUUo8vlb8Ev0OY+GEniCXwdbyeJrm4ur8zTbZ7i0W 2llh81vKZ4lACMU2/LgEcbgDkV59qWi6w/wv8X2aaTftc3HiSSaGEW7l5IzLEQ6rjJXAJyOODXtF FZxrctX2iXb8JKXT0KcLw5W/6s1+p4d8YItZ1CDxrp2p2vi++ke0KeHrXSYLn7I6PDhjI0ACO3mB srMx+XbtX5jnU1Oy1DTvFVvc+EbvxPYate3ViNUsTpLSaddRptEkhmePZE3lZBZZAxCAbS22vXaK 1hi3CMY20S8rPbo11td93rdaWylhlKTlfXX+vl0OL+Ndleah8O761sLSe7uGlgKxQRl3IEqk4A54 HNY/i/QNV1jx5r8NpBNFHe+FHs4bpkIiErScLvIIz3xz9K9MornjO0eX/F/5NHlOhq/4fg7nmVtP c+IdV8FWlr4f1TTZNDuDcagLuxlgitQttJD5cchASUlnAHll1K5PTFb/AMT7DTb3S7GS/k161ltL xLi0vdGtJLi4tpVBw2xI5CVILKQUIIYg9a66itJ1uaoppWs7/O9/63876mMKKjFx8rHkui/8JRaf 8Iv4r8UQ6nq4tDfW08qaZtu1ilk/cTtaxIXB2IqlVAZRJllGGxp6JLc6z8TrnX4dI1e1sJ/D7wRt e2MluxdbkjBVwCCQu4A4O0g45r0eipnVUumvvfdJPpbe7e1l0sXGDjdX3t+DT/Q8O0nQtcsPDPgj VZv+Eg0yPTo7yC8/s+wSa8t/NkJR/IkhkZl+Xadi7gHz93JrY8P6K9v4x8I3mnjxDfWIl1Oaa71S x8iRHkXneoij8sM2doZVJzxkYr1mitpYtvW2vvdtpXv0vu+9vIhUbde34Hi+paLrD/C/xfZppN+1 zceJJJoYRbuXkjMsRDquMlcAnI44NVvjBFrOoQeNdO1O18X30j2hTw9a6TBc/ZHR4cMZGgAR28wN lZmPy7dq/Mc+40VNLEunbTb/ACiv/bfubQ6lJTvfq/1b/X8EeWeFtSHhrxr4nk1bS9fWO8SyNvJb aJd3KPshIb5oomAIJxgmrMGotoWueI7640TXLqDX0hu9PltdKmldx5IQwSKsYaFlI3fvdo/eHnhg PSqKmpUhU+KO65Xr00200ei7hGk4pJPb+v1PJfCGnah4Cn0W61zS724hPhu2013060kvTazxEs0e 2JWk2sGwH5X90MkEjPP/ABLm1jX9F8VpqWmeOJXvNNVvDun2VpdRxBJYAWE4gAUyiQMGjmY4AAVc k596orSOKtU9o1rr17u+nZ9L9m1u7k/V1y8t9NPwVv68/uPHLm11Kyu/HWmzaPqzSa1pUDafLDYy yxSsls4dC6KQjgjG19uSQFyTWnoguvC2raTrep6Tqk1pc+G7WxLWlhJcy2s0Q3FHijQyKHDdcbQY 8HBIz6hRUPEJu7W9vwTjp8n967aD9jaKint/mn+aPIPCOhazaeKPCN5c6VdQRPdaxeSL5bEWyXDu 8ayHkIxDAkE8MSO1dX8JrK8srPxCt5aT2xl1+6ljEsZTeh24YZ6qex6V2lFS619LdGvvlzf8AuNN JW87/hb9Tw74wRazqEHjXTtTtfF99I9oU8PWukwXP2R0eHDGRoAEdvMDZWZj8u3avzHOkbDU4NS8 baPJpOpedrumQf2dMtpI8ErLbOrI0qgrEwIxiQrkkYzXr9FU8Rej7K2lrflr82k33d++kxpctT2l 9f6/4Y8n8Ni81HXvh3cppGsWyaZYT2t99r0+WDyJRbIMEuoBBPAYEqxBwTg1mePNI1mWL4jPbaNq Nybm4057VIbdmNwExu8vs2O+OnfFe10U5Ypup7RL+ufn/PT0HGklHlf9aWPLvFkN14y1W7m0fR9R WOz0G+tPOvrKS0Mk83l7YoxKqlh8hJYfKPl5OeKGgtqGq+IfAAj8P65axabpdxa3k15YPAkM32ZV 2HcATz0cAo3IViQcewUVMasYxcVHS1t+6l/8m/w36jg273/rT/5FfieG2Gm6xJ8OdA04WPiDT9Q8 M6p59+kWngy+WZJR5luZYninIDCTCbmwAANxAr0P4bWltGNW1C31HxJfveXKtNLrWnizcusaj5I/ IhO3btGduCRwcg119FVPE88ZK2rd+nW1+l7XWmvrcSpWknfbT8/8zw74wRazqEHjXTtTtfF99I9o U8PWukwXP2R0eHDGRoAEdvMDZWZj8u3avzHOvFpOqi2+JAOmXoN5p9slqPIb9+wtmUhOPmIPGB3r 1qiplXvR9lbS1vy19Xa77ttjhSUaqqdbnlWivL4Y8Q6Pquq+HtVkgm8LW1ot1aabLdSW8sZBeBki RpE3ZU5IC5TBORxv/Bm1vrTwndrqFhdWE0ms6jMIbmPa4V7qRlPoQQQQQSCOQSK7ainVxHOnpq7/ AJt/r/XWY0Emnfb/ACt+h4rL4O1rV/F3inw7cR3kGh2zXOo6bfSQndHd3USKht2wATERctkHIMqd xmk0vTte1PS9B8Q3+javBqOpeMFv7y1uIDvs4kzCoICjbGFjU5PXduz81e10URxDTi7bcv4O/wCN l9yG6MdfO/4q36ni9rousD7JnSb8bfHzXbZt34g4/e9Puf7XT3rsfjhaXt78NtQg0+xur+53wskF tGXkfEqkgAewrt6Kj2zXJb7LT+5RX/tppyptt9b/AItv9TzDxRaXXjrWbn+x9Pv7SO30O9svtl/Z SWn76cxhUQSoGYfISWAKjC9c8Hw5shNrWlT3uoeNG1LTrB4Gs9R0mK3tLYEIroJkto0kwyrtKO2Q MjIya9Poqo11CDhFafJtfF5f3ntbprvfN0ryUm/60/yX9WtxHi6wvbn4neE7mC1ne3hgvlmmWMmO ItFhdzAYGT0z1rz/AFG9a0+FWi+FJvDuq6bqNlrVglyjae6W4I1GPMgm2iKTzCQ3yMzEuSRwxHu9 c1Z+B/DdrqkeopbXsksVw9zFHcalczQRSsSxdIXkMatliQQoxnjFXh60IOPP9lpr1UnL9WvuJr0n UjJLqmvvVjzzUtF1h/hf4vs00m/a5uPEkk0MIt3LyRmWIh1XGSuATkccGujmuZvC3ijxTJfaNq16 msmOexmsLCS6EhWIRmFjGh8sgjcDIQp8w4bg49ForL2ilDkktLWfpaK8/wCVPbuaODvzJ63v+Lf6 nlfww8O6xoXizSLfUbGSMWnhC3s5ZUVmhWZZFzGrnIJH1zgZrMt9AuLbU9S0HWtU8Z263Otm9tot N0qKezuA8qyRuZxat5eGwrCSRcBM/dINez0VqsW+fnku/wCMua+t9n/V9SHQXLyp9vwjy/keKeID d2Xw+8f+El8La02r38uoSW5tNMllivVlQskvnIvl524Xazb/AJAoBJVa6r4f6V9k+JHirUWttVie 6sdNQmex8q3JjjkB8qXcfMOT8w2rt46549BoqfrFqbglukvut/l/Ww/Y3qc/r+LueF/tt/8AJH7b /sMQ/wDouWij9tv/AJI/bf8AYYh/9Fy0V+l8K/8AItj6v8z5zMv95l8vyNf9lP8A5J7ff9hL/wBt revXa8i/ZT/5J7ff9hL/ANtrevXa+H4l/wCRrX9f0PXyj/cqfoFFFFeGekFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHhf7bf/JH7b/sMQ/+i5aKP22/+SP2 3/YYh/8ARctFfqnCv/Itj6v8z5bMv95l8vyNf9lP/knt9/2Ev/ba3r12vIv2U/8Aknt9/wBhL/22 t69dr4fiX/ka1/X9D18o/wByp+gUUUV4Z6QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFAGN4g8TaVod5a2d6NQlubuOSWGGy024vHZIygdisKOVAMiDJx94VR/4TjR/+gd4r/wDCV1L/ AOMUah/yVfQv+wBqn/pRp1P0K31HVPD1jqDeJ78SXlosxe3jtNgMiSHKYWRcDzU2/PIP3EfzODIZ O5UqKpxlK92u/m1/K+xg5Tcml+Xp5+Yz/hONH/6B3iv/AMJXUv8A4xR/wnGj/wDQO8V/+ErqX/xi tKbS76TzNniTVYt+/bsjtvk3ebjGYj93zExnP+ojznMnmE2l30nmbPEmqxb9+3ZHbfJu83GMxH7v mJjOf9RHnOZPMm2G8/v/APtB/vP6X/BM3/hONH/6B3iv/wAJXUv/AIxR/wAJxo//AEDvFf8A4Sup f/GK0ptLvpPM2eJNVi379uyO2+Td5uMZiP3fMTGc/wCojznMnmE2l30nmbPEmqxb9+3ZHbfJu83G MxH7vmJjOf8AUR5zmTzC2G8/v/8AtA/ef0v+CZv/AAnGj/8AQO8V/wDhK6l/8Yo/4TjR/wDoHeK/ /CV1L/4xWlNpd9J5mzxJqsW/ft2R23ybvNxjMR+75iYzn/UR5zmTzCbS76TzNniTVYt+/bsjtvk3 ebjGYj93zExnP+ojznMnmFsN5/f/APaB+8/pf8Ezf+E40f8A6B3iv/wldS/+MUf8Jxo//QO8V/8A hK6l/wDGK0ptLvpPM2eJNVi379uyO2+Td5uMZiP3fMTGc/6iPOcyeYTaXfSeZs8SarFv37dkdt8m 7zcYzEfu+YmM5/1Eec5k8wthvP7/AP7QP3n9L/gmb/wnGj/9A7xX/wCErqX/AMYo/wCE40f/AKB3 iv8A8JXUv/jFaU2l30nmbPEmqxb9+3ZHbfJu83GMxH7vmJjOf9RHnOZPMJtLvpPM2eJNVi379uyO 2+Td5uMZiP3fMTGc/wCojznMnmFsN5/f/wDaB+8/pf8ABM3/AITjR/8AoHeK/wDwldS/+MUf8Jxo /wD0DvFf/hK6l/8AGK0ptLvpPM2eJNVi379uyO2+Td5uMZiP3fMTGc/6iPOcyeYTaXfSeZs8SarF v37dkdt8m7zcYzEfu+YmM5/1Eec5k8wthvP7/wD7QP3n9L/glLRfGeg6vr50G2fUodTFqbz7Ne6V dWjGEOELjzo1BG5gOP6GuiryLwxePqPx903UJZIpJLrwP5zPFt2MWntySu15Fxzxtdx6Mw5PrtY1 YxVnFWvfrfaTXZdi4t9f60TCiiisSwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA PC/22/8Akj9t/wBhiH/0XLRR+23/AMkftv8AsMQ/+i5aK/VOFf8AkWx9X+Z8tmX+8y+X5Gv+yn/y T2+/7CX/ALbW9eu15F+yn/yT2+/7CX/ttb167Xw/Ev8AyNa/r+h6+Uf7lT9Aooorwz0gooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOY1D/kq+hf9gDVP/SjTq0vCEvneEtHm83zvMsI G8zzfM35jU53+ZLuz6+ZJnrvb7xzdQ/5KvoX/YA1T/0o06tLwhL53hLR5vN87zLCBvM83zN+Y1Od /mS7s+vmSZ672+8eyr/Bh6frIxh8b/rojVooorjNgooooA878RWkfib4uW3hzWUjutDstHa9bT5F LQ3MzSoqtKudrhApKqwIBOeoFYHjnSrPwpqOpaZoCxafpOq+G9Qln0uEhIFmi8rbNHEBhDh2DbcB srkEgGu98TeFpL/XrLxLo2oR6XrlnC9ss8lqJ4ZoXZS0cqblZhlAVKupB7kZBzZvAt5qTapf6/r4 vtWvdOl02CWC1MNtZwyYLeXCZGJZiqlmZyTtAG0Zz0ud6CjzbKV1rq3zWfbrHd9PJGUY2q81uq18 la/n0f3+px/wfkh8ez2l5rfmxQeG7e0jsNDuY9jRyGBSLyZTkOSd3ldlCk/f+77RXFS+BXi1Hwxq 2mav9i1PRLVbGaX7NuS+ttqh43UMD1QMp3Hawzg12tXjasKtRzhs76fr89+6enRNxh4ShBRl/Xl8 v+D3CiiiuM6AooooA8d8GS+d8cdHm83zvM8CBvM83zN+ZrY53+ZLuz6+ZJnrvb7x9irx3wZL53xx 0ebzfO8zwIG8zzfM35mtjnf5ku7Pr5kmeu9vvH2Ktqu0f+3v/S5ER3fy/JBRRRWJYUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHhf7bf/JH7b/sMQ/+i5aKP22/+SP23/YYh/8ARctF fqnCv/Itj6v8z5bMv95l8vyNf9lP/knt9/2Ev/ba3r12vIv2U/8Aknt9/wBhL/22t69dr4fiX/ka 1/X9D18o/wByp+gUUUV4Z6QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHAfEPWr jw3430HWl8Pa9rMH9l6haMNLsHuTG7zWTrv2g7QRE+PXFcvD4/voLRbWDw98WEjSMxxltD811GJQ vzyQMzlfMTlyxPkRlixMnmez0V0e1i4xi76K2jXdvrF9zPlabat+P+aPHZviPqMnmbPDnxTi379u zw8vybvNxjMB+75iYzn/AFEec5k8wm+I+oyeZs8OfFOLfv27PDy/Ju83GMwH7vmJjOf9RHnOZPM9 ioqean5/+Sf/ACA7S8vx/wDkjx2b4j6jJ5mzw58U4t+/bs8PL8m7zcYzAfu+YmM5/wBRHnOZPMJv iPqMnmbPDnxTi379uzw8vybvNxjMB+75iYzn/UR5zmTzPYqKOan5/wDkn/yAWl5fj/8AJHjs3xH1 GTzNnhz4pxb9+3Z4eX5N3m4xmA/d8xMZz/qI85zJ5hN8R9Rk8zZ4c+KcW/ft2eHl+Td5uMZgP3fM TGc/6iPOcyeZ7FRRzU/P/wAk/wDkAtLy/H/5I8dm+I+oyeZs8OfFOLfv27PDy/Ju83GMwH7vmJjO f9RHnOZPMJviPqMnmbPDnxTi379uzw8vybvNxjMB+75iYzn/AFEec5k8z2Kijmp+f/kn/wAgFpeX 4/8AyR47N8R9Rk8zZ4c+KcW/ft2eHl+Td5uMZgP3fMTGc/6iPOcyeYTfEfUZPM2eHPinFv37dnh5 fk3ebjGYD93zExnP+ojznMnmexUUc1Pz/wDJP/kAtLy/H/5I8dm+I+oyeZs8OfFOLfv27PDy/Ju8 3GMwH7vmJjOf9RHnOZPMJviPqMnmbPDnxTi379uzw8vybvNxjMB+75iYzn/UR5zmTzPYqKOan5/+ Sf8AyAWl5fj/APJHjfw9urvWvjXHrEfhrxPpenW/hiSxEmsWU8bFxPAVBkl5dioJySWOCT617JRR Uzkmko7Lvq9W2+i6vsNJ6t/10CiiisygooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KAPC/wBtv/kj9t/2GIf/AEXLRR+23/yR+2/7DEP/AKLlor9U4V/5FsfV/mfLZl/vMvl+Rr/sp/8A JPb7/sJf+21vXrtfl8t7eLGsa3dwEX7qiQ4H0H4Cj7bef8/dx/38Nc+ZcKxx2KniPbcvM725b2+f MvyKwmYyw1GNLkvbrf8A4B+oNFfl99tvP+fu4/7+Gj7bef8AP3cf9/DXD/qTH/n/AP8Akn/2x0/2 zP8A59/j/wAA/UGivy++23n/AD93H/fw0fbbz/n7uP8Av4aP9SY/8/8A/wAk/wDtg/tmf/Pv8f8A gH6g0V+X3228/wCfu4/7+Gj7bef8/dx/38NH+pMf+f8A/wCSf/bB/bM/+ff4/wDAP1Bor8vvtt5/ z93H/fw0fbbz/n7uP+/ho/1Jj/z/AP8AyT/7YP7Zn/z7/H/gH6g0V+X3228/5+7j/v4aPtt5/wA/ dx/38NH+pMf+f/8A5J/9sH9sz/59/j/wD9QaK/L77bef8/dx/wB/DR9tvP8An7uP+/ho/wBSY/8A P/8A8k/+2D+2Z/8APv8AH/gH6g0V+X3228/5+7j/AL+Gj7bef8/dx/38NH+pMf8An/8A+Sf/AGwf 2zP/AJ9/j/wD9QaK/L77bef8/dx/38NH228/5+7j/v4aP9SY/wDP/wD8k/8Atg/tmf8Az7/H/gH6 g0V+X3228/5+7j/v4aPtt5/z93H/AH8NH+pMf+f/AP5J/wDbB/bM/wDn3+P/AAD9QaK/L77bef8A P3cf9/DR9tvP+fu4/wC/ho/1Jj/z/wD/ACT/AO2D+2Z/8+/x/wCAfqDRX5ffbbz/AJ+7j/v4aPtt 5/z93H/fw0f6kx/5/wD/AJJ/9sH9sz/59/j/AMA/UGivy++23n/P3cf9/DR9tvP+fu4/7+Gj/UmP /P8A/wDJP/tg/tmf/Pv8f+AfqDRX5ffbbz/n7uP+/ho+23n/AD93H/fw0f6kx/5//wDkn/2wf2zP /n3+P/AP1Bor8vvtt5/z93H/AH8NH228/wCfu4/7+Gj/AFJj/wA//wDyT/7YP7Zn/wA+/wAf+Afq DRX5ffbbz/n7uP8Av4aPtt5/z93H/fw0f6kx/wCf/wD5J/8AbB/bM/8An3+P/AP1Bor8vvtt5/z9 3H/fw0fbbz/n7uP+/ho/1Jj/AM//APyT/wC2D+2Z/wDPv8f+AfqDRX5ffbbz/n7uP+/ho+23n/P3 cf8Afw0f6kx/5/8A/kn/ANsH9sz/AOff4/8AAP1Bor8vvtt5/wA/dx/38NH228/5+7j/AL+Gj/Um P/P/AP8AJP8A7YP7Zn/z7/H/AIB+oNFfl99tvP8An7uP+/ho+23n/P3cf9/DR/qTH/n/AP8Akn/2 wf2zP/n3+P8AwD9QaK/L77bef8/dx/38NH228/5+7j/v4aP9SY/8/wD/AMk/+2D+2Z/8+/x/4B+o NFfl99tvP+fu4/7+Gj7bef8AP3cf9/DR/qTH/n//AOSf/bB/bM/+ff4/8A/UGivy++23n/P3cf8A fw0fbbz/AJ+7j/v4aP8AUmP/AD//APJP/tg/tmf/AD7/AB/4B+oNFfl99tvP+fu4/wC/ho+23n/P 3cf9/DR/qTH/AJ//APkn/wBsH9sz/wCff4/8A/UGivy++23n/P3cf9/DR9tvP+fu4/7+Gj/UmP8A z/8A/JP/ALYP7Zn/AM+/x/4B+oNFfl99tvP+fu4/7+Gj7bef8/dx/wB/DR/qTH/n/wD+Sf8A2wf2 zP8A59/j/wAA/UGivy++23n/AD93H/fw0fbbz/n7uP8Av4aP9SY/8/8A/wAk/wDtg/tmf/Pv8f8A gH6g0V+X3228/wCfu4/7+Gj7bef8/dx/38NH+pMf+f8A/wCSf/bB/bM/+ff4/wDAP1Bor8vvtt5/ z93H/fw0fbbz/n7uP+/ho/1Jj/z/AP8AyT/7YP7Zn/z7/H/gH6g0V+X3228/5+7j/v4aPtt5/wA/ dx/38NH+pMf+f/8A5J/9sH9sz/59/j/wD9QaK/L77bef8/dx/wB/DR9tvP8An7uP+/ho/wBSY/8A P/8A8k/+2D+2Z/8APv8AH/gH6g0V+X3228/5+7j/AL+Gj7bef8/dx/38NH+pMf8An/8A+Sf/AGwf 2zP/AJ9/j/wD9QaK/L77bef8/dx/38NH228/5+7j/v4aP9SY/wDP/wD8k/8Atg/tmf8Az7/H/gH6 g0V+X3228/5+7j/v4aPtt5/z93H/AH8NH+pMf+f/AP5J/wDbB/bM/wDn3+P/AAD9QaK/L77bef8A P3cf9/DR9tvP+fu4/wC/ho/1Jj/z/wD/ACT/AO2D+2Z/8+/x/wCAfqDRX5ffbbz/AJ+7j/v4aPtt 5/z93H/fw0f6kx/5/wD/AJJ/9sH9sz/59/j/AMA/UGivy++23n/P3cf9/DR9tvP+fu4/7+Gj/UmP /P8A/wDJP/tg/tmf/Pv8f+AfqDRX5ffbbz/n7uP+/ho+23n/AD93H/fw0f6kx/5//wDkn/2wf2zP /n3+P/AP1Bor8vvtt5/z93H/AH8NH228/wCfu4/7+Gj/AFJj/wA//wDyT/7YP7Zn/wA+/wAf+Afq DRX5ffbbz/n7uP8Av4aPtt5/z93H/fw0f6kx/wCf/wD5J/8AbB/bM/8An3+P/AP1Bor8vvtt5/z9 3H/fw0fbbz/n7uP+/ho/1Jj/AM//APyT/wC2D+2Z/wDPv8f+AfqDRX5ffbbz/n7uP+/ho+23n/P3 cf8Afw0f6kx/5/8A/kn/ANsH9sz/AOff4/8AAP1Bor8vvtt5/wA/dx/38NH228/5+7j/AL+Gj/Um P/P/AP8AJP8A7YP7Zn/z7/H/AIB+oNFfl99tvP8An7uP+/ho+23n/P3cf9/DR/qTH/n/AP8Akn/2 wf2zP/n3+P8AwD9QaK/L77bef8/dx/38NH228/5+7j/v4aP9SY/8/wD/AMk/+2D+2Z/8+/x/4B+o NFfl99tvP+fu4/7+Gj7bef8AP3cf9/DR/qTH/n//AOSf/bB/bM/+ff4/8A/UGivy++23n/P3cf8A fw0fbbz/AJ+7j/v4aP8AUmP/AD//APJP/tg/tmf/AD7/AB/4B+oNFfl99tvP+fu4/wC/ho+23n/P 3cf9/DR/qTH/AJ//APkn/wBsH9sz/wCff4/8A/UGivy++23n/P3cf9/DR9tvP+fu4/7+Gj/UmP8A z/8A/JP/ALYP7Zn/AM+/x/4B+oNFfl99tvP+fu4/7+Gj7bef8/dx/wB/DR/qTH/n/wD+Sf8A2wf2 zP8A59/j/wAA/UGivy++23n/AD93H/fw0fbbz/n7uP8Av4aP9SY/8/8A/wAk/wDtg/tmf/Pv8f8A gH6g0V+X3228/wCfu4/7+Gj7bef8/dx/38NH+pMf+f8A/wCSf/bB/bM/+ff4/wDAP1Bor8vvtt5/ z93H/fw0fbbz/n7uP+/ho/1Jj/z/AP8AyT/7YP7Zn/z7/H/gH6g0V+X3228/5+7j/v4aPtt5/wA/ dx/38NH+pMf+f/8A5J/9sH9sz/59/j/wD9QaK/L77bef8/dx/wB/DR9tvP8An7uP+/ho/wBSY/8A P/8A8k/+2D+2Z/8APv8AH/gH6g0V+X3228/5+7j/AL+Gj7bef8/dx/38NH+pMf8An/8A+Sf/AGwf 2zP/AJ9/j/wD9QaK/L77bef8/dx/38NH228/5+7j/v4aP9SY/wDP/wD8k/8Atg/tmf8Az7/H/gH2 b+23/wAkftv+wxD/AOi5aK+L5bi4mXbLPLIoOcM5IzRX1GV5esvw6oKXNa+trb+V2eZiK7r1HUat f5/5H//Z ------=_NextPart_000_006B_01C3828B.75E2AAC0-- From owner-voql@eso.org Wed Sep 24 15:48:59 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 h8ODmiKm003779 for ; Wed, 24 Sep 2003 15:48:44 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8ODmiBS003777 for voql-outgoing; Wed, 24 Sep 2003 15:48:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8ODmRKm003679 for ; Wed, 24 Sep 2003 15:48:28 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8ODmRe11992 for ; Wed, 24 Sep 2003 15:48:27 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAbIaWAx; Wed, 24 Sep 03 15:48:26 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h8ODmMP14242; Wed, 24 Sep 2003 09:48:22 -0400 Date: Wed, 24 Sep 2003 09:48:22 -0400 From: "Wil O'Mullane" To: Tony Linde Cc: voql@ivoa.net, openskyquery@eta.pha.jhu.edu Subject: Re: SkyNode Interface Version 0.5 Message-ID: <20030924094822.B13186@skysrv.pha.jhu.edu> References: <20030922172924.A12215@skysrv.pha.jhu.edu> <006a01c38283$141e42c0$6124d28f@gnowee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <006a01c38283$141e42c0$6124d28f@gnowee>; from ael@star.le.ac.uk on Wed, Sep 24, 2003 at 11:03:18AM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes the include for the regionxsd seems to give an error. But it loads okay. We shall look inot it further... wil P.S. All diagrams are available from http://skyservice.pha.jhu.edu/develop/vo/adql/doc/adql.html On Wed, Sep 24, 2003 at 11:03:18AM +0100, Tony Linde wrote: > Hi Wil, > > When I try to load the schema into XmlSpy I get an error message - see > attached. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Wil O'Mullane > > Sent: 22 September 2003 22:29 > > To: voql@ivoa.net; openskyquery@eta.pha.jhu.edu > > Subject: SkyNode Interface Version 0.5 > > > > > > There has been a suggestion to close OpenSkyQuery mailing > > list and move this to VOQL. As of This mail please use > > VOQL@ivoa.net to comment on the SkyNode specification. > > > > The Latest Spec0.5 is now posted on the twiki at > > http://www.ivoa.net/twiki/bin/view/IVOA/Iv> oaVOQL > > > > We will > > work on producing some precise WSDL for the > > SkyNode next. > > > > As always more comments are welcome. > > > > wil > > From owner-voql@eso.org Mon Oct 6 10:15:07 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 h968E6p5013663 for ; Mon, 6 Oct 2003 10:14:06 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h968E6nt013662 for voql-outgoing; Mon, 6 Oct 2003 10:14:06 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h968DTp5013463 for ; Mon, 6 Oct 2003 10:13:29 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h968DSd05027 for ; Mon, 6 Oct 2003 10:13:28 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARLaq0j; Mon, 6 Oct 03 10:13:27 +0200 Received: from mail-hub.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id RAA00222 for ; Mon, 6 Oct 2003 17:13:29 +0900 (JST) Received: from Cassiopeia.mtk.nao.ac.jp (vpn-06-065.cc.nao.ac.jp [133.40.6.65]) by mail-hub.mtk.nao.ac.jp (8.9.3p2/3.7W00121511) with ESMTP id RAA26682 for ; Mon, 6 Oct 2003 17:13:57 +0900 (JST) Message-Id: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Mon, 06 Oct 2003 17:12:51 +0900 To: voql From: Masatoshi OHISHI Subject: Re: A Working document has been submitted In-Reply-To: <5.0.2.7.2.20030924105131.00d3d7e8@mail.mtk.nao.ac.jp> References: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: VOQL friends, I would like to know who plans to attend our WG meeting in Strasbourg (16th). Those who plan, please send your message to this mailing list. Cheers, Masatoshi Ohishi From owner-voql@eso.org Mon Oct 6 11:39:54 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 h969dB6G012033 for ; Mon, 6 Oct 2003 11:39:11 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h969dBCg012032 for voql-outgoing; Mon, 6 Oct 2003 11:39:11 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h969cZ6G011782 for ; Mon, 6 Oct 2003 11:38:35 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h969cYA09395 for ; Mon, 6 Oct 2003 11:38:34 +0200 (MEST) Received: from ntp2c.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAgvaqws; Mon, 6 Oct 03 11:38:33 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6RjU-0005tC-JD for voql@ivoa.net; Mon, 06 Oct 2003 10:32:48 +0100 Received: (qmail 231 invoked from network); 6 Oct 2003 09:38:53 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Oct 2003 09:38:53 -0000 Date: Mon, 6 Oct 2003 10:38:54 +0100 (BST) From: Clive Page To: voql Subject: Re: A Working document has been submitted In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 6 Oct 2003, Masatoshi OHISHI wrote: > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. I expect to attend. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From francois@vizir.u-strasbg.fr Mon Oct 6 12:11:53 2003 Return-Path: Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96AB4OF022282 for ; Mon, 6 Oct 2003 12:11:04 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96AB3x11261 for ; Mon, 6 Oct 2003 12:11:03 +0200 (MEST) Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAd8ay_v; Mon, 6 Oct 03 12:11:02 +0200 Received: from vizir.u-strasbg.fr (vizir.u-strasbg.fr [130.79.128.13]) by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h96AB1di014071 for ; Mon, 6 Oct 2003 12:11:01 +0200 (CEST) Received: from vizier (localhost [127.0.0.1]) by vizir.u-strasbg.fr (8.11.6+Sun/8.9.1) with ESMTP id h96AAuB20981 for ; Mon, 6 Oct 2003 12:10:56 +0200 (MET DST) Message-Id: <200310061010.h96AAuB20981@vizir.u-strasbg.fr> To: owner-voql@eso.org Subject: Re: A Working document has been submitted In-reply-to: Your message of Mon, 06 Oct 2003 17:12:51 +0900 . Date: Mon, 06 Oct 2003 12:10:56 +0200 From: Francois Ochsenbein X-Antivirus: scanned by sophos at u-strasbg.fr X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes, I plan to attend, thank you for the message. See you soon, Francois > >VOQL friends, > >I would like to know who plans to attend our WG meeting in >Strasbourg (16th). Those who plan, please send your message to >this mailing list. > >Cheers, > > Masatoshi Ohishi ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois@astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 32 ================================================================================ From owner-voql@eso.org Mon Oct 6 13:29:05 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 h96BSKOF015831 for ; Mon, 6 Oct 2003 13:28:20 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96BSKIT015828 for voql-outgoing; Mon, 6 Oct 2003 13:28:20 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96BRZOF015598 for ; Mon, 6 Oct 2003 13:27:35 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96BRZn15808 for ; Mon, 6 Oct 2003 13:27:35 +0200 (MEST) Received: from blaze.cs.jhu.edu(128.220.13.50) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAASaa43E; Mon, 6 Oct 03 13:27:33 +0200 Received: from phd6.cs.jhu.edu (phd6.cs.jhu.edu [128.220.223.228]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id h96BST6k020725 for ; Mon, 6 Oct 2003 07:28:30 -0400 (EDT) Received: from localhost (haridas@localhost) by phd6.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id h96BRdP05856 for ; Mon, 6 Oct 2003 07:27:39 -0400 (EDT) Date: Mon, 6 Oct 2003 07:27:39 -0400 (EDT) From: Vivek Haridas To: voql Subject: Re: A Working document has been submitted (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Vivek Haridas X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I plan to attend too. with Best Regards, Vivek Haridas On Mon, 6 Oct 2003, Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi > From owner-voql@eso.org Mon Oct 6 13:38:25 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 h96BbeOF018788 for ; Mon, 6 Oct 2003 13:37:41 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96BbeCh018787 for voql-outgoing; Mon, 6 Oct 2003 13:37:40 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h96BaqOF018528 for ; Mon, 6 Oct 2003 13:36:52 +0200 (MEST) Received: from eso.org (astarte.hq.eso.org [134.171.10.121]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h96Baqw14415 for ; Mon, 6 Oct 2003 13:36:52 +0200 (MEST) Date: Mon, 6 Oct 2003 13:36:51 +0200 Subject: Re: A Working document has been submitted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jonas Haase To: voql@ivoa.net Content-Transfer-Encoding: 7bit In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Message-Id: <60F7F008-F7F1-11D7-A83A-0003934C517A@eso.org> X-Mailer: Apple Mail (2.552) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Jonas Haase X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Monday, Oct 6, 2003, at 10:12 Europe/Berlin, Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi I will be there cheers Jonas > -- Jonas.Haase@eso.org Tel: +49 89 32006572 ST-ECF c/o ESO HST Science Archive Fax: +49 89 32006480 Karl Schwarzschild Str.2, http://archive.eso.org/ Garching bei Muenchen, http://www.stecf.org/ D-85748 Germany From owner-voql@eso.org Mon Oct 6 15:04:21 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 h96D43OF015763 for ; Mon, 6 Oct 2003 15:04:03 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96D433Y015762 for voql-outgoing; Mon, 6 Oct 2003 15:04:03 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96D3FOF015438 for ; Mon, 6 Oct 2003 15:03:15 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96D3Ew21596 for ; Mon, 6 Oct 2003 15:03:14 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA2haqlQ; Mon, 6 Oct 03 15:03:12 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h96D35p06481; Mon, 6 Oct 2003 09:03:05 -0400 Date: Mon, 6 Oct 2003 09:03:05 -0400 From: "Wil O'Mullane" To: Masatoshi OHISHI Cc: voql Subject: Re: A Working document has been submitted Message-ID: <20031006090305.C32008@skysrv.pha.jhu.edu> References: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> <5.0.2.7.2.20030924105131.00d3d7e8@mail.mtk.nao.ac.jp> <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp>; from masatoshi.ohishi@nao.ac.jp on Mon, Oct 06, 2003 at 05:12:51PM +0900 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I shall attend with Vivek On Mon, Oct 06, 2003 at 05:12:51PM +0900, Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi From owner-voql@eso.org Mon Oct 6 15:16:31 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 h96DFjOF020886 for ; Mon, 6 Oct 2003 15:15:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96DFi3i020883 for voql-outgoing; Mon, 6 Oct 2003 15:15:44 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96DF7OF020684 for ; Mon, 6 Oct 2003 15:15:08 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96DF7F22464 for ; Mon, 6 Oct 2003 15:15:07 +0200 (MEST) Received: from kintyre.roe.ac.uk(195.194.120.72) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAADxa43R; Mon, 6 Oct 03 15:15:06 +0200 Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 27D7E46087 for ; Mon, 6 Oct 2003 14:15:06 +0100 (BST) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 13884; Mon, 06 Oct 2003 14:15:05 +0100 (BST) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B10C446062 for ; Mon, 6 Oct 2003 14:15:05 +0100 (BST) Received: from lismore.roe.ac.uk (lismore.roe.ac.uk [195.194.120.117]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 54C9F46062 for ; Mon, 6 Oct 2003 14:15:05 +0100 (BST) Date: Mon, 6 Oct 2003 14:15:05 +0100 (BST) From: Bob Mann To: voql Subject: Re: A Working document has been submitted In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Message-ID: References: <5.0.2.5.2.20030416235922.01ec40f8@133.40.4.4> <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Bob Mann X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'll be attending. Bob Mann On Mon, 6 Oct 2003, Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi > > From owner-voql@eso.org Mon Oct 6 15:22: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 h96DLmOF022788 for ; Mon, 6 Oct 2003 15:21:48 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96DLmIw022787 for voql-outgoing; Mon, 6 Oct 2003 15:21:48 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96DKpOF022451 for ; Mon, 6 Oct 2003 15:20:51 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96DKnO22807 for ; Mon, 6 Oct 2003 15:20:49 +0200 (MEST) Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAr7aiIS; Mon, 6 Oct 03 15:20:48 +0200 Received: from volpix (volpix.stsci.edu [130.167.250.17]) by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGN47757; Mon, 6 Oct 2003 09:20:46 -0400 (EDT) From: "Antonio Volpicelli" To: "'voql'" Subject: RE: A Working document has been submitted Date: Mon, 6 Oct 2003 09:20:45 -0400 Message-ID: <000601c38c0c$a6db4530$11faa782@stsci.edu> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Importance: Normal X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Antonio Volpicelli" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I will be attending too. Antonio -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Masatoshi OHISHI Sent: Monday, October 06, 2003 4:13 AM To: voql Subject: Re: A Working document has been submitted VOQL friends, I would like to know who plans to attend our WG meeting in Strasbourg (16th). Those who plan, please send your message to this mailing list. Cheers, Masatoshi Ohishi From owner-voql@eso.org Mon Oct 6 15:36:16 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 h96DZTOF027823 for ; Mon, 6 Oct 2003 15:35:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96DZTYD027814 for voql-outgoing; Mon, 6 Oct 2003 15:35:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96DYYOF027500 for ; Mon, 6 Oct 2003 15:34:34 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96DYXZ23700 for ; Mon, 6 Oct 2003 15:34:33 +0200 (MEST) Received: from ntp2c.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAfaaasU; Mon, 6 Oct 03 15:34:32 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6VPq-00042A-Ur for voql@ivoa.net; Mon, 06 Oct 2003 14:28:46 +0100 Received: (qmail 1117 invoked from network); 6 Oct 2003 13:34:20 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 6 Oct 2003 13:34:20 -0000 From: "Tony Linde" To: "'Masatoshi OHISHI'" , "'voql'" Subject: RE: A Working document has been submitted Date: Mon, 6 Oct 2003 14:34:09 +0100 Organization: University of Leicester Message-ID: <003201c38c0e$85e14670$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'll be there. Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 06 October 2003 09:13 > To: voql > Subject: Re: A Working document has been submitted > > > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message > to this mailing list. > > Cheers, > > Masatoshi Ohishi > From owner-voql@eso.org Mon Oct 6 15:42:27 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 h96DfPOF029781 for ; Mon, 6 Oct 2003 15:41:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96DfPJe029779 for voql-outgoing; Mon, 6 Oct 2003 15:41:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96DelOF029592 for ; Mon, 6 Oct 2003 15:40:47 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96DKqF22816 for ; Mon, 6 Oct 2003 15:20:52 +0200 (MEST) Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAfCaGJS; Mon, 6 Oct 03 15:20:50 +0200 Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100]) by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h96DKnNT011153; Mon, 6 Oct 2003 09:20:49 -0400 (EDT) From: Arnold Rots Received: (from arots@localhost) by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id h96DKnC7004823; Mon, 6 Oct 2003 09:20:49 -0400 (EDT) Message-Id: <200310061320.h96DKnC7004823@xebec.cfa.harvard.edu> Subject: Re: A Working document has been submitted In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> To: Masatoshi OHISHI Date: Mon, 6 Oct 2003 09:20:48 -0400 (EDT) CC: voql X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Arnold Rots X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I hope to attend. - Arnold Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi > -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots@head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- From owner-voql@eso.org Mon Oct 6 19:05:37 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 h96H4bS4005387 for ; Mon, 6 Oct 2003 19:04:37 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96H4b3O005386 for voql-outgoing; Mon, 6 Oct 2003 19:04:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96H3oS4005123 for ; Mon, 6 Oct 2003 19:03:50 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96H3om08004 for ; Mon, 6 Oct 2003 19:03:50 +0200 (MEST) Received: from nrcvicex1b.hia.nrc.ca(204.174.103.9) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARQayOp; Mon, 6 Oct 03 19:03:49 +0200 Received: from frodo (d64-180-117-83.bchsia.telus.net [64.180.117.83]) by nrcvicex1.hia.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TNKVFVKN; Mon, 6 Oct 2003 10:03:40 -0700 Content-Type: text/plain; charset="iso-8859-1" X-Sybari-Trust: b92c9862 aef7db6d 66c83239 00000109 From: Patrick Dowler Organization: National Research Council Canada To: Masatoshi OHISHI , voql Subject: Re: A Working document has been submitted Date: Mon, 6 Oct 2003 10:03:39 -0700 User-Agent: KMail/1.4.3 References: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> In-Reply-To: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310061003.39032.patrick.dowler@nrc-cnrc.gc.ca> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Patrick Dowler X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Monday 6 October 2003 01:12, Masatoshi OHISHI wrote: > VOQL friends, > > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > > Cheers, > > Masatoshi Ohishi I will attend and should be able to report on the VOQL effort of Ed Shaya and his coworkers and myself... -- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) From owner-voql@eso.org Mon Oct 6 20:09:56 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 h96I9IS4021806 for ; Mon, 6 Oct 2003 20:09:18 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96I9H3V021805 for voql-outgoing; Mon, 6 Oct 2003 20:09:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96I8iS4021668 for ; Mon, 6 Oct 2003 20:08:44 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96I8he11475 for ; Mon, 6 Oct 2003 20:08:43 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAGlaqAw; Mon, 6 Oct 03 20:08:42 +0200 Received: from chandra.pha.jhu.edu (chandra.pha.jhu.edu [128.220.233.43]) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id h96I8fY12680; Mon, 6 Oct 2003 14:08:41 -0400 Received: from localhost (thakar@localhost) by chandra.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id h96I8fD03602; Mon, 6 Oct 2003 14:08:41 -0400 X-Authentication-Warning: chandra.pha.jhu.edu: thakar owned process doing -bs Date: Mon, 6 Oct 2003 14:08:41 -0400 (EDT) From: Ani Thakar X-X-Sender: thakar@chandra.pha.jhu.edu To: Masatoshi OHISHI cc: voql Subject: Re: A Working document has been submitted In-Reply-To: <200310061003.39032.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Ani Thakar X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: i'll be attending the VOQL session as well. ani > On Monday 6 October 2003 01:12, Masatoshi OHISHI wrote: > > VOQL friends, > > > > I would like to know who plans to attend our WG meeting in > > Strasbourg (16th). Those who plan, please send your message to > > this mailing list. > -- Aniruddha R Thakar, Assoc. Research Scientist, The Sloan Digital Sky Survey Ctr for Astrophysical Sci., JHU, 3701 San Martin Dr Baltimore MD 21218-2695 410-516-4850| fax410-516-5096| thakar@pha.jhu.edu| www.sdss.jhu.edu/~thakar --------------------------------------------------------------------------- What is eloquence in the forum is commonly found to be rhetoric in the study. [Thoreau] From owner-voql@eso.org Tue Oct 7 01:57:24 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 h96NucNq018777 for ; Tue, 7 Oct 2003 01:56:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h96NucXk018776 for voql-outgoing; Tue, 7 Oct 2003 01:56:38 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h96Nu5Nq018628 for ; Tue, 7 Oct 2003 01:56:05 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h96Nu5g28604 for ; Tue, 7 Oct 2003 01:56:05 +0200 (MEST) Received: from argo.act.cmis.csiro.au(152.83.72.46) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAqvaa23; Tue, 7 Oct 03 01:56:03 +0200 Received: from saab-bt.act.cmis.csiro.au (saab-bt.act.cmis.CSIRO.AU [152.83.70.2]) by argo.act.cmis.CSIRO.AU (Postfix) with ESMTP id 1F7CE2850B for ; Tue, 7 Oct 2003 09:55:58 +1000 (EST) Received: by saab-bt.act.cmis.CSIRO.AU with Internet Mail Service (5.5.2656.59) id <42XHR7V2>; Tue, 7 Oct 2003 09:55:58 +1000 Message-ID: <57C87AAEA6B0BC479B69F110575ECCCF09AED9@saab-bt.act.cmis.CSIRO.AU> From: Robert.Power@csiro.au To: voql@ivoa.net Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 09:55:58 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Robert.Power@csiro.au X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > -----Original Message----- > I would like to know who plans to attend our WG meeting in > Strasbourg (16th). Those who plan, please send your message to > this mailing list. > I'll be there, Robert Power +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ robert.power@csiro.au Senior Software Engineer CSIRO ICT Centre Canberra Laboratory PO Box 664 tel: +61 2 6216 7039 Canberra ACT 2601 AUSTRALIA. fax: +61 2 6216 7111 http://www.cmis.csiro.au/grid +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-voql@eso.org Tue Oct 7 11:25:49 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 h979P1Nq018734 for ; Tue, 7 Oct 2003 11:25:01 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h979P16F018724 for voql-outgoing; Tue, 7 Oct 2003 11:25:01 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h979OPNq018544 for ; Tue, 7 Oct 2003 11:24:25 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h979OP120436 for ; Tue, 7 Oct 2003 11:24:25 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAARKaq6N; Tue, 7 Oct 03 11:24:23 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6nzK-0005UL-3q for voql@ivoa.net; Tue, 07 Oct 2003 10:18:38 +0100 Received: (qmail 1524 invoked from network); 7 Oct 2003 09:24:43 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 09:24:43 -0000 Date: Tue, 7 Oct 2003 10:24:44 +0100 (BST) From: Clive Page To: voql Subject: Re: A Working document has been submitted In-Reply-To: <5.0.2.7.2.20030924105131.00d3d7e8@mail.mtk.nao.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think there may be a typo in the IVOA Sky Node v0.5 document: in section 5 QI-6 the function 'degree' should I think be 'degrees' as that is the spelling in the SQL and JDBC standards (and matches the plurality of 'radians'). I have a question: to what extent are user define functions supported or permitted? I see that in QI-9 there is what looks like a REGION function, though it is described as a 'keyword'. The example given is Region ('CIRCLE J2000 19.5 -36.7 0.02') This looks to me a lot like a function call, and would be a lot more flexible if it took a string arg and 3 numeric arguments. Is there a way of defining more functions (or keywords) - since we shall surely want more? Or can they be used in expressions and passed transparently to the SQL-speaking back-end, in roughly the way that JDBC does? -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Oct 7 11:31:28 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 h979UoNq020546 for ; Tue, 7 Oct 2003 11:30:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h979UohY020545 for voql-outgoing; Tue, 7 Oct 2003 11:30:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h979U7Nq020327 for ; Tue, 7 Oct 2003 11:30:07 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h979U7k20739 for ; Tue, 7 Oct 2003 11:30:07 +0200 (MEST) Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA2_aWFO; Tue, 7 Oct 03 11:30:05 +0200 Received: from mail-hub.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id SAA06101 for ; Tue, 7 Oct 2003 18:30:06 +0900 (JST) Received: from Cassiopeia.mtk.nao.ac.jp (vpn-06-065.cc.nao.ac.jp [133.40.6.65]) by mail-hub.mtk.nao.ac.jp (8.9.3p2/3.7W00121511) with ESMTP id SAA15907 for ; Tue, 7 Oct 2003 18:30:35 +0900 (JST) Message-Id: <5.0.2.7.2.20031007182852.02a5dec8@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Tue, 07 Oct 2003 18:29:34 +0900 To: voql From: Masatoshi OHISHI Subject: Re: A Working document has been submitted In-Reply-To: <200310061003.39032.patrick.dowler@nrc-cnrc.gc.ca> References: <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> <5.0.2.7.2.20031006171120.00c90a48@mail.mtk.nao.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thanks Patrick. I assumed so. Cheers, Masatoshi At 10:03 03/10/06 -0700, Patrick Dowler wrote: >I will attend and should be able to report on the VOQL effort of Ed Shaya >and his coworkers and myself... From owner-voql@eso.org Tue Oct 7 11:45:32 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 h979iTNq024905 for ; Tue, 7 Oct 2003 11:44:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h979iSUK024895 for voql-outgoing; Tue, 7 Oct 2003 11:44:28 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h979hMNq024477 for ; Tue, 7 Oct 2003 11:43:22 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h979hLU21585 for ; Tue, 7 Oct 2003 11:43:21 +0200 (MEST) Received: from colossus.systems.pipex.net(62.241.160.73) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAALkaakQ; Tue, 7 Oct 03 11:43:21 +0200 Received: from dial.pipex.com (81-178-227-194.dsl.pipex.com [81.178.227.194]) by colossus.systems.pipex.net (Postfix) with ESMTP id 4567316000071; Tue, 7 Oct 2003 10:43:17 +0100 (BST) Message-ID: <3F828A97.7010801@dial.pipex.com> Date: Tue, 07 Oct 2003 10:42:47 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Clive Page Cc: voql Subject: Re: Functions in ADQL 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Since the americans are probably in bed right now - We wanted to keep the basic SkyNode QL very simple to implement. This is the only function we expect the query language to implement as it will be required for so many queries. As I understand it, it's basically a 'rough' neighbourhood search which can then be refined by the client. I think we're probably going to have to publish other functions through the metadata somehow... as not all services will implement all functions I expect? Clive Page wrote: > I think there may be a typo in the IVOA Sky Node v0.5 document: in section > 5 QI-6 the function 'degree' should I think be 'degrees' as that is the > spelling in the SQL and JDBC standards (and matches the plurality of > 'radians'). > > I have a question: to what extent are user define functions supported or > permitted? I see that in QI-9 there is what looks like a REGION > function, though it is described as a 'keyword'. The example given is > > Region ('CIRCLE J2000 19.5 -36.7 0.02') > > This looks to me a lot like a function call, and would be a lot more > flexible if it took a string arg and 3 numeric arguments. Is there a way > of defining more functions (or keywords) - since we shall surely want > more? Or can they be used in expressions and passed transparently to the > SQL-speaking back-end, in roughly the way that JDBC does? > > From owner-voql@eso.org Tue Oct 7 15:18:51 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 h97DHcwC028634 for ; Tue, 7 Oct 2003 15:17:38 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97DHbOt028633 for voql-outgoing; Tue, 7 Oct 2003 15:17:37 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97DH2wC028479 for ; Tue, 7 Oct 2003 15:17:03 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97DH2h03398 for ; Tue, 7 Oct 2003 15:17:02 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAUbaiOg; Tue, 7 Oct 03 15:17:00 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h97DGxJ24743 for voql@ivoa.net; Tue, 7 Oct 2003 09:16:59 -0400 Date: Tue, 7 Oct 2003 09:16:59 -0400 From: "Wil O'Mullane" To: voql@ivoa.net Subject: adql poster Message-ID: <20031007091659.B17876@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We (Naoki Yasuda & I ) have drafted an ADQL poster. I would like to add more of the comenters as authors i.e. Tony Linde Clive Page Bob Mann Martin Hill Are there others who should be or feel they should be added Do any of you not wish to appear. http://skyservice/develop/meetings/adass2003/ADQL_ADASS.ppt Minor changes may also be accomodated today but we need to finish this today to have some chance of printing it ... wil From owner-voql@eso.org Tue Oct 7 15:44:37 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 h97DhWwC007062 for ; Tue, 7 Oct 2003 15:43:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97DhWZr007061 for voql-outgoing; Tue, 7 Oct 2003 15:43:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97DgmwC006714 for ; Tue, 7 Oct 2003 15:42:48 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97DgmB05164 for ; Tue, 7 Oct 2003 15:42:48 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA5Cayfk; Tue, 7 Oct 03 15:42:46 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h97Dgjk25089 for voql@ivoa.net; Tue, 7 Oct 2003 09:42:45 -0400 Date: Tue, 7 Oct 2003 09:42:45 -0400 From: "Wil O'Mullane" To: voql@ivoa.net Subject: User defined Functions in ADQL Message-ID: <20031007094245.A24951@skysrv.pha.jhu.edu> References: <5.0.2.7.2.20030924105131.00d3d7e8@mail.mtk.nao.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Tue, Oct 07, 2003 at 10:24:44AM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I think there may be a typo in the IVOA Sky Node v0.5 document: in section > 5 QI-6 the function 'degree' should I think be 'degrees' as that is the > spelling in the SQL and JDBC standards (and matches the plurality of > 'radians'). I have started a 0.6 draft with this change in :) Martin expressed well our current thinking of ADQL i.e. it should be complete and simple. If ADQL is to be a parse tree the XSD should contain all keywords/functions. If we allowed user defined functions it would certainly allow flexibility but also introduce uncertainty. It is a debate we have had and I think and interesting topic for discussion at Strasbourg. > > I have a question: to what extent are user define functions supported or > permitted? I see that in QI-9 there is what looks like a REGION > function, though it is described as a 'keyword'. The example given is > > Region ('CIRCLE J2000 19.5 -36.7 0.02') > > This looks to me a lot like a function call, and would be a lot more > flexible if it took a string arg and 3 numeric arguments. Is there a way > of defining more functions (or keywords) - since we shall surely want > more? Or can they be used in expressions and passed transparently to the > SQL-speaking back-end, in roughly the way that JDBC does? > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Oct 7 15:53:36 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 h97DrWaY010496 for ; Tue, 7 Oct 2003 15:53:32 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97DrVBp010495 for voql-outgoing; Tue, 7 Oct 2003 15:53:31 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97DqraY010329 for ; Tue, 7 Oct 2003 15:52:53 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97Dqqa05734 for ; Tue, 7 Oct 2003 15:52:52 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAxfaOml; Tue, 7 Oct 03 15:52:51 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h97Dqo925376 for voql@ivoa.net; Tue, 7 Oct 2003 09:52:50 -0400 Date: Tue, 7 Oct 2003 09:52:50 -0400 From: "Wil O'Mullane" To: voql@ivoa.net Subject: Link to the ADQL poster Message-ID: <20031007095250.C24951@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: sorry it should have been http://skyservice.pha.jhu.edu/develop/meetings/adass2003/ADQL_ADASS.ppt From owner-voql@eso.org Tue Oct 7 16:13:44 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 h97ECj4c017310 for ; Tue, 7 Oct 2003 16:12:45 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97ECjMs017306 for voql-outgoing; Tue, 7 Oct 2003 16:12:45 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97EBW4e016890 for ; Tue, 7 Oct 2003 16:12:10 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97Dnfp05569 for ; Tue, 7 Oct 2003 15:49:41 +0200 (MEST) Received: from ntp2b.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAVBaa4k; Tue, 7 Oct 03 15:49:40 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by apollo.le.ac.uk with smtp (Exim 4.24) id 1A6s7q-0002ZA-A5 for voql@ivoa.net; Tue, 07 Oct 2003 14:43:42 +0100 Received: (qmail 26726 invoked from network); 7 Oct 2003 13:49:59 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 13:49:59 -0000 Date: Tue, 7 Oct 2003 14:50:00 +0100 (BST) From: Clive Page To: "Wil O'Mullane" cc: voql@ivoa.net Subject: Re: User defined Functions in ADQL In-Reply-To: <20031007094245.A24951@skysrv.pha.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil Thanks. > I have started a 0.6 draft with this change in :) I didn't expect to force a revision just for an 's'. :-) > Martin expressed well our current thinking of ADQL i.e. it should be > complete and simple. If ADQL is to be a parse tree the XSD should > contain all keywords/functions. If we allowed user defined functions it > would certainly allow flexibility but also introduce uncertainty. It is > a debate we have had and I think and interesting topic for discussion at > Strasbourg. Agree with need for simplicity. Not sure how to reconcile that with need for UDFs in practice. We can indeed debate at Strasbourg. Cone search is the most vital, which is (if not very neatly) provided already. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Oct 7 17:57:15 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 h97FuXLU023324 for ; Tue, 7 Oct 2003 17:56:33 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97FuWJT023319 for voql-outgoing; Tue, 7 Oct 2003 17:56:32 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97FtbLU022953 for ; Tue, 7 Oct 2003 17:55:38 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97EitG09460 for ; Tue, 7 Oct 2003 16:44:55 +0200 (MEST) Received: from mail.cacr.caltech.edu(131.215.145.9) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAFDa4Bs; Tue, 7 Oct 03 16:44:54 +0200 Received: from SARA (sara.cacr.caltech.edu [131.215.145.107]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id h97EipM9023417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 7 Oct 2003 07:44:51 -0700 Message-ID: <082601c38ce2$385c3390$6b91d783@cacr.caltech.edu> From: "Roy Williams" To: "Clive Page" , "voql" References: Subject: Re: A Working document has been submitted Date: Tue, 7 Oct 2003 07:49:32 -0700 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Region ('CIRCLE J2000 19.5 -36.7 0.02') I have a question in the same style. I would like to start using the UCD ontology within VOQL. I am imagining metadata queries like select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8 in order to find tables that have galactic velocities. Can VOQL be extended in this way? Roy From owner-voql@eso.org Tue Oct 7 19:16:48 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 h97HGQLU020672 for ; Tue, 7 Oct 2003 19:16:26 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97HGQFQ020667 for voql-outgoing; Tue, 7 Oct 2003 19:16:26 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97HFWLU020400 for ; Tue, 7 Oct 2003 19:15:32 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97HFVx19781 for ; Tue, 7 Oct 2003 19:15:31 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAASaGOM; Tue, 7 Oct 03 19:15:30 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6vLE-0002im-N6 for voql@ivoa.net; Tue, 07 Oct 2003 18:09:44 +0100 Received: (qmail 17113 invoked from network); 7 Oct 2003 17:15:51 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 17:15:51 -0000 From: "Tony Linde" To: Subject: RE: User defined Functions in ADQL Date: Tue, 7 Oct 2003 18:15:36 +0100 Organization: University of Leicester Message-ID: <00a901c38cf6$9fb50530$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We need to find a way to namespace ADQL, the list of basic functions that it expects ALL data query services to support and then additional functions. If the list of functions is likely to change out of step with ADQL then you'll need separate namespaces. For additional functions, these are likely to be individually namespaced by the developer(s) until they move into the set of basic ones. A registered service will then have to store as part of its metadata the namespace (version) of ADQL it supports along with the function namespaces. Any query interface will also have to interpret these namespaces to know what functions the user can/cannot make use of. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Clive Page > Sent: 07 October 2003 14:50 > To: Wil O'Mullane > Cc: voql@ivoa.net > Subject: Re: User defined Functions in ADQL > > > Wil > > Thanks. > > > I have started a 0.6 draft with this change in :) > > I didn't expect to force a revision just for an 's'. :-) > > > Martin expressed well our current thinking of ADQL i.e. it > should be > > complete and simple. If ADQL is to be a parse tree the XSD should > > contain all keywords/functions. If we allowed user defined > functions > > it would certainly allow flexibility but also introduce > uncertainty. > > It is a debate we have had and I think and interesting topic for > > discussion at Strasbourg. > > Agree with need for simplicity. Not sure how to reconcile > that with need for UDFs in practice. We can indeed debate at > Strasbourg. Cone search is the most vital, which is (if not > very neatly) provided already. > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > From owner-voql@eso.org Tue Oct 7 19:18:49 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 h97HICLU021192 for ; Tue, 7 Oct 2003 19:18:12 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97HICR9021190 for voql-outgoing; Tue, 7 Oct 2003 19:18:12 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97HHaLU021009 for ; Tue, 7 Oct 2003 19:17:36 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97HHYF19867 for ; Tue, 7 Oct 2003 19:17:34 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAANTaqZM; Tue, 7 Oct 03 19:17:33 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6vND-0002oQ-PJ for voql@ivoa.net; Tue, 07 Oct 2003 18:11:47 +0100 Received: (qmail 17307 invoked from network); 7 Oct 2003 17:17:54 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 17:17:54 -0000 From: "Tony Linde" To: "'Roy Williams'" , "'Clive Page'" , "'voql'" Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 18:17:39 +0100 Organization: University of Leicester Message-ID: <00aa01c38cf6$e8e01970$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <082601c38ce2$385c3390$6b91d783@cacr.caltech.edu> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think it is essential that ADQL support the use of *both* UCDs and column names. It'll be up to the query interface to substitute column names (by asking the user probably) where UCDs are not uniquely resolvable. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Roy Williams > Sent: 07 October 2003 15:50 > To: Clive Page; voql > Subject: Re: A Working document has been submitted > > > > Region ('CIRCLE J2000 19.5 -36.7 0.02') > > I have a question in the same style. I would like to start > using the UCD ontology within VOQL. I am imagining metadata > queries like > > select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8 > > in order to find tables that have galactic velocities. Can > VOQL be extended in this way? > > Roy > From owner-voql@eso.org Tue Oct 7 19:42:52 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 h97HgELU028447 for ; Tue, 7 Oct 2003 19:42:14 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97HgEkY028446 for voql-outgoing; Tue, 7 Oct 2003 19:42:14 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97HfeLU028252 for ; Tue, 7 Oct 2003 19:41:40 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97Hfel21153 for ; Tue, 7 Oct 2003 19:41:40 +0200 (MEST) Received: from colossus.systems.pipex.net(62.241.160.73) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAA6KaOtP; Tue, 7 Oct 03 19:41:39 +0200 Received: from dial.pipex.com (81-178-227-194.dsl.pipex.com [81.178.227.194]) by colossus.systems.pipex.net (Postfix) with ESMTP id D41DF16000548; Tue, 7 Oct 2003 18:41:36 +0100 (BST) Message-ID: <3F82FAB5.2050307@dial.pipex.com> Date: Tue, 07 Oct 2003 18:41:09 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: "'voql'" Subject: Re: A Working document has been submitted References: <00aa01c38cf6$e8e01970$0a01a8c0@gnowee> In-Reply-To: <00aa01c38cf6$e8e01970$0a01a8c0@gnowee> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Errrm - as I understand it, UCDs are *never* uniquely resolvable. ie, even if there is a unique UCD in one table, it doesn't necessarily mean it has the same meaning as a column with the same UCD in another table. That means we need to get user confirmation at every stage where we map between UCDs and table columns at the moment, and wherever we specify an actual applied query, it needs to be resolved to actual table column names. Tony Linde wrote: > I think it is essential that ADQL support the use of *both* UCDs and column > names. It'll be up to the query interface to substitute column names (by > asking the user probably) where UCDs are not uniquely resolvable. > > Cheers, > Tony. > > >>-----Original Message----- >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On >>Behalf Of Roy Williams >>Sent: 07 October 2003 15:50 >>To: Clive Page; voql >>Subject: Re: A Working document has been submitted >> >> >> >>> Region ('CIRCLE J2000 19.5 -36.7 0.02') >> >>I have a question in the same style. I would like to start >>using the UCD ontology within VOQL. I am imagining metadata >>queries like >> >>select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8 >> >>in order to find tables that have galactic velocities. Can >>VOQL be extended in this way? >> >>Roy >> > > From owner-voql@eso.org Tue Oct 7 19:48:25 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 h97HloLU029917 for ; Tue, 7 Oct 2003 19:47:50 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97HloPt029916 for voql-outgoing; Tue, 7 Oct 2003 19:47:50 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97HlILU029780 for ; Tue, 7 Oct 2003 19:47:18 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97HlHe21408 for ; Tue, 7 Oct 2003 19:47:17 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAhba4ZP; Tue, 7 Oct 03 19:47:16 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6vpy-0003ra-S3 for voql@ivoa.net; Tue, 07 Oct 2003 18:41:30 +0100 Received: (qmail 19490 invoked from network); 7 Oct 2003 17:47:36 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 17:47:36 -0000 From: "Tony Linde" To: "'Martin Hill'" , "'voql'" Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 18:47:21 +0100 Organization: University of Leicester Message-ID: <00ac01c38cfb$0f46bd40$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F82FAB5.2050307@dial.pipex.com> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: No, if the user chooses to use UCDs then they take the risk that they mean different things in different tables being targetted. So UCDs must be included. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Martin Hill > Sent: 07 October 2003 18:41 > To: 'voql' > Subject: Re: A Working document has been submitted > > > Errrm - as I understand it, UCDs are *never* uniquely > resolvable. ie, > even if there is a unique UCD in one table, it doesn't > necessarily mean > it has the same meaning as a column with the same UCD in > another table. > > That means we need to get user confirmation at every stage > where we map > between UCDs and table columns at the moment, and wherever we > specify an > actual applied query, it needs to be resolved to actual table column > names. > > Tony Linde wrote: > > > I think it is essential that ADQL support the use of *both* > UCDs and > > column names. It'll be up to the query interface to > substitute column > > names (by asking the user probably) where UCDs are not uniquely > > resolvable. > > > > Cheers, > > Tony. > > > > > >>-----Original Message----- > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > >>Behalf Of Roy Williams > >>Sent: 07 October 2003 15:50 > >>To: Clive Page; voql > >>Subject: Re: A Working document has been submitted > >> > >> > >> > >>> Region ('CIRCLE J2000 19.5 -36.7 0.02') > >> > >>I have a question in the same style. I would like to start > >>using the UCD ontology within VOQL. I am imagining metadata > >>queries like > >> > >>select table where UCDMatch(table, "phys.velocity, > src.galaxy") > 0.8 > >> > >>in order to find tables that have galactic velocities. Can > >>VOQL be extended in this way? > >> > >>Roy > >> > > > > > > From owner-voql@eso.org Tue Oct 7 19:53:07 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 h97HqPLU001438 for ; Tue, 7 Oct 2003 19:52:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97HqPj1001436 for voql-outgoing; Tue, 7 Oct 2003 19:52:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97HppLU001223 for ; Tue, 7 Oct 2003 19:51:51 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97Hpp921621 for ; Tue, 7 Oct 2003 19:51:51 +0200 (MEST) Received: from colossus.systems.pipex.net(62.241.160.73) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAc0aGoQ; Tue, 7 Oct 03 19:51:50 +0200 Received: from dial.pipex.com (81-178-227-194.dsl.pipex.com [81.178.227.194]) by colossus.systems.pipex.net (Postfix) with ESMTP id D783E160006A1 for ; Tue, 7 Oct 2003 18:51:49 +0100 (BST) Message-ID: <3F82FD1A.6030402@dial.pipex.com> Date: Tue, 07 Oct 2003 18:51:22 +0100 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en, en-us MIME-Version: 1.0 To: "'voql'" Subject: Re: A Working document has been submitted References: <00ac01c38cfb$0f46bd40$0a01a8c0@gnowee> In-Reply-To: <00ac01c38cfb$0f46bd40$0a01a8c0@gnowee> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Then there's a danger that users get back incorrect results without knowing it, which (I gather) is worse than the query failing. Tony Linde wrote: > No, if the user chooses to use UCDs then they take the risk that they mean > different things in different tables being targetted. So UCDs must be > included. > > Cheers, > Tony. > > >>-----Original Message----- >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On >>Behalf Of Martin Hill >>Sent: 07 October 2003 18:41 >>To: 'voql' >>Subject: Re: A Working document has been submitted >> >> >>Errrm - as I understand it, UCDs are *never* uniquely >>resolvable. ie, >>even if there is a unique UCD in one table, it doesn't >>necessarily mean >>it has the same meaning as a column with the same UCD in >>another table. >> >>That means we need to get user confirmation at every stage >>where we map >>between UCDs and table columns at the moment, and wherever we >>specify an >>actual applied query, it needs to be resolved to actual table column >>names. >> >>Tony Linde wrote: >> >> >>>I think it is essential that ADQL support the use of *both* >> >>UCDs and >> >>>column names. It'll be up to the query interface to >> >>substitute column >> >>>names (by asking the user probably) where UCDs are not uniquely >>>resolvable. >>> >>>Cheers, >>>Tony. >>> >>> >>> >>>>-----Original Message----- >>>>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On >>>>Behalf Of Roy Williams >>>>Sent: 07 October 2003 15:50 >>>>To: Clive Page; voql >>>>Subject: Re: A Working document has been submitted >>>> >>>> >>>> >>>> >>>>> Region ('CIRCLE J2000 19.5 -36.7 0.02') >>>> >>>>I have a question in the same style. I would like to start >>>>using the UCD ontology within VOQL. I am imagining metadata >>>>queries like >>>> >>>>select table where UCDMatch(table, "phys.velocity, >> >>src.galaxy") > 0.8 >> >>>>in order to find tables that have galactic velocities. Can >>>>VOQL be extended in this way? >>>> >>>>Roy >>>> >>> >>> >> > From owner-voql@eso.org Tue Oct 7 20:00:12 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 h97HxaLU003481 for ; Tue, 7 Oct 2003 19:59:36 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97Hxarg003480 for voql-outgoing; Tue, 7 Oct 2003 19:59:36 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97Hx2LU003294 for ; Tue, 7 Oct 2003 19:59:02 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97Hx2422044 for ; Tue, 7 Oct 2003 19:59:02 +0200 (MEST) Received: from mailsend.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAQbaydR; Tue, 7 Oct 03 19:59:01 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6w1L-0004FT-Aj for voql@ivoa.net; Tue, 07 Oct 2003 18:53:15 +0100 Received: (qmail 20350 invoked from network); 7 Oct 2003 17:59:22 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 17:59:22 -0000 From: "Tony Linde" To: "'Martin Hill'" , "'voql'" Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 18:59:07 +0100 Organization: University of Leicester Message-ID: <00ad01c38cfc$b3bde640$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F82FD1A.6030402@dial.pipex.com> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We can't program out human stupidity :) If users choose to query on UCDs (which they have asked for) then they have to be allowed to do so. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Martin Hill > Sent: 07 October 2003 18:51 > To: 'voql' > Subject: Re: A Working document has been submitted > > > Then there's a danger that users get back incorrect results without > knowing it, which (I gather) is worse than the query failing. > > Tony Linde wrote: > > > No, if the user chooses to use UCDs then they take the risk > that they > > mean different things in different tables being targetted. So UCDs > > must be included. > > > > Cheers, > > Tony. > > > > > >>-----Original Message----- > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > >>Behalf Of Martin Hill > >>Sent: 07 October 2003 18:41 > >>To: 'voql' > >>Subject: Re: A Working document has been submitted > >> > >> > >>Errrm - as I understand it, UCDs are *never* uniquely > >>resolvable. ie, > >>even if there is a unique UCD in one table, it doesn't > >>necessarily mean > >>it has the same meaning as a column with the same UCD in > >>another table. > >> > >>That means we need to get user confirmation at every stage > >>where we map > >>between UCDs and table columns at the moment, and wherever we > >>specify an > >>actual applied query, it needs to be resolved to actual > table column > >>names. > >> > >>Tony Linde wrote: > >> > >> > >>>I think it is essential that ADQL support the use of *both* > >> > >>UCDs and > >> > >>>column names. It'll be up to the query interface to > >> > >>substitute column > >> > >>>names (by asking the user probably) where UCDs are not uniquely > >>>resolvable. > >>> > >>>Cheers, > >>>Tony. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > >>>>Roy Williams > >>>>Sent: 07 October 2003 15:50 > >>>>To: Clive Page; voql > >>>>Subject: Re: A Working document has been submitted > >>>> > >>>> > >>>> > >>>> > >>>>> Region ('CIRCLE J2000 19.5 -36.7 0.02') > >>>> > >>>>I have a question in the same style. I would like to > start using the > >>>>UCD ontology within VOQL. I am imagining metadata queries like > >>>> > >>>>select table where UCDMatch(table, "phys.velocity, > >> > >>src.galaxy") > 0.8 > >> > >>>>in order to find tables that have galactic velocities. > Can VOQL be > >>>>extended in this way? > >>>> > >>>>Roy > >>>> > >>> > >>> > >> > > > > From owner-voql@eso.org Tue Oct 7 20:05:59 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 h97I5HLU005439 for ; Tue, 7 Oct 2003 20:05:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97I5GX4005438 for voql-outgoing; Tue, 7 Oct 2003 20:05:16 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97I4YLU005210 for ; Tue, 7 Oct 2003 20:04:34 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97I4Xn22369 for ; Tue, 7 Oct 2003 20:04:33 +0200 (MEST) Received: from skysrv.pha.jhu.edu(128.220.233.32) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAKVaWRR; Tue, 7 Oct 03 20:04:32 +0200 Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h97I4Rg30370; Tue, 7 Oct 2003 14:04:27 -0400 Date: Tue, 7 Oct 2003 14:04:27 -0400 From: "Wil O'Mullane" To: Martin Hill Cc: "'voql'" Subject: Re: A Working document has been submitted Message-ID: <20031007140427.E28585@skysrv.pha.jhu.edu> References: <00aa01c38cf6$e8e01970$0a01a8c0@gnowee> <3F82FAB5.2050307@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F82FAB5.2050307@dial.pipex.com>; from mchill@dial.pipex.com on Tue, Oct 07, 2003 at 06:41:09PM +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I would rather hope we map not to UCD but to Data Model terms. We were rather thinking of this mapping being at perhaps a higherlevel so skynode would just respond to its own schema but some other portal would take a query interms of UCDS and rewrite it using appropriate colum names. Another portal might do the same for Data Model terms etc.. So Althoutgh I thinkthe SkyNode must publish its ucds I think any query comming in should be in terms of the proper column names.. > > > I think it is essential that ADQL support the use of *both* UCDs and column > > names. It'll be up to the query interface to substitute column names (by > > asking the user probably) where UCDs are not uniquely resolvable. > > > > Cheers, > > Tony. > > > > > >>-----Original Message----- > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > >>Behalf Of Roy Williams > >>Sent: 07 October 2003 15:50 > >>To: Clive Page; voql > >>Subject: Re: A Working document has been submitted > >> > >> > >> > >>> Region ('CIRCLE J2000 19.5 -36.7 0.02') > >> > >>I have a question in the same style. I would like to start > >>using the UCD ontology within VOQL. I am imagining metadata > >>queries like > >> > >>select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8 > >> > >>in order to find tables that have galactic velocities. Can > >>VOQL be extended in this way? > >> > >>Roy > >> > > > > > From owner-voql@eso.org Tue Oct 7 20:15:02 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 h97IEPLU008452 for ; Tue, 7 Oct 2003 20:14:25 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97IEPiC008447 for voql-outgoing; Tue, 7 Oct 2003 20:14:25 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97IDLLU008152 for ; Tue, 7 Oct 2003 20:13:21 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97IDJx22984 for ; Tue, 7 Oct 2003 20:13:19 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAnxa44S; Tue, 7 Oct 03 20:13:18 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6wFA-0004hl-Id for voql@ivoa.net; Tue, 07 Oct 2003 19:07:32 +0100 Received: (qmail 20998 invoked from network); 7 Oct 2003 18:13:38 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 18:13:38 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" , "'Martin Hill'" Cc: "'voql'" Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 19:13:23 +0100 Organization: University of Leicester Message-ID: <00b501c38cfe$b213f4e0$0a01a8c0@gnowee> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20031007140427.E28585@skysrv.pha.jhu.edu> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think if a query service is described using UCDs (eg for table contents) then it ought to support queries on those UCDs. The query interface should simply pass on the query that the user has constructed in ADQL structure. The underlying database probably won't understand UCDs so the service will do the translation which is where it should be to my mind. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 07 October 2003 19:04 > To: Martin Hill > Cc: 'voql' > Subject: Re: A Working document has been submitted > > > I would rather hope we map not to UCD but to Data Model > terms. We were rather thinking of this mapping being at > perhaps a higherlevel so skynode would just respond to its > own schema but some other portal > would take a query interms of UCDS and rewrite it using > appropriate colum names. Another portal might do the same for > Data Model terms etc.. So Althoutgh I thinkthe SkyNode must > publish its ucds I think any query comming in should be in > terms of the proper column names.. > > > > > > I think it is essential that ADQL support the use of > *both* UCDs and > > > column names. It'll be up to the query interface to substitute > > > column names (by asking the user probably) where UCDs are not > > > uniquely resolvable. > > > > > > Cheers, > > > Tony. > > > > > > > > >>-----Original Message----- > > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > >>Behalf Of Roy Williams > > >>Sent: 07 October 2003 15:50 > > >>To: Clive Page; voql > > >>Subject: Re: A Working document has been submitted > > >> > > >> > > >> > > >>> Region ('CIRCLE J2000 19.5 -36.7 0.02') > > >> > > >>I have a question in the same style. I would like to start > > >>using the UCD ontology within VOQL. I am imagining metadata > > >>queries like > > >> > > >>select table where UCDMatch(table, "phys.velocity, src.galaxy") > > > >>0.8 > > >> > > >>in order to find tables that have galactic velocities. Can > > >>VOQL be extended in this way? > > >> > > >>Roy > > >> > > > > > > > > > From owner-voql@eso.org Tue Oct 7 22:29:04 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 h97KSHLU007707 for ; Tue, 7 Oct 2003 22:28:17 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97KSHXD007705 for voql-outgoing; Tue, 7 Oct 2003 22:28:17 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97KRhLU007376 for ; Tue, 7 Oct 2003 22:27:43 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97KRhu00961 for ; Tue, 7 Oct 2003 22:27:43 +0200 (MEST) Received: from mail.cacr.caltech.edu(131.215.145.9) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAoZaa4b; Tue, 7 Oct 03 22:27:41 +0200 Received: from SARA (sara.cacr.caltech.edu [131.215.145.107]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id h97KRaM9028521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 7 Oct 2003 13:27:36 -0700 Message-ID: <010c01c38d12$1a748f00$6b91d783@cacr.caltech.edu> From: "Roy Williams" To: "Wil O'Mullane" , "Martin Hill" Cc: "'voql'" References: <00aa01c38cf6$e8e01970$0a01a8c0@gnowee> <3F82FAB5.2050307@dial.pipex.com> <20031007140427.E28585@skysrv.pha.jhu.edu> Subject: Re: A Working document has been submitted Date: Tue, 7 Oct 2003 13:32:18 -0700 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Perhaps there is a mis-understanding between metadata queries and data queries. First is the metadata query, asking which columns are appropriate. This would be done in Xquery or ADQL (as previously discussed), and it returns a small result. It could be in terms of UCD matching, or even Google type matching in the column descriptions. Once we know which columns we want, and what they mean, we can issu a data query. A data query must specify exactly what is being done, and may return a lot of data. It would be in SQL or something very like it (eg ADQL). Roy -------- Caltech Center for Advanced Computing Research roy@cacr.caltech.edu 626 395 3670 From owner-voql@eso.org Tue Oct 7 23:01:31 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 h97L0sLU025516 for ; Tue, 7 Oct 2003 23:00:54 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97L0sWQ025515 for voql-outgoing; Tue, 7 Oct 2003 23:00:54 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97L0JLU025183 for ; Tue, 7 Oct 2003 23:00:19 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97L0Hj03384 for ; Tue, 7 Oct 2003 23:00:17 +0200 (MEST) Received: from artemis.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAACjaiMg; Tue, 7 Oct 03 23:00:16 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6yqk-0002SM-Rv for voql@ivoa.net; Tue, 07 Oct 2003 21:54:30 +0100 Received: (qmail 27608 invoked from network); 7 Oct 2003 21:00:37 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 21:00:37 -0000 From: "Tony Linde" To: "'voql'" Subject: RE: A Working document has been submitted Date: Tue, 7 Oct 2003 22:00:22 +0100 Organization: University of Leicester Message-ID: <00b801c38d16$06160850$0a01a8c0@gnowee> 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 In-Reply-To: <010c01c38d12$1a748f00$6b91d783@cacr.caltech.edu> 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 h97L0rLU025504 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: A metadata query should go to the Registry. If the registry has coarse granularity then it can harvest the metadata from the resource but if it is fine-grained then it can answer all metadata queries itself. The user, via the query interface or workflow composer, can then construct a data query (in a high level ADQL) to be run on the chosen resources. If the resources have common UCDs then the query could be entirely constructed of UCDs. The workflow is then turned into tasks within a job where each task will target a specific resource with a specific ADQL query. Whether the task ADQL contains column names or UCDs is not too important but I would prefer the translation to happen at the resource end. We probably need to cater for both. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Roy Williams > Sent: 07 October 2003 21:32 > To: Wil O'Mullane; Martin Hill > Cc: 'voql' > Subject: Re: A Working document has been submitted > > > Perhaps there is a mis-understanding between metadata queries > and data queries. > > First is the metadata query, asking which columns are > appropriate. This would be done in Xquery or ADQL (as > previously discussed), and it returns a small result. It > could be in terms of UCD matching, or even Google type > matching in the column descriptions. > > Once we know which columns we want, and what they mean, we > can issu a data query. A data query must specify exactly what > is being done, and may return a lot of data. It would be in > SQL or something very like it (eg ADQL). > > Roy > > -------- > Caltech Center for Advanced Computing Research > roy@cacr.caltech.edu 626 395 3670 > From owner-voql@eso.org Tue Oct 7 23:25:17 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 h97LOdLU002932 for ; Tue, 7 Oct 2003 23:24:39 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97LOdqw002931 for voql-outgoing; Tue, 7 Oct 2003 23:24:39 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97LO5LU002793 for ; Tue, 7 Oct 2003 23:24:05 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97LO5V04765 for ; Tue, 7 Oct 2003 23:24:05 +0200 (MEST) Received: from ntp2c.le.ac.uk(143.210.16.126) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAAjQaitj; Tue, 7 Oct 03 23:24:04 +0200 Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1A6zDm-0003BT-BH for voql@ivoa.net; Tue, 07 Oct 2003 22:18:18 +0100 Received: (qmail 28371 invoked from network); 7 Oct 2003 21:24:25 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 7 Oct 2003 21:24:25 -0000 From: "Tony Linde" To: Subject: FW: A Working document has been submitted Date: Tue, 7 Oct 2003 22:24:10 +0100 Organization: University of Leicester Message-ID: <000201c38d19$58ee7ff0$6124d28f@gnowee> 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-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 h97LOcLU002919 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Resend - Outlook crashed while this was on the way - apologies if it double posts... A metadata query should go to the Registry. If the registry has coarse granularity then it can harvest the metadata from the resource but if it is fine-grained then it can answer all metadata queries itself. The user, via the query interface or workflow composer, can then construct a data query (in a high level ADQL) to be run on the chosen resources. If the resources have common UCDs then the query could be entirely constructed of UCDs. The workflow is then turned into tasks within a job where each task will target a specific resource with a specific ADQL query. Whether the task ADQL contains column names or UCDs is not too important but I would prefer the translation to happen at the resource end. We probably need to cater for both. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Roy Williams > Sent: 07 October 2003 21:32 > To: Wil O'Mullane; Martin Hill > Cc: 'voql' > Subject: Re: A Working document has been submitted > > > Perhaps there is a mis-understanding between metadata queries > and data queries. > > First is the metadata query, asking which columns are > appropriate. This would be done in Xquery or ADQL (as > previously discussed), and it returns a small result. It > could be in terms of UCD matching, or even Google type > matching in the column descriptions. > > Once we know which columns we want, and what they mean, we > can issu a data query. A data query must specify exactly what > is being done, and may return a lot of data. It would be in > SQL or something very like it (eg ADQL). > > Roy > > -------- > Caltech Center for Advanced Computing Research > roy@cacr.caltech.edu 626 395 3670 > From owner-voql@eso.org Tue Oct 14 18:34:23 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 h9EGXTWg012190 for ; Tue, 14 Oct 2003 18:33:29 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9EGXTg2012189 for voql-outgoing; Tue, 14 Oct 2003 18:33:29 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h9EGWsWg011934 for ; Tue, 14 Oct 2003 18:32:54 +0200 (MEST) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9EGWqs3013081 for ; Tue, 14 Oct 2003 18:32:53 +0200 (CEST) Received: from mail-hub.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id BAA23055 for ; Wed, 15 Oct 2003 01:32:54 +0900 (JST) Received: from Cassiopeia.mtk.nao.ac.jp (vpn-06-071.cc.nao.ac.jp [133.40.6.71]) by mail-hub.mtk.nao.ac.jp (8.9.3p2/3.7W00121511) with ESMTP id BAA01275 for ; Wed, 15 Oct 2003 01:33:24 +0900 (JST) Message-Id: <5.0.2.7.2.20031015012850.00c90cf8@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 15 Oct 2003 01:32:17 +0900 To: "voql" From: Masatoshi OHISHI Subject: Speakers In-Reply-To: <082601c38ce2$385c3390$6b91d783@cacr.caltech.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Patrick and Wil, In our VOQL meeting on 16th, Patrick will be the first reporter, and Wil is the second. You may speak up to 15 - 20 minutes without questions. After Wil reports on progress of ADQL and so on, we will start discussions regarding to the content of ADQL, SkyQL and so on. Cheers, Masatoshi From owner-voql@eso.org Tue Oct 7 22:58:17 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 h97KvZLU023397 for ; Tue, 7 Oct 2003 22:57:35 +0200 (MEST) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97KvZxM023395 for voql-outgoing; Tue, 7 Oct 2003 22:57:35 +0200 (MEST) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1]) by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97KuwLU023140; Tue, 7 Oct 2003 22:56:58 +0200 (MEST) Received: (from uucp@localhost) by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97KuwT02698; Tue, 7 Oct 2003 22:56:58 +0200 (MEST) Received: from revere.aoc.nrao.edu(146.88.1.15) by eso-wall-ext.hq.eso.org via csmap (V6.0) id srcAAATzairf; Tue, 7 Oct 03 22:56:57 +0200 Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id h97KuoE32722; Tue, 7 Oct 2003 14:56:50 -0600 Received: from oak (oak [146.88.1.137]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id h97Kuh72024980; Tue, 7 Oct 2003 14:56:43 -0600 (MDT) Date: Tue, 7 Oct 2003 14:56:43 -0600 (MDT) From: Doug Tody X-X-Sender: dtody@oak To: "Wil O'Mullane" cc: "'voql'" , Subject: Re: A Working document has been submitted In-Reply-To: <20031007140427.E28585@skysrv.pha.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.2, required 7, EMAIL_ATTRIBUTION, IN_REP_TO, SPAM_PHRASE_00_01, USER_AGENT_PINE) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: We had a similar discussion in the context of DAL a while back, and ended up proposing a new tag UTYPE for this purpose. UTYPE is a pointer into a data model, and serves to identify the unique data model attribute associated with, e.g, a field or column of a VOTable (and also thereby indirectly associating all the attributes of a given data model). The same field could also have a UCD, which serves a different purpose. The idea goes like this: o We formally define a data model somewhere on the Web within the VO. This includes a namespace for each data model (and other things such as a schema, whitepaper defining the data model, etc.). o A VOTable which uses a given data model (DM) will reference the DM namespace. o Each UTYPE tag specifies the data model namespace, and the data model attribute associated with the field or other data item, e.g., UTYPE=. o The attributes of a data model can thus be mapped into votable columns (or other structures), with the ability to rigorously identify and associate each such DM attribute. One can then do things like extract the DM attributes and pass them off to analysis software, go back to the published DM schema to autoverify the DM attributes, and so forth. Both UCD (fuzzy knowledge tags) and UTYPE (rigorous pointer into data model) have their place. UCD provides a simple way to do semantic associations without requiring data models, topic maps, etc., and UTYPE allows one to reliably use data models, e.g., for data analysis or for more precise queries. - Doug On Tue, 7 Oct 2003, Wil O'Mullane wrote: > I would rather hope we map not to UCD but to Data Model terms. > We were rather thinking of this mapping being at perhaps a higherlevel > so skynode would just respond to its own schema but some other portal > would take a query interms of UCDS and rewrite it using appropriate colum > names. Another portal might do the same for Data Model terms etc.. > So Althoutgh I thinkthe SkyNode must publish its ucds I think any query > comming in should be in terms of the proper column names.. > > > > > > I think it is essential that ADQL support theuse of *both* UCDs and column > > > names. It'll be up to the query interface to substitute column names (by > > > asking the user probably) where UCDs are not uniquely resolvable. > > > > > > Cheers, > > > Tony. > > > > > > > > >>-----Original Message----- > > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > >>Behalf Of Roy Williams > > >>Sent: 07 October 2003 15:50 > > >>To: Clive Page; voql > > >>Subject: Re: A Working document has been submitted > > >> > > >> > > >> > > >>> Region ('CIRCLE J2000 19.5 -36.7 0.02') > > >> > > >>I have a question in the same style. I would like to start > > >>using the UCD ontology within VOQL. I am imagining metadata > > >>queries like > > >> > > >>select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8 > > >> > > >>in order to find tables that have galactic velocities. Can > > >>VOQL be extended in this way? > > >> > > >>Roy > > >> > > > > > > > > > > From owner-voql@eso.org Mon Oct 27 10:06:45 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 h9R91ZFJ008265 for ; Mon, 27 Oct 2003 10:01:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9R91ZoK008264 for voql-outgoing; Mon, 27 Oct 2003 10:01:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h9R90hFJ008014 for ; Mon, 27 Oct 2003 10:00:43 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9R90gs3024882 for ; Mon, 27 Oct 2003 10:00:43 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h9R90de20988 for voql@ivoa.net; Mon, 27 Oct 2003 04:00:39 -0500 Date: Mon, 27 Oct 2003 04:00:39 -0500 From: "Wil O'Mullane" To: voql@ivoa.net Subject: Skynode and ADQL 0.6 Message-ID: <20031027040039.A20962@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I have placed the updated versions on http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL and on http://skyservice.pha.jhu.edu/develop/vo/adql/ please ensure your modifcations are satisfactory Thanks to Pat for the notes from the meeting ! I HAVE ONE QUESTION what about authors - I have switched this to be the working group and switched the editor to be myself Is this acceptable (Masatoshi ?)- i perhaps there is somehting in the standards process about this which I missed (Bob ?) wil From owner-voql@eso.org Mon Oct 27 10:27:20 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 h9R9N1FJ015174 for ; Mon, 27 Oct 2003 10:23:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9R9N1d9015173 for voql-outgoing; Mon, 27 Oct 2003 10:23:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h9R9MSFJ015007 for ; Mon, 27 Oct 2003 10:22:28 +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 h9R9MRB1021241 for ; Mon, 27 Oct 2003 10:22:28 +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 1AE3Zz-00003V-1f for voql@ivoa.net; Mon, 27 Oct 2003 09:22:27 +0000 Received: (qmail 7209 invoked from network); 27 Oct 2003 09:22:47 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 27 Oct 2003 09:22:47 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" , Subject: RE: Skynode and ADQL 0.6 Date: Mon, 27 Oct 2003 09:22:43 -0000 Organization: University of Leicester Message-ID: <001501c39c6b$e0874120$6124d28f@gnowee> 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: <20031027040039.A20962@skysrv.pha.jhu.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, Can you upload the ADQL xsd please. Thanks, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 27 October 2003 09:01 > To: voql@ivoa.net > Subject: Skynode and ADQL 0.6 > > > I have placed the updated versions on > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL > and on > http://skyservice.pha.jhu.edu/develop/vo/adql/ > > please ensure your modifcations are satisfactory > Thanks to Pat for the notes from the meeting ! > > I HAVE ONE QUESTION > what about authors - I have switched this to be the working > group and switched the editor to be myself > Is this acceptable (Masatoshi ?)- i > perhaps there is somehting in the standards process about this > which I missed (Bob ?) > > wil > From owner-voql@eso.org Tue Oct 28 09:35:51 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 h9S8V7LW019999 for ; Tue, 28 Oct 2003 09:31:08 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9S8V7K2019998 for voql-outgoing; Tue, 28 Oct 2003 09:31:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h9S8U8td019716 for ; Tue, 28 Oct 2003 09:30:08 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9S8U7s3025430 for ; Tue, 28 Oct 2003 09:30:07 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id h9S8U2X09017; Tue, 28 Oct 2003 03:30:02 -0500 Date: Tue, 28 Oct 2003 03:30:02 -0500 From: "Wil O'Mullane" To: Tony Linde Cc: voql@ivoa.net Subject: Re: Skynode and ADQL 0.6 Message-ID: <20031028033002.D8900@skysrv.pha.jhu.edu> References: <20031027040039.A20962@skysrv.pha.jhu.edu> <001501c39c6b$e0874120$6124d28f@gnowee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <001501c39c6b$e0874120$6124d28f@gnowee>; from ael@star.le.ac.uk on Mon, Oct 27, 2003 at 09:22:43AM -0000 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I have put a link on the IVOA page to http://skyservice.pha.jhu.edu/devel/AdqlTranslator/ADQLschema.xsd wil On Mon, Oct 27, 2003 at 09:22:43AM -0000, Tony Linde wrote: > Hi Wil, > > Can you upload the ADQL xsd please. > > Thanks, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Wil O'Mullane > > Sent: 27 October 2003 09:01 > > To: voql@ivoa.net > > Subject: Skynode and ADQL 0.6 > > > > > > I have placed the updated versions on > > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL > > and on > > http://skyservice.pha.jhu.edu/develop/vo/adql/ > > > > please ensure your modifcations are satisfactory > > Thanks to Pat for the notes from the meeting ! > > > > I HAVE ONE QUESTION > > what about authors - I have switched this to be the working > > group and switched the editor to be myself > > Is this acceptable (Masatoshi ?)- i > > perhaps there is somehting in the standards process about this > > which I missed (Bob ?) > > > > wil > > From owner-voql@eso.org Tue Oct 28 10:53:44 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 h9S9msvP010272 for ; Tue, 28 Oct 2003 10:48:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9S9msYv010266 for voql-outgoing; Tue, 28 Oct 2003 10:48:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 h9S9m5vP010025 for ; Tue, 28 Oct 2003 10:48:05 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9S9m3B1024230 for ; Tue, 28 Oct 2003 10:48:04 +0100 (CET) Received: from mail-hub.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id SAA06116 for ; Tue, 28 Oct 2003 18:48:06 +0900 (JST) Received: from Cassiopeia.mtk.nao.ac.jp (dhcp-208-193.mtk.nao.ac.jp [133.40.208.193]) by mail-hub.mtk.nao.ac.jp (8.9.3p2/3.7W00121511) with ESMTP id SAA06630 for ; Tue, 28 Oct 2003 18:48:41 +0900 (JST) Message-Id: <6.0.0.20.2.20031028184057.02d0ad70@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 28 Oct 2003 18:47:32 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Re: Skynode and ADQL 0.6 In-Reply-To: <20031027040039.A20962@skysrv.pha.jhu.edu> References: <20031027040039.A20962@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil, At 04:00 03/10/27 -0500, Wil O'Mullane wrote: > >I have placed the updated versions > >please ensure your modifcations are satisfactory Thanks. I will check these documents. >what about authors - I have switched this to be the working group >and switched the editor to be myself >Is this acceptable (Masatoshi ?)- i Because this is a Working Document, I suggest you to make original authours and Alex to be new authours. On editors, my suggestion is to BLANK that part, because nobody editted the document, as far as I know. How do you think ? Cheers, Masatoshi From owner-voql@eso.org Fri Nov 7 16:53:13 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 hA7FqBhm018877 for ; Fri, 7 Nov 2003 16:52:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA7FqBgH018873 for voql-outgoing; Fri, 7 Nov 2003 16:52:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA7FpZhm018618 for ; Fri, 7 Nov 2003 16:51:35 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA7FpZs3018941 for ; Fri, 7 Nov 2003 16:51:35 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 159344613A for ; Fri, 7 Nov 2003 15:51:35 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 30507; Fri, 07 Nov 2003 15:51:34 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9BD734612F for ; Fri, 7 Nov 2003 15:51:34 +0000 (GMT) Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 428084612F for ; Fri, 7 Nov 2003 15:51:34 +0000 (GMT) Received: from localhost (localhost [[UNIX: localhost]]) by fannich.roe.ac.uk (8.11.6/8.9.1) id hA7FpXK04882 for voql@ivoa.net; Fri, 7 Nov 2003 15:51:33 GMT Message-Id: <200311071551.hA7FpXK04882@fannich.roe.ac.uk> Content-Type: text/plain; charset="iso-8859-1" From: Martin Hill Organization: ROE To: voql@ivoa.net Subject: ADQL v0.7 recommendations Date: Fri, 7 Nov 2003 15:51:32 +0000 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=1000.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi all, Now that we (AstroGrid datacenters) have been using ADQL in practice for a bit, we'd like to make a couple of suggestions: 1) The 'Compare' tag is a pain if editing by hand, as we have to deal with > and <. Can we make this either an attribute of the Compare tag, eg , or special tags - eg etc? Probably the former! 2) Reduce the verbosity: a) Move types into attributes instead of tags. For example instead of: 13 etc have: Similarly: to: and cat RA to RA b) I am in two minds about this, but can we replace and with a general ? (I can't remember enough about SQL to know if the order is important). Better still it should be optional, but this might make the schema a bit messy. These changes should not only make it much easier to read and write by hand, but also the object model becomes much simpler to navigate, and GUIs much easier to build. 3) Have we got anywhere a formal definition of what the functions (particularly the neighbourhood matches XMatch and Region) will be converted to in SQL, for those databases that don't include them built-in? Thanks Martin -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From owner-voql@eso.org Fri Nov 7 18:29:05 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 hA7HSNhm021058 for ; Fri, 7 Nov 2003 18:28:23 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA7HSNB6021057 for voql-outgoing; Fri, 7 Nov 2003 18:28:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA7HRjhm020922 for ; Fri, 7 Nov 2003 18:27:45 +0100 (MET) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA7HRis3025278 for ; Fri, 7 Nov 2003 18:27:45 +0100 (CET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 09:27:47 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 Nov 2003 09:27:35 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Nov 2003 09:27:42 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 09:27:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ADQL v0.7 recommendations Date: Fri, 7 Nov 2003 09:27:34 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490159C12E@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADQL v0.7 recommendations Thread-Index: AcOlSJKJ2LugeF3ASwK6rz1Zp7YSOwAAxTkw From: "Jim Gray" To: "Martin Hill" Cc: X-OriginalArrivalTime: 07 Nov 2003 17:27:28.0305 (UTC) FILETIME=[6ABC0A10:01C3A554] X-Scanned-By: MIMEDefang 2.35 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 hA7HSMhm021051 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin Hopefully no human is writing ADQL, it is for machine-to-machine communication. People write a linear syntax like SQL or better yet, use a graphical user interface. To answer your question about cross match and neighbors. No dbms I know of has cross-match and neighbors (with that param list) built in. SkyQuery provides a reference implementation of both based on HTM. The cross-match code itself uses neighbors and a Bayesian distance function. The code is there to look at. A "pure sql" implementation is a bit slower but is pure sql. "A Purely Relational Way of Computing Neighbors on a Sphere," http://research.microsoft.com/~Gray/papers/Neighbors.doc All designs require table-valued functions. Oracle, DB2, SqlServer, MySQL and PostSQL have that I think Patrick Dussud has an implemtation of the spatial functions in DB2 using the HTM code. -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Martin Hill Sent: Friday, November 07, 2003 7:52 AM To: voql@ivoa.net Subject: ADQL v0.7 recommendations Hi all, Now that we (AstroGrid datacenters) have been using ADQL in practice for a bit, we'd like to make a couple of suggestions: 1) The 'Compare' tag is a pain if editing by hand, as we have to deal with > and <. Can we make this either an attribute of the Compare tag, eg , or special tags - eg etc? Probably the former! 2) Reduce the verbosity: a) Move types into attributes instead of tags. For example instead of: 13 etc have: Similarly: to: and cat RA to RA b) I am in two minds about this, but can we replace and with a general ? (I can't remember enough about SQL to know if the order is important). Better still it should be optional, but this might make the schema a bit messy. These changes should not only make it much easier to read and write by hand, but also the object model becomes much simpler to navigate, and GUIs much easier to build. 3) Have we got anywhere a formal definition of what the functions (particularly the neighbourhood matches XMatch and Region) will be converted to in SQL, for those databases that don't include them built-in? Thanks Martin -- Martin Hill Astrogrid/AVO, ROE Tel: 07901 55 24 66 From owner-voql@eso.org Sat Nov 8 02:05:33 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 hA810LQU000889 for ; Sat, 8 Nov 2003 02:00:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA810LSt000888 for voql-outgoing; Sat, 8 Nov 2003 02:00:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA80xjQU000748 for ; Sat, 8 Nov 2003 01:59:47 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA80xjs3016983 for ; Sat, 8 Nov 2003 01:59:45 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id hA80xim7007674; Sat, 8 Nov 2003 00:59:44 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id hA80xiJl007673; Sat, 8 Nov 2003 00:59:44 GMT Received: from 81.178.190.35 ( [81.178.190.35]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Sat, 8 Nov 2003 00:59:44 +0000 Message-ID: <1068253184.3fac40003d29d@netmail.pipex.net> Date: Sat, 8 Nov 2003 00:59:44 +0000 From: martin hill To: Jim Gray Cc: voql@ivoa.net Subject: RE: ADQL v0.7 recommendations References: <25603A6EFF8BA34AB2A49615383CD4490159C12E@RED-MSG-31.redmond.corp.microsoft.com> In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490159C12E@RED-MSG-31.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 81.178.190.35 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Quoting Jim Gray : > Martin > > Hopefully no human is writing ADQL, it is for machine-to-machine > communication. > People write a linear syntax like SQL or better yet, use a graphical > user interface. > Yes and no - ADQL is for our machine interface, but we also want to allow for the typical Astronomer script kiddy :-) who will want to write their own tools and so on. ADQL should be independent of implementations in a way that SQL is (unfortunately) not - otherwise we would just use SQL... So therefore people might write ADQL to cover a set of IVO services. > To answer your question about cross match and neighbors. > > No dbms I know of has cross-match and neighbors (with that param list) > built in. > > SkyQuery provides a reference implementation of both based on HTM. > The cross-match code itself uses neighbors and a Bayesian distance > function. > The code is there to look at. Can you/anyone give me a link to find it rather than hunt for it? ta! > > A "pure sql" implementation is a bit slower but is pure sql. Yes - but if we can provide this as a minimum it's easy on the providers to start with! > "A Purely Relational Way of Computing Neighbors on a Sphere," > http://research.microsoft.com/~Gray/papers/Neighbors.doc Thanks! > > All designs require table-valued functions. > Oracle, DB2, SqlServer, MySQL and PostSQL have that > I think Patrick Dussud has an implemtation of the spatial functions in > DB2 using the HTM code. Do you know where I can find it? Cheers! Martin (Hopefully this makes sense - I've spent the evening in the local pub - I thought I'd sent it as the earlier we can get feedback the better for our current iteration!) > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Martin > Hill > Sent: Friday, November 07, 2003 7:52 AM > To: voql@ivoa.net > Subject: ADQL v0.7 recommendations > > Hi all, > > Now that we (AstroGrid datacenters) have been using ADQL in practice for > a bit, we'd like to make a couple of suggestions: > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal > with > and <. Can we make this either an attribute of the Compare > tag, eg , or special tags - eg > etc? Probably the former! > > 2) Reduce the verbosity: > a) Move types into attributes instead of tags. For example instead > of: > > > > > 13 > > etc > have: > > > Similarly: > > > > to: > > > and > > cat > RA > > to > RA > > b) I am in two minds about this, but can we replace and > with a general ? (I can't remember enough about > SQL to know if the order is important). Better still it should be > optional, but this might make the schema a bit messy. > > These changes should not only make it much easier to read and write > by hand, but also the object model becomes much simpler to navigate, and > GUIs much easier to build. > > 3) Have we got anywhere a formal definition of what the functions > (particularly the neighbourhood matches XMatch and Region) will be > converted to in SQL, for those databases that don't include them > built-in? > > Thanks > > Martin > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 > > > > -- Software Engineer Astrogrid, ROE (www.astrogrid.org) Mob: +44 7901 55 24 66 Fax: +44 131 668 82 64 From owner-voql@eso.org Sat Nov 8 08:12:33 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 hA877VQU014844 for ; Sat, 8 Nov 2003 08:07:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA877UiI014843 for voql-outgoing; Sat, 8 Nov 2003 08:07:30 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA876jQU014774 for ; Sat, 8 Nov 2003 08:06:45 +0100 (MET) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA876hs3021299 for ; Sat, 8 Nov 2003 08:06:44 +0100 (CET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 23:06:30 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Nov 2003 23:06:41 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 23:06:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ADQL v0.7 recommendations Date: Fri, 7 Nov 2003 23:06:34 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490159C845@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADQL v0.7 recommendations Thread-Index: AcOlk5CvTr8r4INoQE2UVcir8pib6AAMfHSg From: "Jim Gray" To: "martin hill" Cc: , "Patrick Dantressangle" X-OriginalArrivalTime: 08 Nov 2003 07:06:42.0703 (UTC) FILETIME=[DD09F1F0:01C3A5C6] X-Scanned-By: MIMEDefang 2.35 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 hA877SQU014839 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The http://www.skyserver.org/myskyserver/ page lists the 3 URLs and nothing else so it is not much of a hunt but try these URLs. http://www.skyserver.org/myskyserver/MySkyServerDr1.zip : the database, all stored procedures, all the spatial functions, all the DDL, and 1% of the data. All self-installing. The Website. Mostly Javascript that implements the gui interface to the DB and also has the 150hours of online instruction, a bit of a webservice for the image processing, and all the code that we used to load the database. http://www.skyserver.org/myskyserver/MySkyServerWI.zip The image processing software is a VisualStuio C# project http://www.skyserver.org/myskyserver/ImgCutoutSrc.zip Patrick Dantressangle's code is public at ROE (he gave it the Astrogrid guys) I assume it is public domain (as the JHU/Microsoft implementation of SkyServer is). I think you are a less than a kilometer from you. He is at dantress@uk.ibm.com -----Original Message----- From: martin hill [mailto:mch@roe.ac.uk] Sent: Friday, November 07, 2003 5:00 PM To: Jim Gray Cc: voql@ivoa.net Subject: RE: ADQL v0.7 recommendations Quoting Jim Gray : > Martin > > Hopefully no human is writing ADQL, it is for machine-to-machine > communication. > People write a linear syntax like SQL or better yet, use a graphical > user interface. > Yes and no - ADQL is for our machine interface, but we also want to allow for the typical Astronomer script kiddy :-) who will want to write their own tools and so on. ADQL should be independent of implementations in a way that SQL is (unfortunately) not - otherwise we would just use SQL... So therefore people might write ADQL to cover a set of IVO services. > To answer your question about cross match and neighbors. > > No dbms I know of has cross-match and neighbors (with that param > list) built in. > > SkyQuery provides a reference implementation of both based on HTM. > The cross-match code itself uses neighbors and a Bayesian distance > function. > The code is there to look at. Can you/anyone give me a link to find it rather than hunt for it? ta! > > A "pure sql" implementation is a bit slower but is pure sql. Yes - but if we can provide this as a minimum it's easy on the providers to start with! > "A Purely Relational Way of Computing Neighbors on a Sphere," > http://research.microsoft.com/~Gray/papers/Neighbors.doc Thanks! > > All designs require table-valued functions. > Oracle, DB2, SqlServer, MySQL and PostSQL have that I think Patrick > Dussud has an implemtation of the spatial functions in > DB2 using the HTM code. Do you know where I can find it? Cheers! Martin (Hopefully this makes sense - I've spent the evening in the local pub - I thought I'd sent it as the earlier we can get feedback the better for our current iteration!) > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > Martin Hill > Sent: Friday, November 07, 2003 7:52 AM > To: voql@ivoa.net > Subject: ADQL v0.7 recommendations > > Hi all, > > Now that we (AstroGrid datacenters) have been using ADQL in practice > for a bit, we'd like to make a couple of suggestions: > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal > with > and <. Can we make this either an attribute of the > Compare tag, eg , or special tags - eg > etc? Probably the former! > > 2) Reduce the verbosity: > a) Move types into attributes instead of tags. For example instead > of: > > > > > 13 > > etc > have: > > > Similarly: > > > > to: > > > and > > cat > RA > > to > RA > > b) I am in two minds about this, but can we replace and > with a general ? (I can't remember enough > about SQL to know if the order is important). Better still it should > be optional, but this might make the schema a bit messy. > > These changes should not only make it much easier to read and write > by hand, but also the object model becomes much simpler to navigate, > and GUIs much easier to build. > > 3) Have we got anywhere a formal definition of what the functions > (particularly the neighbourhood matches XMatch and Region) will be > converted to in SQL, for those databases that don't include them > built-in? > > Thanks > > Martin > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 > > > > -- Software Engineer Astrogrid, ROE (www.astrogrid.org) Mob: +44 7901 55 24 66 Fax: +44 131 668 82 64 From owner-voql@eso.org Sat Nov 8 14:52:03 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 hA8DkvQU029405 for ; Sat, 8 Nov 2003 14:46:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA8Dkvfj029404 for voql-outgoing; Sat, 8 Nov 2003 14:46:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA8Dk6QU029311 for ; Sat, 8 Nov 2003 14:46:10 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA8Dk6s3025698 for ; Sat, 8 Nov 2003 14:46:06 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id hA8Dk5m7016625; Sat, 8 Nov 2003 13:46:05 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id hA8Dk1as016624; Sat, 8 Nov 2003 13:46:01 GMT Received: from 81.178.190.35 ( [81.178.190.35]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Sat, 8 Nov 2003 13:46:01 +0000 Message-ID: <1068299161.3facf39976c0a@netmail.pipex.net> Date: Sat, 8 Nov 2003 13:46:01 +0000 From: martin hill To: Jim Gray Cc: voql@ivoa.net, Patrick Dantressangle Subject: RE: ADQL v0.7 recommendations References: <25603A6EFF8BA34AB2A49615383CD4490159C845@RED-MSG-31.redmond.corp.microsoft.com> In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490159C845@RED-MSG-31.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 81.178.190.35 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Quoting Jim Gray : > The http://www.skyserver.org/myskyserver/ page lists the 3 URLs and > nothing else Excellent that's what I needed. > Patrick Dantressangle's code is public at ROE (he gave it the Astrogrid > guys) > I assume it is public domain (as the JHU/Microsoft implementation of > SkyServer is). > I think you are a less than a kilometer from you. > He is at dantress@uk.ibm.com Patrick, can we publicise the algorithms you use for doing XMatch/Region? I'd like to check that we all agree on it before implementing a version or incorporating your code. Thanks, Martin I'm often less than a kilometer from me :-) > > -----Original Message----- > From: martin hill [mailto:mch@roe.ac.uk] > Sent: Friday, November 07, 2003 5:00 PM > To: Jim Gray > Cc: voql@ivoa.net > Subject: RE: ADQL v0.7 recommendations > > Quoting Jim Gray : > > > Martin > > > > Hopefully no human is writing ADQL, it is for machine-to-machine > > communication. > > People write a linear syntax like SQL or better yet, use a graphical > > user interface. > > > > Yes and no - ADQL is for our machine interface, but we also want to > allow for the typical Astronomer script kiddy :-) who will want to write > their own tools and so on. ADQL should be independent of > implementations in a way that SQL is > (unfortunately) not - otherwise we would just use SQL... So therefore > people might write ADQL to cover a set of IVO services. > > > To answer your question about cross match and neighbors. > > > > No dbms I know of has cross-match and neighbors (with that param > > list) built in. > > > > SkyQuery provides a reference implementation of both based on HTM. > > The cross-match code itself uses neighbors and a Bayesian distance > > function. > > The code is there to look at. > > Can you/anyone give me a link to find it rather than hunt for it? ta! > > > > A "pure sql" implementation is a bit slower but is pure sql. > > Yes - but if we can provide this as a minimum it's easy on the providers > to start with! > > > "A Purely Relational Way of Computing Neighbors on a Sphere," > > http://research.microsoft.com/~Gray/papers/Neighbors.doc > > Thanks! > > > > > All designs require table-valued functions. > > Oracle, DB2, SqlServer, MySQL and PostSQL have that I think Patrick > > Dussud has an implemtation of the spatial functions in > > DB2 using the HTM code. > > Do you know where I can find it? > > Cheers! > > Martin > > (Hopefully this makes sense - I've spent the evening in the local pub - > I thought I'd sent it as the earlier we can get feedback the better for > our current iteration!) > > > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > > Martin Hill > > Sent: Friday, November 07, 2003 7:52 AM > > To: voql@ivoa.net > > Subject: ADQL v0.7 recommendations > > > > Hi all, > > > > Now that we (AstroGrid datacenters) have been using ADQL in practice > > for a bit, we'd like to make a couple of suggestions: > > > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal > > with > and <. Can we make this either an attribute of the > > Compare tag, eg , or special tags - eg > > etc? Probably the former! > > > > 2) Reduce the verbosity: > > a) Move types into attributes instead of tags. For example instead > > of: > > > > > > > > > > 13 > > > > etc > > have: > > > > > > Similarly: > > > > > > > > to: > > > > > > and > > > > cat > > RA > > > > to > > RA > > > > b) I am in two minds about this, but can we replace and > > > with a general ? (I can't remember enough > > about SQL to know if the order is important). Better still it should > > be optional, but this might make the schema a bit messy. > > > > These changes should not only make it much easier to read and write > > > by hand, but also the object model becomes much simpler to navigate, > > and GUIs much easier to build. > > > > 3) Have we got anywhere a formal definition of what the functions > > (particularly the neighbourhood matches XMatch and Region) will be > > converted to in SQL, for those databases that don't include them > > built-in? > > > > Thanks > > > > Martin > > > > -- > > Martin Hill > > Astrogrid/AVO, ROE > > Tel: 07901 55 24 66 > > > > > > > > > > > -- > Software Engineer > Astrogrid, ROE (www.astrogrid.org) > Mob: +44 7901 55 24 66 > Fax: +44 131 668 82 64 > > > -- Software Engineer Astrogrid, ROE (www.astrogrid.org) Mob: +44 7901 55 24 66 Fax: +44 131 668 82 64 From owner-voql@eso.org Sun Nov 9 00:00:30 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 hA8MxB0A003543 for ; Sat, 8 Nov 2003 23:59:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA8MxBxt003542 for voql-outgoing; Sat, 8 Nov 2003 23:59:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA8Mtw0S003174 for ; Sat, 8 Nov 2003 23:58:37 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA8MjNB1009240 for ; Sat, 8 Nov 2003 23:45:24 +0100 (CET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 8 Nov 2003 14:45:43 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 08 Nov 2003 14:45:21 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 8 Nov 2003 14:45:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ADQL v0.7 recommendations Date: Sat, 8 Nov 2003 14:45:13 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490159C884@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADQL v0.7 recommendations Thread-Index: AcOl/quuDB9ioUBURvinI5igDjTGMwASvIWQ From: "Jim Gray" To: "martin hill" Cc: , "Patrick Dantressangle" X-OriginalArrivalTime: 08 Nov 2003 22:45:02.0030 (UTC) FILETIME=[F20D7EE0:01C3A649] X-Scanned-By: MIMEDefang 2.35 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 hA8MxA0A003539 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The skyserver code I pointed you at has the region queries. The crossmatch (Bayesian Spatial Join) code can be gotten from the JHU folks, but It is easier to read the document look at the publications page http://www.skyquery.net/ -----Original Message----- From: martin hill [mailto:mch@roe.ac.uk] Sent: Saturday, November 08, 2003 5:46 AM To: Jim Gray Cc: voql@ivoa.net; Patrick Dantressangle Subject: RE: ADQL v0.7 recommendations Quoting Jim Gray : > The http://www.skyserver.org/myskyserver/ page lists the 3 URLs and > nothing else Excellent that's what I needed. > Patrick Dantressangle's code is public at ROE (he gave it the > Astrogrid > guys) > I assume it is public domain (as the JHU/Microsoft implementation of > SkyServer is). > I think you are a less than a kilometer from you. > He is at dantress@uk.ibm.com Patrick, can we publicise the algorithms you use for doing XMatch/Region? I'd like to check that we all agree on it before implementing a version or incorporating your code. Thanks, Martin I'm often less than a kilometer from me :-) > > -----Original Message----- > From: martin hill [mailto:mch@roe.ac.uk] > Sent: Friday, November 07, 2003 5:00 PM > To: Jim Gray > Cc: voql@ivoa.net > Subject: RE: ADQL v0.7 recommendations > > Quoting Jim Gray : > > > Martin > > > > Hopefully no human is writing ADQL, it is for machine-to-machine > > communication. > > People write a linear syntax like SQL or better yet, use a graphical > > user interface. > > > > Yes and no - ADQL is for our machine interface, but we also want to > allow for the typical Astronomer script kiddy :-) who will want to > write their own tools and so on. ADQL should be independent of > implementations in a way that SQL is > (unfortunately) not - otherwise we would just use SQL... So therefore > people might write ADQL to cover a set of IVO services. > > > To answer your question about cross match and neighbors. > > > > No dbms I know of has cross-match and neighbors (with that param > > list) built in. > > > > SkyQuery provides a reference implementation of both based on HTM. > > The cross-match code itself uses neighbors and a Bayesian distance > > function. > > The code is there to look at. > > Can you/anyone give me a link to find it rather than hunt for it? ta! > > > > A "pure sql" implementation is a bit slower but is pure sql. > > Yes - but if we can provide this as a minimum it's easy on the > providers to start with! > > > "A Purely Relational Way of Computing Neighbors on a Sphere," > > http://research.microsoft.com/~Gray/papers/Neighbors.doc > > Thanks! > > > > > All designs require table-valued functions. > > Oracle, DB2, SqlServer, MySQL and PostSQL have that I think Patrick > > Dussud has an implemtation of the spatial functions in > > DB2 using the HTM code. > > Do you know where I can find it? > > Cheers! > > Martin > > (Hopefully this makes sense - I've spent the evening in the local pub > - I thought I'd sent it as the earlier we can get feedback the better > for our current iteration!) > > > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > > Martin Hill > > Sent: Friday, November 07, 2003 7:52 AM > > To: voql@ivoa.net > > Subject: ADQL v0.7 recommendations > > > > Hi all, > > > > Now that we (AstroGrid datacenters) have been using ADQL in practice > > for a bit, we'd like to make a couple of suggestions: > > > > 1) The 'Compare' tag is a pain if editing by hand, as we have to > > deal with > and <. Can we make this either an attribute of > > the Compare tag, eg , or special tags - eg > > etc? Probably the former! > > > > 2) Reduce the verbosity: > > a) Move types into attributes instead of tags. For example > > instead > > of: > > > > > > > > > > 13 > > > > etc > > have: > > > > > > Similarly: > > > > > > > > to: > > > > > > and > > > > cat > > RA > > > > to > > > table="cat">RA > > > > b) I am in two minds about this, but can we replace > > and > > > with a general ? (I can't remember enough > > about SQL to know if the order is important). Better still it should > > be optional, but this might make the schema a bit messy. > > > > These changes should not only make it much easier to read and > > write > > > by hand, but also the object model becomes much simpler to navigate, > > and GUIs much easier to build. > > > > 3) Have we got anywhere a formal definition of what the functions > > (particularly the neighbourhood matches XMatch and Region) will be > > converted to in SQL, for those databases that don't include them > > built-in? > > > > Thanks > > > > Martin > > > > -- > > Martin Hill > > Astrogrid/AVO, ROE > > Tel: 07901 55 24 66 > > > > > > > > > > > -- > Software Engineer > Astrogrid, ROE (www.astrogrid.org) > Mob: +44 7901 55 24 66 > Fax: +44 131 668 82 64 > > > -- Software Engineer Astrogrid, ROE (www.astrogrid.org) Mob: +44 7901 55 24 66 Fax: +44 131 668 82 64 From owner-voql@eso.org Sun Nov 9 18:58:11 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 hA9Hud0A028163 for ; Sun, 9 Nov 2003 18:56:39 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA9HudC6028162 for voql-outgoing; Sun, 9 Nov 2003 18:56:39 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hA9Hu50A028092 for ; Sun, 9 Nov 2003 18:56:05 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA9Hu4B1019973 for ; Sun, 9 Nov 2003 18:56:04 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hA9Hu1E30467; Sun, 9 Nov 2003 12:56:01 -0500 Date: Sun, 9 Nov 2003 12:56:01 -0500 From: "Wil O'Mullane" To: Martin Hill Cc: voql@ivoa.net Subject: Re: ADQL v0.7 recommendations Message-ID: <20031109125601.D30074@skysrv.pha.jhu.edu> References: <200311071551.hA7FpXK04882@fannich.roe.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200311071551.hA7FpXK04882@fannich.roe.ac.uk>; from mch@roe.ac.uk on Fri, Nov 07, 2003 at 03:51:32PM +0000 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: normally I do not like attribs - but here you a point. I'll talk with vivkek ans see if there is any parser impact. Skynode 0.6 has a detailed description of Xmatch .. wil On Fri, Nov 07, 2003 at 03:51:32PM +0000, Martin Hill wrote: > Hi all, > > Now that we (AstroGrid datacenters) have been using ADQL in practice for a > bit, we'd like to make a couple of suggestions: > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal with > > and <. Can we make this either an attribute of the Compare tag, eg > , or special tags - eg > etc? Probably the former! > > 2) Reduce the verbosity: > a) Move types into attributes instead of tags. For example instead of: > > > > > 13 > > etc > have: > > > Similarly: > > > > to: > > > and > > cat > RA > > to > RA > > b) I am in two minds about this, but can we replace and > with a general ? (I can't remember enough about SQL > to know if the order is important). Better still it should be optional, but > this might make the schema a bit messy. > > These changes should not only make it much easier to read and write by > hand, but also the object model becomes much simpler to navigate, and GUIs > much easier to build. > > 3) Have we got anywhere a formal definition of what the functions > (particularly the neighbourhood matches XMatch and Region) will be converted > to in SQL, for those databases that don't include them built-in? > > Thanks > > Martin > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 From owner-voql@eso.org Mon Nov 10 22:16:44 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 hAALFVP1020152 for ; Mon, 10 Nov 2003 22:15:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAALFVGB020151 for voql-outgoing; Mon, 10 Nov 2003 22:15:31 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hAALEvP1019991 for ; Mon, 10 Nov 2003 22:14:57 +0100 (MET) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAALEvs3016748 for ; Mon, 10 Nov 2003 22:14:57 +0100 (CET) Received: from dial.pipex.com (81-178-173-227.dsl.pipex.com [81.178.173.227]) by pengo.systems.pipex.net (Postfix) with ESMTP id E16D24C0017E; Mon, 10 Nov 2003 21:14:53 +0000 (GMT) Message-ID: <3FAFFFE7.3070802@dial.pipex.com> Date: Mon, 10 Nov 2003 21:15:19 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" Cc: Martin Hill , voql@ivoa.net Subject: Re: ADQL v0.7 recommendations - tags vs attributes References: <200311071551.hA7FpXK04882@fannich.roe.ac.uk> <20031109125601.D30074@skysrv.pha.jhu.edu> In-Reply-To: <20031109125601.D30074@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil O'Mullane wrote: > normally I do not like attribs - but here you a point. > I'll talk with vivkek ans see if there is any parser impact. At the risk of disappearing up my own donkey (as this can be a long off-topic discussion!) Normally yes I agree that values should not be stored as attributes (whatever a value is) which is why I'm a little hesitant over putting the contents in as an attribute. But it might be more convenient than the special tags. However I do like using attributes to describe what a value *is*/means (eg type information), and use nested tags instead to describe structure. Seems more natural somehow... Cheers Martin From owner-voql@eso.org Wed Nov 12 10:25:48 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 hAC9P0cF012183 for ; Wed, 12 Nov 2003 10:25:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAC9P0BE012174 for voql-outgoing; Wed, 12 Nov 2003 10:25:00 +0100 (MET) Message-Id: <200311120925.hAC9P0BE012174@mercury.hq.eso.org> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Date: Wed, 12 Nov 2003 09:38:40 +0100 From: Laurent MICHEL To: Jim Gray , voql@ivoa.net Subject: Re: ADQL v0.7 recommendations Sender: owner-voql@eso.org Precedence: bulk Reply-To: Laurent MICHEL X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Jim, I'm just now trying to join the forum and I would give some precision about the existence of systems implementing cross match and neighbours . At least one such system does exists. One of the public interfaces (http://xcatdb.u-strasbg.fr) of the XMM-Newton serendipitous source catalogue (1XMM) implements such associations. The XMM-Newton pipeline computes correlations between X ray sources and about 200 archival catalogues. These correlation links, delivered in FITS tables, are stored in our database by populating N-M relationships between X ray data and archival data. Our system is able to process complex queries including constraints on correlated data patterns. Below is an example (in formal language, GUI is normally used for query set-up) select XRay sources correlated with at least one Simbad entry at less than 3arsec and with no 1RXS entry but having some radio counterparts The system is totally based on Object Technology, so that join issues are dramatically reduced. OQL query language is used. My feeling is that operators processing such associations should have some place in the VO query language. LM Jim Gray wrote: > > Martin > > Hopefully no human is writing ADQL, it is for machine-to-machine > communication. > People write a linear syntax like SQL or better yet, use a graphical > user interface. > > To answer your question about cross match and neighbors. > > No dbms I know of has cross-match and neighbors (with that param list) > built in. > > SkyQuery provides a reference implementation of both based on HTM. > The cross-match code itself uses neighbors and a Bayesian distance > function. > The code is there to look at. > > A "pure sql" implementation is a bit slower but is pure sql. > "A Purely Relational Way of Computing Neighbors on a Sphere," > http://research.microsoft.com/~Gray/papers/Neighbors.doc > > All designs require table-valued functions. > Oracle, DB2, SqlServer, MySQL and PostSQL have that > I think Patrick Dussud has an implemtation of the spatial functions in > DB2 using the HTM code. > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Martin > Hill > Sent: Friday, November 07, 2003 7:52 AM > To: voql@ivoa.net > Subject: ADQL v0.7 recommendations > > Hi all, > > Now that we (AstroGrid datacenters) have been using ADQL in practice for > a bit, we'd like to make a couple of suggestions: > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal > with > and <. Can we make this either an attribute of the Compare > tag, eg , or special tags - eg > etc? Probably the former! > > 2) Reduce the verbosity: > a) Move types into attributes instead of tags. For example instead > of: > > > > > 13 > > etc > have: > > > Similarly: > > > > to: > > > and > > cat > RA > > to > RA > > b) I am in two minds about this, but can we replace and > with a general ? (I can't remember enough about > SQL to know if the order is important). Better still it should be > optional, but this might make the schema a bit messy. > > These changes should not only make it much easier to read and write > by hand, but also the object model becomes much simpler to navigate, and > GUIs much easier to build. > > 3) Have we got anywhere a formal definition of what the functions > (particularly the neighbourhood matches XMatch and Region) will be > converted to in SQL, for those databases that don't include them > built-in? > > Thanks > > Martin > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 -- ---- Laurent MICHEL Tel (33 0) 3 90 24 24 37 Observatoire de Strasbourg Fax (33 0) 3 90 24 24 32 11 Rue de l'Universite Mail laurent.michel@astro.u-strasbg.fr 67000 Strasbourg (France) Web http://astro.u-strasbg.fr/~michel --- From owner-voql@eso.org Wed Nov 12 18:24:02 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 hACHMxcF009530 for ; Wed, 12 Nov 2003 18:22:59 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hACHMx85009529 for voql-outgoing; Wed, 12 Nov 2003 18:22:59 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hACHMNcF009385 for ; Wed, 12 Nov 2003 18:22:23 +0100 (MET) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hACHMMB1017945 for ; Wed, 12 Nov 2003 18:22:22 +0100 (CET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 09:22:21 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 09:22:19 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 09:22:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Cross match in AQL Date: Wed, 12 Nov 2003 09:22:30 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD449016567A6@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cross match in AQL Thread-Index: AcOo+OzHhGmX/DiWT3Cr9bpPlIMzOgAQHh2w From: "Jim Gray" To: "Laurent MICHEL" , Cc: "Alex Szalay" , "Tanu Malik" , "Maria A. Nieto-Santisteban" X-OriginalArrivalTime: 12 Nov 2003 17:22:25.0870 (UTC) FILETIME=[8A88DEE0:01C3A941] X-Scanned-By: MIMEDefang 2.35 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 hACHMwcF009521 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Programming language design is a specialty. All programmers are experts in this specialty -- indeed each of us can design the perfect language. I have spent much of my career avoiding language design wars, but I have helped others design some horrible languages (e.g. SQL). The OO language wars started in the mid 70's and are still being fought (sounds like you are on the front lines). I have tried to avoid them and will try to avoid this one -- and just focus on the plumbing. In SkyQuery there are inner-joins and outer-joins (borrowed from relational database). A inner join B requires that both A and B exist. A outer join B generates a record if either A or B exists (it fills in null for the missing half). There are also left and right outer join for the asymmetric case. I would use the outer-join syntax for the queries you mention below. As for the defining spatial cross-match, this is something astronomers have been doing for several decades. There are really erudite papers on the topic. There are MANY different ways to do it. SkyQuery has one implementation (one operator), SkyServer has another, and I suspect that there are at least 100 other implementations in use. The way to accommodate all this is to define one trivial cross match (Xmatch in SkyQuery) allow anyone to define a cross-match operator (that returns "distance") and allow people to write queries like Select A.*, B.* FROM A outer join B ON MyXmatch(A,B) < .1 WHERE This avoids the religion (anyone can define his own operator). All this is the "on the wire format". You are welcome to implement it in any language you want within your server. If you have a favorite database technology, that is your business. A good way to demonstrate your object technology would be to implement the SDSS And run the 20 queries on it. The SqlServer performance is public, and the DB2 performance will soon be public. So, you have two other systems to compare against, and the data size is large enough (600GB) so that join speed is a significant issue. You can find all the source code and the 0.5% dataset at http://www.skyserver.org/myskyserver/ -----Original Message----- From: michel@xmm.u-strasbg.fr [mailto:michel@xmm.u-strasbg.fr] On Behalf Of Laurent MICHEL Sent: Wednesday, November 12, 2003 12:39 AM To: Jim Gray; voql@ivoa.net Subject: Re: ADQL v0.7 recommendations Jim, I'm just now trying to join the forum and I would give some precision about the existence of systems implementing cross match and neighbours . At least one such system does exists. One of the public interfaces (http://xcatdb.u-strasbg.fr) of the XMM-Newton serendipitous source catalogue (1XMM) implements such associations. The XMM-Newton pipeline computes correlations between X ray sources and about 200 archival catalogues. These correlation links, delivered in FITS tables, are stored in our database by populating N-M relationships between X ray data and archival data. Our system is able to process complex queries including constraints on correlated data patterns. Below is an example (in formal language, GUI is normally used for query set-up) select XRay sources correlated with at least one Simbad entry at less than 3arsec and with no 1RXS entry but having some radio counterparts The system is totally based on Object Technology, so that join issues are dramatically reduced. OQL query language is used. My feeling is that operators processing such associations should have some place in the VO query language. LM Jim Gray wrote: > > Martin > > Hopefully no human is writing ADQL, it is for machine-to-machine > communication. > People write a linear syntax like SQL or better yet, use a graphical > user interface. > > To answer your question about cross match and neighbors. > > No dbms I know of has cross-match and neighbors (with that param > list) built in. > > SkyQuery provides a reference implementation of both based on HTM. > The cross-match code itself uses neighbors and a Bayesian distance > function. > The code is there to look at. > > A "pure sql" implementation is a bit slower but is pure sql. > "A Purely Relational Way of Computing Neighbors on a Sphere," > http://research.microsoft.com/~Gray/papers/Neighbors.doc > > All designs require table-valued functions. > Oracle, DB2, SqlServer, MySQL and PostSQL have that I think Patrick > Dussud has an implemtation of the spatial functions in > DB2 using the HTM code. > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > Martin Hill > Sent: Friday, November 07, 2003 7:52 AM > To: voql@ivoa.net > Subject: ADQL v0.7 recommendations > > Hi all, > > Now that we (AstroGrid datacenters) have been using ADQL in practice > for a bit, we'd like to make a couple of suggestions: > > 1) The 'Compare' tag is a pain if editing by hand, as we have to deal > with > and <. Can we make this either an attribute of the > Compare tag, eg , or special tags - eg > etc? Probably the former! > > 2) Reduce the verbosity: > a) Move types into attributes instead of tags. For example instead > of: > > > > > 13 > > etc > have: > > > Similarly: > > > > to: > > > and > > cat > RA > > to > RA > > b) I am in two minds about this, but can we replace and > with a general ? (I can't remember enough > about SQL to know if the order is important). Better still it should > be optional, but this might make the schema a bit messy. > > These changes should not only make it much easier to read and write > by hand, but also the object model becomes much simpler to navigate, > and GUIs much easier to build. > > 3) Have we got anywhere a formal definition of what the functions > (particularly the neighbourhood matches XMatch and Region) will be > converted to in SQL, for those databases that don't include them > built-in? > > Thanks > > Martin > > -- > Martin Hill > Astrogrid/AVO, ROE > Tel: 07901 55 24 66 -- ---- Laurent MICHEL Tel (33 0) 3 90 24 24 37 Observatoire de Strasbourg Fax (33 0) 3 90 24 24 32 11 Rue de l'Universite Mail laurent.michel@astro.u-strasbg.fr 67000 Strasbourg (France) Web http://astro.u-strasbg.fr/~michel --- From owner-voql@eso.org Tue Dec 2 10:02:40 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 hB292Fi9022967 for ; Tue, 2 Dec 2003 10:02:15 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB292F5M022964 for voql-outgoing; Tue, 2 Dec 2003 10:02:15 +0100 (MET) Message-Id: <200312020902.hB292F5M022964@mercury.hq.eso.org> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f Date: Mon, 01 Dec 2003 16:03:09 -0800 From: John Good To: voql@ivoa.net Subject: Comments on ADQL v0.6 Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I've just made a first pass through the ADQL v0.6 document. It looks reasonable, though there are a couple of minor things that struck me: I would very much like to get beyond the limitations of the "Cone Search". All IRSA services already allow polygonal regions on the sky and it has been our experience that for anything beyond a very small search size (i.e. looking for a single source) box-like searches far outweigh cone searches in frequency. I notice that the list of "math functions" matches PostgreSQL but no other DBMS that I am aware of. For instance, SQLServer, MySQL, and Informix use "log10" while Oracle and PostgreSQL use "log". MySQL and PostgreSQL have a "radians" function while the others don't. A different subset supports "cot". It would probably be best to go with an unambiguous, lowest-common-denominator approach since not all systems support extension. The document would also be well served by a few well-crafted examples. It is often much easier to see a problem in an example than in schema definitions. - John Good From owner-voql@eso.org Tue Dec 2 11:15:46 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 hB2AEji9009435 for ; Tue, 2 Dec 2003 11:14:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2AEjHF009433 for voql-outgoing; Tue, 2 Dec 2003 11:14:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2AE7i9009261 for ; Tue, 2 Dec 2003 11:14:08 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2AE7d8004211 for ; Tue, 2 Dec 2003 11:14:07 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.24) id 1AR7Xi-0002Uh-RJ for voql@ivoa.net; Tue, 02 Dec 2003 10:14:06 +0000 Received: (qmail 12335 invoked from network); 2 Dec 2003 10:14:28 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 2 Dec 2003 10:14:28 -0000 Date: Tue, 2 Dec 2003 10:14:06 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 In-Reply-To: <200312020902.hB292F5M022964@mercury.hq.eso.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 1 Dec 2003, John Good wrote: > I notice that the list of "math functions" matches PostgreSQL > but no other DBMS that I am aware of. For instance, > SQLServer, MySQL, and Informix use "log10" while Oracle > and PostgreSQL use "log". MySQL and PostgreSQL have > a "radians" function while the others don't. A different subset > supports "cot". It would probably be best to go with an > unambiguous, lowest-common-denominator approach since > not all systems support extension. This is something that I was also concerned about. The problem is that it is going to be quite hard to write astronomical code if the list of functions in ADQL is the rather short list supported by _every_ DBMS that astronomers currently use. It's worth pointint out that some sites are not even using a relational DBMS at all, as shown by the popularity of sites based on WCSTOOLS and one or two using the even more basic BROWSE. I had assumed that the ADQL document was based on the list of functions supported by JDBC, which in turn is said to be based on SQL92 Entry Level. The functions supported by JDBC 3.0 are listed at: http://java.sun.com/products/jdbc/driverdevs.html The JDBC list includes RADIANS and DEGREES (without which we are going to find life difficult) and both LOG and LOG10 but not COT. It is hard to find the SQL92 Standard on line (I think perhaps it's a document that you have to purchase as hard-copy), but a little googling found me x3h2-93-091.ps.Z from http://www.funet.fi/pub/standards/sql/ which looks like the genuine article. I've checked the index and skimmed through it all (a mere 1004 pages) but failed to find a list of functions supported, except the obvious ones like COUNT and MAX. So maybe the Standard is so inadequate it's no help at all. This is very peculiar. It seems to be well known in the trade that the US National Institute of Standards and Technology used to be heavily involved in the SQL Standards process, and used to report on conformance by the major players. But some years ago, presumably after pressure from the large vendors whose products showed a lack of standards conformance, they were directed by the US Government to withdraw from this area. As a result, practically no current DBMS, and certainly none of the popular ones, conforms fully to any official SQL Standard. The vendors, obviously, want to lock you in to their product. This is very unfortunate, and we have to put up with the consequences. My own view is that the appropriate course for the VO is to settle on a reasonably standard set of functions, and the list of JDBC seems a good choice. This means, of course, that those using a DBMS which lacks these functions will have either have to switch to a more astronomer-friendly DBMS (such as Postgres) or provide a user-defined function to fill the gap. In the case of the RADIANS function, at least, this isn't so difficult, as long as your DBMS supports user-defined functions at all. > The document would also be well served by a few well-crafted > examples. It is often much easier to see a problem in an > example than in schema definitions. Agreed. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Dec 2 11:59:26 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 hB2Awbi9019589 for ; Tue, 2 Dec 2003 11:58:37 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2Awbsh019588 for voql-outgoing; Tue, 2 Dec 2003 11:58:37 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2Aw2i9019430 for ; Tue, 2 Dec 2003 11:58:03 +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 SMTP id hB2Aw2s3026640 for ; Tue, 2 Dec 2003 11:58:02 +0100 (CET) Received: from dial.pipex.com (81-86-232-154.dsl.pipex.com [81.86.232.154]) by shockwave.systems.pipex.net (Postfix) with ESMTP id D5ACF1C006CD; Tue, 2 Dec 2003 10:58:00 +0000 (GMT) Message-ID: <3FCC7037.7020604@dial.pipex.com> Date: Tue, 02 Dec 2003 10:57:59 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Good Cc: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 - feature creep References: <200312020902.hB292F5M022964@mercury.hq.eso.org> In-Reply-To: <200312020902.hB292F5M022964@mercury.hq.eso.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I would prefer to see a 'minimum set', as anyone who implements an adql-compliant datacenter has to implement all the adql functions not provided by the RDBMS. A simple query function set will presumably provide enough to do a first-stage query that can be refined elsewhere? This is obviously a balance between those who use/access data and those providing it! To contradict myself, a point in favour of providing more functionality at the data server end is that the work only has to be done there once to implement it, and then it is available for all queries. However at this stage, I would rather see a simple ADQL that is 'easy' to implement anywhere. When the VO is 'up and running' we can look at extending it for ADQL v2. I would even prefer limiting region searches to a vaguer 'neighbourhood search', specified like a cone search (RA, Dec, Radius) but possibly implemented as a rectangle or HTM depending on the backend. Again, the results can then be refined elsewhere. An alternative is for a datacenter to publish as part of its metadata the subset of ADQL that it implements. We (AstroGrid datacenter) are thinking that this would be useful for many kinds of data querying that are not RDB-backed. For example, we have implemented ADQL-like interfaces to NVO-Cone-Search servers (where SELECT and ORDER BY are irrelevent, and only REGION-CIRCLE has meaning). Similarly we are implenting one for selecting FITS files from their keywords, and again the full SQL-like features are not available. How do folks feel about this subset publishing? Cheers, Martin John Good wrote: > I've just made a first pass through the ADQL v0.6 document. > It looks reasonable, though there are a couple of minor things > that struck me: > > I would very much like to get beyond the limitations of the > "Cone Search". All IRSA services already allow polygonal > regions on the sky and it has been our experience that for > anything beyond a very small search size (i.e. looking for a > single source) box-like searches far outweigh cone searches > in frequency. > > I notice that the list of "math functions" matches PostgreSQL > but no other DBMS that I am aware of. For instance, > SQLServer, MySQL, and Informix use "log10" while Oracle > and PostgreSQL use "log". MySQL and PostgreSQL have > a "radians" function while the others don't. A different subset > supports "cot". It would probably be best to go with an > unambiguous, lowest-common-denominator approach since > not all systems support extension. > > The document would also be well served by a few well-crafted > examples. It is often much easier to see a problem in an > example than in schema definitions. > > - John Good -- Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Tue Dec 2 12:01:12 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 hB2B0Ti9020232 for ; Tue, 2 Dec 2003 12:00:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2B0TRV020228 for voql-outgoing; Tue, 2 Dec 2003 12:00:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2B0MTc020182; Tue, 2 Dec 2003 12:00:22 +0100 (MET) Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hB2B0Mt28372; Tue, 2 Dec 2003 12:00:22 +0100 (MET) From: Andreas Wicenec Organization: European Southern Observatory To: Clive Page , voql@ivoa.net Subject: Re: Comments on ADQL v0.6 Date: Tue, 2 Dec 2003 12:00:22 +0100 User-Agent: KMail/1.5.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312021200.22436.awicenec@eso.org> Sender: owner-voql@eso.org Precedence: bulk Reply-To: Andreas Wicenec X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear all, just a little comment on this: At least all the major DBMS support now user defined functions (UDFs) mostly written in Java, i.e. you can in fact define your own function and use it afterwards in normal SQL statements. Like this you are not that dependent on the provided functions anymore... Andreas On Tuesday 02 December 2003 11:14, Clive Page wrote: > On Mon, 1 Dec 2003, John Good wrote: > > I notice that the list of "math functions" matches PostgreSQL > > but no other DBMS that I am aware of. For instance, > > SQLServer, MySQL, and Informix use "log10" while Oracle > > and PostgreSQL use "log". MySQL and PostgreSQL have > > a "radians" function while the others don't. A different subset > > supports "cot". It would probably be best to go with an > > unambiguous, lowest-common-denominator approach since > > not all systems support extension. > > This is something that I was also concerned about. The problem is that it > is going to be quite hard to write astronomical code if the list of > functions in ADQL is the rather short list supported by _every_ DBMS that > astronomers currently use. It's worth pointint out that some sites are > not even using a relational DBMS at all, as shown by the popularity of > sites based on WCSTOOLS and one or two using the even more basic BROWSE. > > I had assumed that the ADQL document was based on the list of functions > supported by JDBC, which in turn is said to be based on SQL92 Entry Level. > The functions supported by JDBC 3.0 are listed at: > http://java.sun.com/products/jdbc/driverdevs.html > > The JDBC list includes RADIANS and DEGREES (without which we are going to > find life difficult) and both LOG and LOG10 but not COT. > > It is hard to find the SQL92 Standard on line (I think perhaps it's a > document that you have to purchase as hard-copy), but a little googling > found me x3h2-93-091.ps.Z from http://www.funet.fi/pub/standards/sql/ > which looks like the genuine article. I've checked the index and skimmed > through it all (a mere 1004 pages) but failed to find a list of functions > supported, except the obvious ones like COUNT and MAX. So maybe the > Standard is so inadequate it's no help at all. This is very peculiar. > > It seems to be well known in the trade that the US National Institute of > Standards and Technology used to be heavily involved in the SQL Standards > process, and used to report on conformance by the major players. But some > years ago, presumably after pressure from the large vendors whose products > showed a lack of standards conformance, they were directed by the US > Government to withdraw from this area. As a result, practically no > current DBMS, and certainly none of the popular ones, conforms fully to > any official SQL Standard. The vendors, obviously, want to lock you in to > their product. This is very unfortunate, and we have to put up with the > consequences. > > > My own view is that the appropriate course for the VO is to settle on a > reasonably standard set of functions, and the list of JDBC seems a good > choice. This means, of course, that those using a DBMS which lacks these > functions will have either have to switch to a more astronomer-friendly > DBMS (such as Postgres) or provide a user-defined function to fill the > gap. In the case of the RADIANS function, at least, this isn't so > difficult, as long as your DBMS supports user-defined functions at all. > > > The document would also be well served by a few well-crafted > > examples. It is often much easier to see a problem in an > > example than in schema definitions. > > Agreed. From owner-voql@eso.org Tue Dec 2 17:04:57 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 hB2G46i9004188 for ; Tue, 2 Dec 2003 17:04:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2G45aA004187 for voql-outgoing; Tue, 2 Dec 2003 17:04:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2G3Mi9003977 for ; Tue, 2 Dec 2003 17:03:22 +0100 (MET) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2G3Ld8014227 for ; Tue, 2 Dec 2003 17:03:21 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20031202160318.KHPH10749.mta01-svc.ntlworld.com@gnowee> for ; Tue, 2 Dec 2003 16:03:18 +0000 From: "Tony Linde" To: Subject: RE: Comments on ADQL v0.6 - function list Date: Tue, 2 Dec 2003 16:03:31 -0000 Organization: University of Leicester Message-ID: <00a401c3b8ed$e378f1a0$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 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 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 hB2G43i9004179 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'd agree that we should settle on a standard list of functions and Clive's suggestion of JDBC seems reasonable, supplemented perhaps by some core astro ones as suggested in the VOQL documents. We should probably namespace the function list separate from the syntax of the language so that they can change at different rates and be supported differentially by query service implementations. We need some way of allowing a registered service to indicate that its Query method (or 'port type' as I believe the WS people call it) supports: VOQL v(2.00-2.37), VOQLFunctions-Basic v1.2, VOQLFunctions-Spatial v3.*, and FredsSpecialSearchFunction v0.0.1. Easy eh? Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Clive Page > Sent: 02 December 2003 10:14 > To: voql@ivoa.net > Subject: Re: Comments on ADQL v0.6 > > > On Mon, 1 Dec 2003, John Good wrote: > > > I notice that the list of "math functions" matches PostgreSQL > > but no other DBMS that I am aware of. For instance, > > SQLServer, MySQL, and Informix use "log10" while Oracle > > and PostgreSQL use "log". MySQL and PostgreSQL have > > a "radians" function while the others don't. A different subset > > supports "cot". It would probably be best to go with an > > unambiguous, lowest-common-denominator approach since > > not all systems support extension. > > This is something that I was also concerned about. The > problem is that it is going to be quite hard to write > astronomical code if the list of functions in ADQL is the > rather short list supported by _every_ DBMS that astronomers > currently use. It's worth pointint out that some sites are > not even using a relational DBMS at all, as shown by the > popularity of sites based on WCSTOOLS and one or two using > the even more basic BROWSE. > > I had assumed that the ADQL document was based on the list of > functions supported by JDBC, which in turn is said to be > based on SQL92 Entry Level. The functions supported by JDBC > 3.0 are listed at: http://java.sun.com/products/jdbc/driverdevs.html > > The JDBC list includes RADIANS and DEGREES (without which we > are going to find life difficult) and both LOG and LOG10 but not COT. > > It is hard to find the SQL92 Standard on line (I think > perhaps it's a document that you have to purchase as > hard-copy), but a little googling found me x3h2-93-091.ps.Z > from http://www.funet.fi/pub/standards/sql/ > which looks like the genuine article. I've checked the index > and skimmed through it all (a mere 1004 pages) but failed to > find a list of functions supported, except the obvious ones > like COUNT and MAX. So maybe the Standard is so inadequate > it's no help at all. This is very peculiar. > > It seems to be well known in the trade that the US National > Institute of Standards and Technology used to be heavily > involved in the SQL Standards process, and used to report on > conformance by the major players. But some years ago, > presumably after pressure from the large vendors whose > products showed a lack of standards conformance, they were > directed by the US Government to withdraw from this area. As > a result, practically no current DBMS, and certainly none of > the popular ones, conforms fully to any official SQL > Standard. The vendors, obviously, want to lock you in to > their product. This is very unfortunate, and we have to put > up with the consequences. > > > My own view is that the appropriate course for the VO is to > settle on a reasonably standard set of functions, and the > list of JDBC seems a good choice. This means, of course, > that those using a DBMS which lacks these functions will have > either have to switch to a more astronomer-friendly DBMS > (such as Postgres) or provide a user-defined function to fill > the gap. In the case of the RADIANS function, at least, this > isn't so difficult, as long as your DBMS supports > user-defined functions at all. > > > > The document would also be well served by a few > well-crafted examples. > > It is often much easier to see a problem in an example than > in schema > > definitions. > > Agreed. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > From owner-voql@eso.org Tue Dec 2 17:20:40 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 hB2GJqi9008861 for ; Tue, 2 Dec 2003 17:19:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2GJqRl008860 for voql-outgoing; Tue, 2 Dec 2003 17:19:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2GJEi9008719 for ; Tue, 2 Dec 2003 17:19:14 +0100 (MET) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2GJCs3005746 for ; Tue, 2 Dec 2003 17:19:13 +0100 (CET) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 08:19:17 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Dec 2003 08:19:00 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Dec 2003 08:19:12 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 08:19:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on ADQL v0.6 Date: Tue, 2 Dec 2003 08:19:56 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD449012D92DB@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on ADQL v0.6 Thread-Index: AcO4vnj1S0S2e7MVRlywbkDWovKaHgAL2xug From: "Jim Gray" To: "Clive Page" , X-OriginalArrivalTime: 02 Dec 2003 16:19:12.0657 (UTC) FILETIME=[05DD8010:01C3B8F0] X-Scanned-By: MIMEDefang 2.35 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 hB2GJpi9008851 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Just as a correction, SqlServer has log10 and radians and cot and acos and .. All the math functions in Excel. Sybase is the same This is the heritage of the Sybase/Microsoft/Excel interop effort of 1988. It may be that DB2 or Oracle have different names for those functions, If so it is easy enough to define new functions in Oracle and DB2 with the "standard names" that map to these "Excel standard" names. This is actually an area where there is a fair amount of uniformity. -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Clive Page Sent: Tuesday, December 02, 2003 2:14 AM To: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 On Mon, 1 Dec 2003, John Good wrote: > I notice that the list of "math functions" matches PostgreSQL > but no other DBMS that I am aware of. For instance, > SQLServer, MySQL, and Informix use "log10" while Oracle > and PostgreSQL use "log". MySQL and PostgreSQL have > a "radians" function while the others don't. A different subset > supports "cot". It would probably be best to go with an > unambiguous, lowest-common-denominator approach since > not all systems support extension. This is something that I was also concerned about. The problem is that it is going to be quite hard to write astronomical code if the list of functions in ADQL is the rather short list supported by _every_ DBMS that astronomers currently use. It's worth pointint out that some sites are not even using a relational DBMS at all, as shown by the popularity of sites based on WCSTOOLS and one or two using the even more basic BROWSE. I had assumed that the ADQL document was based on the list of functions supported by JDBC, which in turn is said to be based on SQL92 Entry Level. The functions supported by JDBC 3.0 are listed at: http://java.sun.com/products/jdbc/driverdevs.html The JDBC list includes RADIANS and DEGREES (without which we are going to find life difficult) and both LOG and LOG10 but not COT. It is hard to find the SQL92 Standard on line (I think perhaps it's a document that you have to purchase as hard-copy), but a little googling found me x3h2-93-091.ps.Z from http://www.funet.fi/pub/standards/sql/ which looks like the genuine article. I've checked the index and skimmed through it all (a mere 1004 pages) but failed to find a list of functions supported, except the obvious ones like COUNT and MAX. So maybe the Standard is so inadequate it's no help at all. This is very peculiar. It seems to be well known in the trade that the US National Institute of Standards and Technology used to be heavily involved in the SQL Standards process, and used to report on conformance by the major players. But some years ago, presumably after pressure from the large vendors whose products showed a lack of standards conformance, they were directed by the US Government to withdraw from this area. As a result, practically no current DBMS, and certainly none of the popular ones, conforms fully to any official SQL Standard. The vendors, obviously, want to lock you in to their product. This is very unfortunate, and we have to put up with the consequences. My own view is that the appropriate course for the VO is to settle on a reasonably standard set of functions, and the list of JDBC seems a good choice. This means, of course, that those using a DBMS which lacks these functions will have either have to switch to a more astronomer-friendly DBMS (such as Postgres) or provide a user-defined function to fill the gap. In the case of the RADIANS function, at least, this isn't so difficult, as long as your DBMS supports user-defined functions at all. > The document would also be well served by a few well-crafted examples. > It is often much easier to see a problem in an example than in schema > definitions. Agreed. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Dec 2 17:39:49 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 hB2Gd2i9013547 for ; Tue, 2 Dec 2003 17:39:02 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2Gd1xh013546 for voql-outgoing; Tue, 2 Dec 2003 17:39:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2GcRi9013440 for ; Tue, 2 Dec 2003 17:38:27 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2GcQs3006341 for ; Tue, 2 Dec 2003 17:38:26 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hB2GcOL01067; Tue, 2 Dec 2003 11:38:24 -0500 Date: Tue, 2 Dec 2003 11:38:24 -0500 From: "Wil O'Mullane" To: Tony Linde Cc: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 - function list Message-ID: <20031202113824.D31268@skysrv.pha.jhu.edu> References: <00a401c3b8ed$e378f1a0$0b01a8c0@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <00a401c3b8ed$e378f1a0$0b01a8c0@STAR.LE.AC.UK>; from ael@star.le.ac.uk on Tue, Dec 02, 2003 at 04:03:31PM -0000 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The SkyNode document suggest that a Functions port exists which allows the provider list available functions. As discussed at Strasbourg .. wil On Tue, Dec 02, 2003 at 04:03:31PM -0000, Tony Linden wrote: > I'd agree that we should settle on a standard list of functions and Clive's > suggestion of JDBC seems reasonable, supplemented perhaps by some core astro > ones as suggested in the VOQL documents. > > We should probably namespace the function list separate from the syntax of > the language so that they can change at different rates and be supported > differentially by query service implementations. > > We need some way of allowing a registered service to indicate that its Query > method (or 'port type' as I believe the WS people call it) supports: > VOQL v(2.00-2.37), > VOQLFunctions-Basic v1.2, > VOQLFunctions-Spatial v3.*, and > FredsSpecialSearchFunction v0.0.1. > > Easy eh? > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Clive Page > > Sent: 02 December 2003 10:14 > > To: voql@ivoa.net > > Subject: Re: Comments on ADQL v0.6 > > > > > > On Mon, 1 Dec 2003, John Good wrote: > > > > > I notice that the list of "math functions" matches PostgreSQL > > > but no other DBMS that I am aware of. For instance, > > > SQLServer, MySQL, and Informix use "log10" while Oracle > > > and PostgreSQL use "log". MySQL and PostgreSQL have > > > a "radians" function while the others don't. A different subset > > > supports "cot". It would probably be best to go with an > > > unambiguous, lowest-common-denominator approach since > > > not all systems support extension. > > > > This is something that I was also concerned about. The > > problem is that it is going to be quite hard to write > > astronomical code if the list of functions in ADQL is the > > rather short list supported by _every_ DBMS that astronomers > > currently use. It's worth pointint out that some sites are > > not even using a relational DBMS at all, as shown by the > > popularity of sites based on WCSTOOLS and one or two using > > the even more basic BROWSE. > > > > I had assumed that the ADQL document was based on the list of > > functions supported by JDBC, which in turn is said to be > > based on SQL92 Entry Level. The functions supported by JDBC > > 3.0 are listed at: http://java.sun.com/products/jdbc/driverdevs.html > > > > The JDBC list includes RADIANS and DEGREES (without which we > > are going to find life difficult) and both LOG and LOG10 but not COT. > > > > It is hard to find the SQL92 Standard on line (I think > > perhaps it's a document that you have to purchase as > > hard-copy), but a little googling found me x3h2-93-091.ps.Z > > from http://www.funet.fi/pub/standards/sql/ > > which looks like the genuine article. I've checked the index > > and skimmed through it all (a mere 1004 pages) but failed to > > find a list of functions supported, except the obvious ones > > like COUNT and MAX. So maybe the Standard is so inadequate > > it's no help at all. This is very peculiar. > > > > It seems to be well known in the trade that the US National > > Institute of Standards and Technology used to be heavily > > involved in the SQL Standards process, and used to report on > > conformance by the major players. But some years ago, > > presumably after pressure from the large vendors whose > > products showed a lack of standards conformance, they were > > directed by the US Government to withdraw from this area. As > > a result, practically no current DBMS, and certainly none of > > the popular ones, conforms fully to any official SQL > > Standard. The vendors, obviously, want to lock you in to > > their product. This is very unfortunate, and we have to put > > up with the consequences. > > > > > > My own view is that the appropriate course for the VO is to > > settle on a reasonably standard set of functions, and the > > list of JDBC seems a good choice. This means, of course, > > that those using a DBMS which lacks these functions will have > > either have to switch to a more astronomer-friendly DBMS > > (such as Postgres) or provide a user-defined function to fill > > the gap. In the case of the RADIANS function, at least, this > > isn't so difficult, as long as your DBMS supports > > user-defined functions at all. > > > > > > > The document would also be well served by a few > > well-crafted examples. > > > It is often much easier to see a problem in an example than > > in schema > > > definitions. > > > > Agreed. > > > > > > -- > > Clive Page > > Dept of Physics & Astronomy, > > University of Leicester, Tel +44 116 252 3551 > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > From owner-voql@eso.org Tue Dec 2 18:34:57 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 hB2HYBi9028407 for ; Tue, 2 Dec 2003 18:34:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2HYAvY028405 for voql-outgoing; Tue, 2 Dec 2003 18:34:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2HXBi9028046 for ; Tue, 2 Dec 2003 18:33:11 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2HXAd8017384 for ; Tue, 2 Dec 2003 18:33:10 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2HX8p12805 for ; Tue, 2 Dec 2003 09:33:08 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv3.ipac.caltech.edu [134.4.40.112]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2HX5U12790; Tue, 2 Dec 2003 09:33:05 -0800 (PST) Message-ID: <3FCCCCCA.6D659A02@ipac.caltech.edu> Date: Tue, 02 Dec 2003 09:32:58 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: Clive Page CC: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: It isn't realistic to expect anyone to switch DBMSs based on what VO would like (we've got almost a terabyte of relational data). It is also naive to base a VO standard on something which is not fully supported by any of the major DBMS vendors. All that will happen is that you will get a bunch of partially-compliant VO servers. We are using Informix and one of the reasons behind this choice was that we can extend the DBMS kernel to add all sorts of functionality. However, I would be surprised if other sites would be either able to do so or that their management would allow it. If the argument is that astronomical applications absolutely need some specific functions, I'm not sure I buy it and if I did I would maintain that things like coordinate, DDtoSEX and timescale transforms would actually be higher on the list than things like degrees to radians. - John From owner-voql@eso.org Tue Dec 2 19:10:09 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 hB2I9Ki9008768 for ; Tue, 2 Dec 2003 19:09:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2I9KW0008765 for voql-outgoing; Tue, 2 Dec 2003 19:09:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2I8ii9008655 for ; Tue, 2 Dec 2003 19:08:44 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2I8is3009033 for ; Tue, 2 Dec 2003 19:08:44 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1AREx1-0006G2-Np for voql@ivoa.net; Tue, 02 Dec 2003 18:08:43 +0000 Received: (qmail 7680 invoked from network); 2 Dec 2003 18:09:05 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 2 Dec 2003 18:09:05 -0000 Date: Tue, 2 Dec 2003 18:08:43 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 In-Reply-To: <3FCCCCCA.6D659A02@ipac.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Tue, 2 Dec 2003, John Good wrote: > It isn't realistic to expect anyone to switch DBMSs based on > what VO would like (we've got almost a terabyte of relational data). Not generally realistic, but there may be a few cases (naming no names) which are using antique database software and may be looking to migrate to something more modern... > It is also naive to base a VO standard on something which is not > fully supported by any of the major DBMS vendors. Actually the thing I said was not supported by any of the major DBMS vendors was _any_ Official SQL Standard. I think that's still true, but am willing to be corrected. So on that basis we are left with nothing. But there are JDBC drivers for almost all DBMS; whether they are all perfectly compliant with the JDBC Standard (written by Sun I think) is something I don't know. But in nearly all DBMS you can provide user-defined functions; maybe the JDBC layer does that to fill in any gaps? If not astronomers could write the necessary functions themselves. My investigations this afternoon in DBMS manuals covering: JDBC and the following DBMS: MySQL, Postgres, DB2, SQL Server, Oracle, and Sybase. Sorry I didn't think of Informix, but it's now owned by IBM so if it doesn't support the same functions as DB2, maybe it soon will (or it could be that IBM will cease to support it?). I don't have the time today to type in a nicely formatted table, but here below are the differences I discovered for the functions listed in the ADQL document. I think this is accurate and up-to-date, but may have missed something in quickly scanning the on-line manuals where I don't have printed copies. The entry "ok" means supported by all the above systems. ABS ok ACOS ok ASIN ok ATAN ok CEILING called CEIL by Postgres and Oracle, DB2 supports both names. COS ok COT missing from Oracle DEGREES missing from Oracle EXP ok FLOOR ok LN/LOG supported by Postgres, DB2, Oracle; called LOG/LOG10 by JDBC, MySQL, SQL Server, and Sybase. MOD missing from SQL Server, and Sybase PI missing from DB2, Oracle POWER called POW by Postgres; MySQL supports both names. RADIANS missing from Oracle SIN ok SQRT ok TAN ok There are 4 other math functions supported by JDBC which were not included in ADQL, which astronomers might need: ATAN2 called ATN2 by SQL Server and Sybase RAND called RANDOM by Postgres, missing from Oracle ROUND ok TRUNCATE called TRUNC by Postgres and Oracle, missing from SQL Server and Sybase. Maybe John Good could check his Informix manuals and update this pseudo-table. It may not leave us with all that many "standard" functions. There are, of course, a lot of other functions supported by JDBC which astronomers might want to use, especially for string handling and for date/time manipulation. But given the problems found with simple math functions, maybe we ought not to venture in such wild and uncharted territory without a guide. What's in ADQL seems sensible to me, except perhaps for the LOG/LN LOG/LOG10 problem. This is rather pernicious, since LOG to some SQL processors means log to base 10 and to others means log to base e. I'd like to suggest that we change ADQL to use LOG and LOG10, to conform to JDBC. If we make no change, none of the DBMS listed above conforms to the ADQL spec; if we change this than MySQL is the only one conforming. Actually, that's rather remarkable, given that MySQL is often criticised for its lack of standards-conformance. I'm grateful to Tony for reminding us that the ADQL spec also includes a facility for cone-search (via the REGION keyword). I don't want to stir up any more hornets nests, but I'd have thought that a simple numerical function might be easier to use, i.e. instead of REGION('CIRCLE J2000 19.5, -36.7 0.02') we had something like CIRCLE('J2000', 19.5, -36.7, 0.02) but I guess the former gives more flexibility for using non-circular regions. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Tue Dec 2 19:26:04 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 hB2Hbti9029642 for ; Tue, 2 Dec 2003 18:37:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2HbsTh029635 for voql-outgoing; Tue, 2 Dec 2003 18:37:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2Haii9029260; Tue, 2 Dec 2003 18:36:44 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2Hagd8017523; Tue, 2 Dec 2003 18:36:43 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2Hafp13299; Tue, 2 Dec 2003 09:36:41 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv3.ipac.caltech.edu [134.4.40.112]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2HadU13291; Tue, 2 Dec 2003 09:36:39 -0800 (PST) Message-ID: <3FCCCDA0.1681C9F6@ipac.caltech.edu> Date: Tue, 02 Dec 2003 09:36:32 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: Andreas Wicenec CC: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 References: <200312021200.22436.awicenec@eso.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Two comments on this comment: 1) As was pointed out before, not everyone is using a COTS DBMS. 2) I think it would be a mistake to *expect* anyone to extend their DBMS. - John Andreas Wicenec wrote: > Dear all, > > just a little comment on this: > > At least all the major DBMS support now user defined functions (UDFs) mostly > written in Java, i.e. you can in fact define your own function and use it > afterwards in normal SQL statements. Like this you are not that dependent on > the provided functions anymore... From owner-voql@eso.org Tue Dec 2 19:37:09 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 hB2IaOi9015286 for ; Tue, 2 Dec 2003 19:36:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2IaOep015285 for voql-outgoing; Tue, 2 Dec 2003 19:36:24 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2IZoi9015158 for ; Tue, 2 Dec 2003 19:35:50 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2IZmd8019179 for ; Tue, 2 Dec 2003 19:35:49 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2IZkp22895 for ; Tue, 2 Dec 2003 10:35:47 -0800 (PST) Received: from ipac.caltech.edu (oasis.ipacds.ipac.caltech.edu [134.4.70.173]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB2IZkU22889 for ; Tue, 2 Dec 2003 10:35:46 -0800 (PST) Message-ID: <3FCCDB82.F18EEC83@ipac.caltech.edu> Date: Tue, 02 Dec 2003 10:35:46 -0800 From: John Good Organization: IPAC / Caltech X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: More comments on ADQL v0.6 References: <3FCCCCCA.6D659A02@ipac.caltech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On more thorough reading of the ADQL document, there is one more issue that strikes me as a source of potential problems. Specifically, the ability to do joins. I suspect that not all database software used in astronomy can support a query like SELECT a.f1, b.f2, c.f3 FROM tbl1 a, tbl2 b, tbl3 c WHERE a.x = b.y AND a.w = c.z; but more to the point I am certain that many institutions will not allow it. All of this is simple enough with small tables but when you have giga-row databases, you have to be very careful, especially when doing three-way joins which may want to create "temporary" tables that are larger than the free space you have or take hours to days even to create. As I say, not a technical problem but certainly one that will give many managers pause. There should probably be a well-defined subset of VOQL functionality which allows for basic subsetting of a single table and allows data providers to register to do that alone. - John From owner-voql@eso.org Tue Dec 2 19:42:45 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 hB2Ifxi9016999 for ; Tue, 2 Dec 2003 19:41:59 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2IfwF3016996 for voql-outgoing; Tue, 2 Dec 2003 19:41:58 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2IfKi9016813 for ; Tue, 2 Dec 2003 19:41:21 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2IfKd8019338 for ; Tue, 2 Dec 2003 19:41:20 +0100 (CET) Received: from dial.pipex.com (81-86-232-154.dsl.pipex.com [81.86.232.154]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 399D01C00647; Tue, 2 Dec 2003 18:41:19 +0000 (GMT) Message-ID: <3FCCDCCC.3040505@dial.pipex.com> Date: Tue, 02 Dec 2003 18:41:16 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Good Cc: Andreas Wicenec , voql@ivoa.net Subject: Re: Comments on ADQL v0.6 References: <200312021200.22436.awicenec@eso.org> <3FCCCDA0.1681C9F6@ipac.caltech.edu> In-Reply-To: <3FCCCDA0.1681C9F6@ipac.caltech.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: John Good wrote: > Two comments on this comment: > > 1) As was pointed out before, not everyone is using a COTS DBMS. Yes - and indeed data might not be in a DBMS at all. > > 2) I think it would be a mistake to *expect* anyone to extend their DBMS. However... If we (IVOA implementers, eg AstroGrid) can provide 'toolkits' that include these functions, then we can look at expanding the range of functions available for the 'advanced' servers. If 'most modern' DBMSs provide truly Java-based UDF, this might be a way of doing so with little cost to the data owners. Not sure how we differentiate at the moment between 'simple' servers and 'advanced' ones, but I think the SkyNode folks were looking at this? > > - John > > > Andreas Wicenec wrote: > > >>Dear all, >> >>just a little comment on this: >> >>At least all the major DBMS support now user defined functions (UDFs) mostly >>written in Java, i.e. you can in fact define your own function and use it >>afterwards in normal SQL statements. Like this you are not that dependent on >>the provided functions anymore... > > -- Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Tue Dec 2 20:09:32 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 hB2J8ni9023478 for ; Tue, 2 Dec 2003 20:08:49 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2J8n1Z023477 for voql-outgoing; Tue, 2 Dec 2003 20:08:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2J8Ei9023315 for ; Tue, 2 Dec 2003 20:08:14 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2J8Ds3010768 for ; Tue, 2 Dec 2003 20:08:14 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hB2J8BN04436; Tue, 2 Dec 2003 14:08:11 -0500 Date: Tue, 2 Dec 2003 14:08:11 -0500 From: "Wil O'Mullane" To: John Good Cc: voql@ivoa.net Subject: Re: More comments on ADQL v0.6 Message-ID: <20031202140811.A3160@skysrv.pha.jhu.edu> References: <3FCCCCCA.6D659A02@ipac.caltech.edu> <3FCCDB82.F18EEC83@ipac.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FCCDB82.F18EEC83@ipac.caltech.edu>; from jcg@ipac.caltech.edu on Tue, Dec 02, 2003 at 10:35:46AM -0800 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Again I point to SkyNode0.6 ADQL is a syntax only. We need other ways that Nodes show what level of support they provide. This is the SkyNode document. It says how to accept a query and what to return. It outlines basic and full SkyNode we had some more refinements but people were finding it too complex. This is the place for defining the types of joins allowed etc - not in the syntax of the language. The main question is what is the minimum to be supported your answer would seem to be : very few functions and no joins Others think minimum should include joins and all facets of STC i.e. complex shapes and areas. The attempt in sky node was to have a middle ground which most people felt comfortable with. Even if for some that may have meant buying a DBMS license. Or that was the feeling I got in Strasbourg. Of course, as you point out, when people go to do this they may have many other issues... And then there will be many execution issues to deal with also. The attempt in ADQL was to have a good set of Functions which were generally available. The assumption is indeed that people use a Database. IF your assumption is that people do not use a database then I feel we must still insist on the common set of basic functions. wil On Tue, Dec 02, 2003 at 10:35:46AM -0800, John Good wrote: > > > On more thorough reading of the ADQL document, there is one more > issue that strikes me as a source of potential problems. Specifically, > the > ability to do joins. I suspect that not all database software used in > astronomy can support a query like > > SELECT a.f1, b.f2, c.f3 > FROM tbl1 a, tbl2 b, tbl3 c > WHERE a.x = b.y > AND a.w = c.z; > > but more to the point I am certain that many institutions will not allow > > it. All of this is simple enough with small tables but when you have > giga-row databases, you have to be very careful, especially when doing > three-way joins which may want to create "temporary" tables that are > larger than the free space you have or take hours to days even to > create. > > As I say, not a technical problem but certainly one that will give many > managers pause. > > There should probably be a well-defined subset of VOQL functionality > which allows for basic subsetting of a single table and allows data > providers to register to do that alone. > > - John From owner-voql@eso.org Tue Dec 2 20:14:09 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 hB2JDKi9024550 for ; Tue, 2 Dec 2003 20:13:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2JDKJw024549 for voql-outgoing; Tue, 2 Dec 2003 20:13:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2JCki9024453 for ; Tue, 2 Dec 2003 20:12:46 +0100 (MET) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2JCid8020269 for ; Tue, 2 Dec 2003 20:12:45 +0100 (CET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 11:12:44 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Dec 2003 11:12:42 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 11:12:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Load Governors for SkyNodes Date: Tue, 2 Dec 2003 11:12:28 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD44901895C2A@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Load Governors for SkyNodes Thread-Index: AcO5BaD/lk6NXBlWR/Ka7+YoGbfPmgAAHRvQ From: "Jim Gray" To: "John Good" , X-OriginalArrivalTime: 02 Dec 2003 19:12:47.0222 (UTC) FILETIME=[456E0160:01C3B908] X-Scanned-By: MIMEDefang 2.35 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 hB2JDJi9024544 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: John Good worries about queries like Select * from Objects Which will return billions of records and swamp a SkyNode. We worried a LOT about this in the SkyServer. But, in the end we decided to just accept ANY query you gave us. There was just one restriction: The query has to generate less than 1,000 rows and run in less than 90 seconds. For the collaboration there is a separate server with the limits The query has to generate less than 500,000 rows and run in less than 90 minutes. Both database servers are lightly loaded most of the time (30 M web hits and 0.8 M sql queries) This sounds crazy, but so far no one has complained and the system has worked fine. You can look at the sql Query logs at http://skyserver.sdss.org/dr1/en/tools/search/sql.asp Select * from sdssad2.weblog.dbo.sqllog order by yy desc And the weblogs are Select * from sdssad2.weblog.dbo.weblog order by yy desc (we add the top 1000 to your query if you do not specify a count). The folks at JHU have set up a "batch system" that allows big jobs to run through a query system and to deposit their answer in a local database. You can experiment with that at: http://skyservice.pha.jhu.edu/devel/casjobs/ Overall we have found that people do not abuse these systems. Amazing but true. We have served 818,669 SQL queries and 553,805,369 rows over the last year. (in addition to the SkyServer database traffic). You can get the counts by doing: select count(*), sum(rows) from sdssad2.weblog.dbo.sqllog where rows < 500001 -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of John Good Sent: Tuesday, December 02, 2003 10:36 AM To: voql@ivoa.net Subject: Re: More comments on ADQL v0.6 On more thorough reading of the ADQL document, there is one more issue that strikes me as a source of potential problems. Specifically, the ability to do joins. I suspect that not all database software used in astronomy can support a query like SELECT a.f1, b.f2, c.f3 FROM tbl1 a, tbl2 b, tbl3 c WHERE a.x = b.y AND a.w = c.z; but more to the point I am certain that many institutions will not allow it. All of this is simple enough with small tables but when you have giga-row databases, you have to be very careful, especially when doing three-way joins which may want to create "temporary" tables that are larger than the free space you have or take hours to days even to create. As I say, not a technical problem but certainly one that will give many managers pause. There should probably be a well-defined subset of VOQL functionality which allows for basic subsetting of a single table and allows data providers to register to do that alone. - John From owner-voql@eso.org Tue Dec 2 22:04:59 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 hB2L4Fi9022377 for ; Tue, 2 Dec 2003 22:04:15 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2L4FLR022376 for voql-outgoing; Tue, 2 Dec 2003 22:04:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2L3fi9022252 for ; Tue, 2 Dec 2003 22:03:41 +0100 (MET) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2L3ed8023143 for ; Tue, 2 Dec 2003 22:03:40 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20031202210338.OAXH10749.mta01-svc.ntlworld.com@gnowee> for ; Tue, 2 Dec 2003 21:03:38 +0000 From: "Tony Linde" To: Subject: RE: Comments on ADQL v0.6 - function list Date: Tue, 2 Dec 2003 21:03:30 -0000 Organization: University of Leicester Message-ID: <00b501c3b917$d84717b0$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 Importance: Normal In-Reply-To: <20031202113824.D31268@skysrv.pha.jhu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 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 hB2L4Fi9022373 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > The SkyNode document > suggest that a Functions port exists which allows > the provider list available functions. > As discussed at Strasbourg .. I know, Wil. Just making the point again as the questions about it have come around again. Plus ca change, plus c-est la meme chose. :) T. > -----Original Message----- > From: Wil O'Mullane [mailto:womullan@skysrv.pha.jhu.edu] > Sent: 02 December 2003 16:38 > To: Tony Linde > Cc: voql@ivoa.net > Subject: Re: Comments on ADQL v0.6 - function list > > > The SkyNode document > suggest that a Functions port exists which allows > the provider list available functions. > As discussed at Strasbourg .. > wil > On Tue, Dec 02, 2003 at 04:03:31PM -0000, Tony Linden wrote: > > I'd agree that we should settle on a standard list of functions and > > Clive's suggestion of JDBC seems reasonable, supplemented > perhaps by > > some core astro ones as suggested in the VOQL documents. > > > > We should probably namespace the function list separate from the > > syntax of the language so that they can change at different > rates and > > be supported differentially by query service implementations. > > > > We need some way of allowing a registered service to > indicate that its > > Query method (or 'port type' as I believe the WS people call it) > > supports: VOQL v(2.00-2.37), VOQLFunctions-Basic v1.2, > > VOQLFunctions-Spatial v3.*, and > > FredsSpecialSearchFunction v0.0.1. > > > > Easy eh? > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > > Behalf Of Clive Page > > > Sent: 02 December 2003 10:14 > > > To: voql@ivoa.net > > > Subject: Re: Comments on ADQL v0.6 > > > > > > > > > On Mon, 1 Dec 2003, John Good wrote: > > > > > > > I notice that the list of "math functions" matches PostgreSQL > > > > but no other DBMS that I am aware of. For instance, > > > > SQLServer, MySQL, and Informix use "log10" while Oracle > > > > and PostgreSQL use "log". MySQL and PostgreSQL have > > > > a "radians" function while the others don't. A > different subset > > > > supports "cot". It would probably be best to go with an > > > > unambiguous, lowest-common-denominator approach since > > > > not all systems support extension. > > > > > > This is something that I was also concerned about. The > > > problem is that it is going to be quite hard to write > > > astronomical code if the list of functions in ADQL is the > > > rather short list supported by _every_ DBMS that astronomers > > > currently use. It's worth pointint out that some sites are > > > not even using a relational DBMS at all, as shown by the > > > popularity of sites based on WCSTOOLS and one or two using > > > the even more basic BROWSE. > > > > > > I had assumed that the ADQL document was based on the list of > > > functions supported by JDBC, which in turn is said to be > > > based on SQL92 Entry Level. The functions supported by JDBC > > > 3.0 are listed at: > http://java.sun.com/products/jdbc/driverdevs.html > > > > > > The JDBC list includes RADIANS and DEGREES (without which we > > > are going to find life difficult) and both LOG and LOG10 > but not COT. > > > > > > It is hard to find the SQL92 Standard on line (I think > > > perhaps it's a document that you have to purchase as > > > hard-copy), but a little googling found me x3h2-93-091.ps.Z > > > from http://www.funet.fi/pub/standards/sql/ > > > which looks like the genuine article. I've checked the index > > > and skimmed through it all (a mere 1004 pages) but failed to > > > find a list of functions supported, except the obvious ones > > > like COUNT and MAX. So maybe the Standard is so inadequate > > > it's no help at all. This is very peculiar. > > > > > > It seems to be well known in the trade that the US National > > > Institute of Standards and Technology used to be heavily > > > involved in the SQL Standards process, and used to report on > > > conformance by the major players. But some years ago, > > > presumably after pressure from the large vendors whose > > > products showed a lack of standards conformance, they were > > > directed by the US Government to withdraw from this area. As > > > a result, practically no current DBMS, and certainly none of > > > the popular ones, conforms fully to any official SQL > > > Standard. The vendors, obviously, want to lock you in to > > > their product. This is very unfortunate, and we have to put > > > up with the consequences. > > > > > > > > > My own view is that the appropriate course for the VO is to > > > settle on a reasonably standard set of functions, and the > > > list of JDBC seems a good choice. This means, of course, > > > that those using a DBMS which lacks these functions will have > > > either have to switch to a more astronomer-friendly DBMS > > > (such as Postgres) or provide a user-defined function to fill > > > the gap. In the case of the RADIANS function, at least, this > > > isn't so difficult, as long as your DBMS supports > > > user-defined functions at all. > > > > > > > > > > The document would also be well served by a few > > > well-crafted examples. > > > > It is often much easier to see a problem in an example than > > > in schema > > > > definitions. > > > > > > Agreed. > > > > > > > > > -- > > > Clive Page > > > Dept of Physics & Astronomy, > > > University of Leicester, Tel +44 116 252 3551 > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > > > > > From owner-voql@eso.org Tue Dec 2 22:10:19 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 hB2L9ci9023358 for ; Tue, 2 Dec 2003 22:09:38 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2L9cnu023357 for voql-outgoing; Tue, 2 Dec 2003 22:09:38 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2L94i9023290 for ; Tue, 2 Dec 2003 22:09:04 +0100 (MET) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2L93d8023269 for ; Tue, 2 Dec 2003 22:09:04 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20031202210858.OMZQ10749.mta01-svc.ntlworld.com@gnowee>; Tue, 2 Dec 2003 21:08:58 +0000 From: "Tony Linde" To: "'Wil O'Mullane'" , "'John Good'" Cc: Subject: RE: More comments on ADQL v0.6 Date: Tue, 2 Dec 2003 21:08:47 -0000 Organization: University of Leicester Message-ID: <00b601c3b918$96e639d0$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 Importance: Normal In-Reply-To: <20031202140811.A3160@skysrv.pha.jhu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Scanned-By: MIMEDefang 2.35 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 hB2L9ci9023353 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'd support Wil here. The comments here imply that ADQL will be used to access a database; it won't. ADQL is the (proposed & generally accepted) language for querying a data *service* which is registered as such on the VO. The service will likely by a web service or may be a cgi program. It is those services which will query the databases. A data service has to take in VOQL and then translate that into a query that the database (if there is one) will understand. So functions which are in the base VOQL function list will need to be translated to their equivalent in the dbms SQL. Where there is no equivalent (either of functions or syntax - eg joins) then either the service fills the gap by using some specially written application or it signifies in its registry entry that it cannot support that feature. This is the approach we've taken in AstroGrid where plugins to our data service provide the specific adql/database translation. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 02 December 2003 19:08 > To: John Good > Cc: voql@ivoa.net > Subject: Re: More comments on ADQL v0.6 > > > Again I point to SkyNode0.6 > ADQL is a syntax only. > We need other ways that Nodes show what level of support they > provide. This is the SkyNode document. It says how to accept > a query and what to return. It outlines basic and full > SkyNode we had some more refinements but people were finding > it too complex. This is the place for defining the types of joins > allowed etc - not in the syntax of the language. > > The main question is what is the minimum to be supported > your answer would seem to be : very few functions and no > joins Others think minimum should include joins and all > facets of STC i.e. complex shapes and areas. > > The attempt in sky node was to have a middle ground which > most people felt comfortable with. Even if for some that may > have meant buying a DBMS license. Or that was the feeling I got > in Strasbourg. Of course, as you point out, when people go to > do this they may have many other issues... And then there > will be many execution issues to deal with also. > > The attempt in ADQL was to have a good set of Functions which > were generally available. The assumption is indeed that > people use a Database. IF your assumption is that people do > not use a database then I feel we must still insist on the > common set of basic functions. > > wil > On Tue, Dec 02, 2003 at 10:35:46AM -0800, John Good wrote: > > > > > > On more thorough reading of the ADQL document, there is one > more issue > > that strikes me as a source of potential problems. > Specifically, the > > ability to do joins. I suspect that not all database > software used in > > astronomy can support a query like > > > > SELECT a.f1, b.f2, c.f3 > > FROM tbl1 a, tbl2 b, tbl3 c > > WHERE a.x = b.y > > AND a.w = c.z; > > > > but more to the point I am certain that many institutions will not > > allow > > > > it. All of this is simple enough with small tables but > when you have > > giga-row databases, you have to be very careful, especially > when doing > > three-way joins which may want to create "temporary" tables > that are > > larger than the free space you have or take hours to days even to > > create. > > > > As I say, not a technical problem but certainly one that will give > > many managers pause. > > > > There should probably be a well-defined subset of VOQL > functionality > > which allows for basic subsetting of a single table and allows data > > providers to register to do that alone. > > > > - John > From owner-voql@eso.org Tue Dec 2 22:34:49 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 hB2LY6i9028805 for ; Tue, 2 Dec 2003 22:34:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB2LY65w028804 for voql-outgoing; Tue, 2 Dec 2003 22:34:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB2LXUi9028692 for ; Tue, 2 Dec 2003 22:33:30 +0100 (MET) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB2LXTs3015565 for ; Tue, 2 Dec 2003 22:33:30 +0100 (CET) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id hB2LXOp12961; Tue, 2 Dec 2003 14:33:25 -0700 Received: from oak (oak [146.88.1.137]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id hB2LXJ72008627; Tue, 2 Dec 2003 14:33:19 -0700 (MST) Date: Tue, 2 Dec 2003 14:33:19 -0700 (MST) From: Doug Tody X-X-Sender: dtody@oak To: Tony Linde cc: "'Wil O'Mullane'" , "'John Good'" , Subject: RE: More comments on ADQL v0.6 In-Reply-To: <00b601c3b918$96e639d0$0b01a8c0@STAR.LE.AC.UK> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'll add my support to this view as well. An ADQL is a document which is passed to a service; the service executes the query and may or may not query a DBMS. If a DBMS is queried there will often be some level of translation involved. In particular we will ultimately need functions which extend the classical DBMS query language, e.g, for spatial queries. It should be possible to use any reasonable DBMS on the back-end. Simple services may not support ADQL at all. The service profile in the registry will indicate the level of capability of the service. Of course, it would be useful for the basic functions provided to be similar to those provided by most DBMS. But it is clear that some level of translation and extension will be required. - Doug On Tue, 2 Dec 2003, Tony Linde wrote: > I'd support Wil here. The comments here imply that ADQL will be used to > access a database; it won't. > > ADQL is the (proposed & generally accepted) language for querying a data > *service* which is registered as such on the VO. The service will likely by > a web service or may be a cgi program. It is those services which will query > the databases. > > A data service has to take in VOQL and then translate that into a query that > the database (if there is one) will understand. So functions which are in > the base VOQL function list will need to be translated to their equivalent > in the dbms SQL. > > Where there is no equivalent (either of functions or syntax - eg joins) then > either the service fills the gap by using some specially written application > or it signifies in its registry entry that it cannot support that feature. > > This is the approach we've taken in AstroGrid where plugins to our data > service provide the specific adql/database translation. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Wil O'Mullane > > Sent: 02 December 2003 19:08 > > To: John Good > > Cc: voql@ivoa.net > > Subject: Re: More comments on ADQL v0.6 > > > > > > Again I point to SkyNode0.6 > > ADQL is a syntax only. > > We need other ways that Nodes show what level of support they > > provide. This is the SkyNode document. It says how to accept > > a query and what to return. It outlines basic and full > > SkyNode we had some more refinements but people were finding > > it too complex. This is the place for defining the types of joins > > allowed etc - not in the syntax of the language. > > > > The main question is what is the minimum to be supported > > your answer would seem to be : very few functions and no > > joins Others think minimum should include joins and all > > facets of STC i.e. complex shapes and areas. > > > > The attempt in sky node was to have a middle ground which > > most people felt comfortable with. Even if for some that may > > have meant buying a DBMS license. Or that was the feeling I got > > in Strasbourg. Of course, as you point out, when people go to > > do this they may have many other issues... And then there > > will be many execution issues to deal with also. > > > > The attempt in ADQL was to have a good set of Functions which > > were generally available. The assumption is indeed that > > people use a Database. IF your assumption is that people do > > not use a database then I feel we must still insist on the > > common set of basic functions. > > > > wil > > On Tue, Dec 02, 2003 at 10:35:46AM -0800, John Good wrote: > > > > > > > > > On more thorough reading of the ADQL document, there is one > > more issue > > > that strikes me as a source of potential problems. > > Specifically, the > > > ability to do joins. I suspect that not all database > > software used in > > > astronomy can support a query like > > > > > > SELECT a.f1, b.f2, c.f3 > > > FROM tbl1 a, tbl2 b, tbl3 c > > > WHERE a.x = b.y > > > AND a.w = c.z; > > > > > > but more to the point I am certain that many institutions will not > > > allow > > > > > > it. All of this is simple enough with small tables but > > when you have > > > giga-row databases, you have to be very careful, especially > > when doing > > > three-way joins which may want to create "temporary" tables > > that are > > > larger than the free space you have or take hours to days even to > > > create. > > > > > > As I say, not a technical problem but certainly one that will give > > > many managers pause. > > > > > > There should probably be a well-defined subset of VOQL > > functionality > > > which allows for basic subsetting of a single table and allows data > > > providers to register to do that alone. > > > > > > - John > > > > > From owner-voql@eso.org Wed Dec 3 11:27: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 hB3AQawe016171 for ; Wed, 3 Dec 2003 11:26:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB3AQZnJ016170 for voql-outgoing; Wed, 3 Dec 2003 11:26:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB3AQXrU016161 for ; Wed, 3 Dec 2003 11:26:33 +0100 (MET) Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55]) by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hB3AQWt27588 for ; Wed, 3 Dec 2003 11:26:32 +0100 (MET) From: Andreas Wicenec Organization: European Southern Observatory To: voql@ivoa.net Subject: Re: Comments on ADQL v0.6 Date: Wed, 3 Dec 2003 11:26:32 +0100 User-Agent: KMail/1.5.1 References: <200312021200.22436.awicenec@eso.org> <3FCCCDA0.1681C9F6@ipac.caltech.edu> In-Reply-To: <3FCCCDA0.1681C9F6@ipac.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312031126.32547.awicenec@eso.org> Sender: owner-voql@eso.org Precedence: bulk Reply-To: Andreas Wicenec X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Dear all, I agree with everything said above, the point I wanted to make is just that we should probably not look to closely to what is provided by a DBMS or anything else but more to what we *really* need to satisfy our requirements. If soemthing is missing in one or more of the underlying systems we have to find a workaround. Please note that I highlighted the word *really*! Andreas On Tuesday 02 December 2003 18:36, John Good wrote: > Two comments on this comment: > > 1) As was pointed out before, not everyone is using a COTS DBMS. > > 2) I think it would be a mistake to *expect* anyone to extend their > DBMS. > > - John > > Andreas Wicenec wrote: > > Dear all, > > > > just a little comment on this: > > > > At least all the major DBMS support now user defined functions (UDFs) > > mostly written in Java, i.e. you can in fact define your own function and > > use it afterwards in normal SQL statements. Like this you are not that > > dependent on the provided functions anymore... From owner-voql@eso.org Wed Dec 3 12:52:46 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 hB3Bplof009148 for ; Wed, 3 Dec 2003 12:51:47 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB3Bpl9b009147 for voql-outgoing; Wed, 3 Dec 2003 12:51:47 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB3BpDof009039 for ; Wed, 3 Dec 2003 12:51:13 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB3BpDd8012254 for ; Wed, 3 Dec 2003 12:51:13 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1ARVXE-00010j-J9 for voql@ivoa.net; Wed, 03 Dec 2003 11:51:12 +0000 Received: (qmail 26638 invoked from network); 3 Dec 2003 11:51:34 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 3 Dec 2003 11:51:34 -0000 Date: Wed, 3 Dec 2003 11:51:12 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: More comments on ADQL v0.6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: If anyone thinks my comments on the lack of standard-conformance among vendors of popular DBMS were a bit harsh, then I recommend the website of Troels Arvin of Copenhagen who provides a wealth of supporting detail. He also covers date/time and string functionality which I did not cover at all, but which may be important to astronomers: http://troels.arvin.dk/db/rdbms/ I continue to be amazed by all this: every vendor of a compiler for say C or Fortran feels obliged to implement every last detail of the relevant ANSI or ISO Standard, or else their product gets drummed out of town. But the DBMS vendors hardly even pay lip service to the SQL Standard, despite which users seem happy to give them huge sums of money and their reward is get locked into one product indefinitely. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Wed Dec 3 18:00:03 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 hB3Gwiof029775 for ; Wed, 3 Dec 2003 17:58:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB3GwiHn029770 for voql-outgoing; Wed, 3 Dec 2003 17:58:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB3GwAof029671 for ; Wed, 3 Dec 2003 17:58:11 +0100 (MET) 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 SMTP id hB3Gw9s3010393 for ; Wed, 3 Dec 2003 17:58:10 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id hB3Gw7c01601 for ; Wed, 3 Dec 2003 10:58:07 -0600 Date: Wed, 3 Dec 2003 10:58:07 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: RE: More comments on ADQL v0.6 In-Reply-To: <00b601c3b918$96e639d0$0b01a8c0@STAR.LE.AC.UK> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'm going to jump in to endorse the concept that ADQL/SkyNode is an interface and not an implementation (and applaud Wil's efforts to address the broad range of needs). I'll throw in two short points: * The slight variation in function names among DBMS underlines the importance of having an easy-to-parse version of ADQL (i.e. XML). It becomes trivial to swap in the local name for the standard name. * Wil mentioned the tension between setting the entry level bar low to allow maximum participation and setting it higher to ensure a useful level of functionality. ConeSearch has demonstrated to be both useful and easy to implement. If we see ADQL/SkyNode as a replacement for ConeSearch (as I do), then the entry level should be the same. That means no should have to upgrade their "DB" (note quotes) to practically participate at the lowest level. cheers, Ray From owner-voql@eso.org Wed Dec 3 19:11:48 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 hB3IB0KM017324 for ; Wed, 3 Dec 2003 19:11:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB3IB0mu017323 for voql-outgoing; Wed, 3 Dec 2003 19:11:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB3IASKM017182 for ; Wed, 3 Dec 2003 19:10:28 +0100 (MET) Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB3IAQd8022727 for ; Wed, 3 Dec 2003 19:10:27 +0100 (CET) Received: from zia.aoc.nrao.edu (zia [146.88.1.4]) by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id hB3IAMp07816; Wed, 3 Dec 2003 11:10:22 -0700 Received: from oak (oak [146.88.1.137]) by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id hB3IAI72018660; Wed, 3 Dec 2003 11:10:18 -0700 (MST) Date: Wed, 3 Dec 2003 11:10:18 -0700 (MST) From: Doug Tody X-X-Sender: dtody@oak To: Ray Plante cc: voql@ivoa.net Subject: RE: More comments on ADQL v0.6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7, BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00, USER_AGENT_PINE 0.00) X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Wed, 3 Dec 2003, Ray Plante wrote: > I'm going to jump in to endorse the concept that ADQL/SkyNode is an > interface and not an implementation (and applaud Wil's efforts to address > the broad range of needs). I'll throw in two short points: > > * The slight variation in function names among DBMS underlines the > importance of having an easy-to-parse version of ADQL (i.e. XML). It > becomes trivial to swap in the local name for the standard name. > > * Wil mentioned the tension between setting the entry level bar low to > allow maximum participation and setting it higher to ensure a useful > level of functionality. ConeSearch has demonstrated to be both useful > and easy to implement. If we see ADQL/SkyNode as a replacement for > ConeSearch (as I do), then the entry level should be the same. That > means no should have to upgrade their "DB" (note quotes) to > practically participate at the lowest level. I agree, and this is consistent with my comment earlier about individual service implementations having a range of capability levels. For most DAL services we want to keep a simple keyword-based query interface (as at present with the addition of a WS version), and add a new, more capable, ADQL-based query method. Probably all sucy query methods would return the same document-based results, only the method used to invoke the query would differ. If we apply this logic to cone search, then a future ADQL-based version should provide both a simple keyword-based interface, as with the current cone search, as well as the more capable ADQL interface. Not only does this lower the bar for service implementers, it retains a simple interface for simple queries. The most common queries are likely to be the simple ones. From owner-voql@eso.org Wed Dec 3 21:33:42 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 hB3KWqKM019132 for ; Wed, 3 Dec 2003 21:32:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB3KWqbI019131 for voql-outgoing; Wed, 3 Dec 2003 21:32:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB3KWHKM018938 for ; Wed, 3 Dec 2003 21:32:17 +0100 (MET) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB3KWHs3015712 for ; Wed, 3 Dec 2003 21:32:17 +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 <20031203203216.ZNHU19387.mta05-svc.ntlworld.com@gnowee> for ; Wed, 3 Dec 2003 20:32:16 +0000 From: "Tony Linde" To: Subject: RE: More comments on ADQL v0.6 Date: Wed, 3 Dec 2003 20:32:39 -0000 Organization: University of Leicester Message-ID: <000a01c3b9dc$a0d45700$0c01a8c0@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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scanned-By: MIMEDefang 2.35 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 hB3KWqKM019128 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > individual service implementations having a range of > capability levels. For most DAL services we want to keep a > simple keyword-based query interface (as at present with the > addition of a WS version), and add a new, more capable, > ADQL-based query method. Probably all sucy query methods ... > Not only does this lower the bar for service implementers, it > retains a simple interface for simple queries. The most Problem is that no-one can use these simple interfaces *from the VO*. Unless these are defined as a standard that VO portals/tools/whatever can understand, it'll be a matter of a user looking up the entry in a registry then trying from the metadata to figure out the particular keywords of that particular service. Or they can only be invoked from a portal which happens to have been coded to understand one particular service interface. That's fine if these simple services are not meant to be part of the VO, but if they are then we need some standard way of describing them and invoking them. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Doug Tody > Sent: 03 December 2003 18:10 > To: Ray Plante > Cc: voql@ivoa.net > Subject: RE: More comments on ADQL v0.6 > > > On Wed, 3 Dec 2003, Ray Plante wrote: > > > I'm going to jump in to endorse the concept that ADQL/SkyNode is an > > interface and not an implementation (and applaud Wil's > efforts to address > > the broad range of needs). I'll throw in two short points: > > > > * The slight variation in function names among DBMS > underlines the > > importance of having an easy-to-parse version of ADQL > (i.e. XML). It > > becomes trivial to swap in the local name for the standard name. > > > > * Wil mentioned the tension between setting the entry > level bar low to > > allow maximum participation and setting it higher to > ensure a useful > > level of functionality. ConeSearch has demonstrated to > be both useful > > and easy to implement. If we see ADQL/SkyNode as a > replacement for > > ConeSearch (as I do), then the entry level should be > the same. That > > means no should have to upgrade their "DB" (note quotes) to > > practically participate at the lowest level. > > I agree, and this is consistent with my comment earlier about > individual service implementations having a range of > capability levels. For most DAL services we want to keep a > simple keyword-based query interface (as at present with the > addition of a WS version), and add a new, more capable, > ADQL-based query method. Probably all sucy query methods > would return the same document-based results, only the method > used to invoke the query would differ. > > If we apply this logic to cone search, then a future > ADQL-based version should provide both a simple keyword-based > interface, as with the current cone search, as well as the > more capable ADQL interface. > > Not only does this lower the bar for service implementers, it > retains a simple interface for simple queries. The most > common queries are likely to be the simple ones. > From owner-voql@eso.org Thu Dec 4 12:56:23 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 hB4BtLlK029850 for ; Thu, 4 Dec 2003 12:55:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4BtLej029847 for voql-outgoing; Thu, 4 Dec 2003 12:55:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB4BsklK029685 for ; Thu, 4 Dec 2003 12:54:46 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB4Bsgd8016551 for ; Thu, 4 Dec 2003 12:54:45 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id UAA03154; Thu, 4 Dec 2003 20:54:37 +0900 (JST) Message-Id: <6.0.0.20.2.20031204205406.02e795d0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 04 Dec 2003 20:54:36 +0900 To: Ray Plante , voql@ivoa.net From: Masatoshi OHISHI Subject: RE: More comments on ADQL v0.6 In-Reply-To: References: <00b601c3b918$96e639d0$0b01a8c0@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Ray, At 10:58 03/12/03 -0600, Ray Plante wrote: > >I'm going to jump in to endorse the concept that ADQL/SkyNode is an >interface and not an implementation (and applaud Wil's efforts to address >the broad range of needs). You are right. -- Masatoshi From owner-voql@eso.org Thu Dec 4 14:27:17 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 hB4DQIlK024126 for ; Thu, 4 Dec 2003 14:26:18 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4DQIGO024125 for voql-outgoing; Thu, 4 Dec 2003 14:26:18 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB4DPdlK023950 for ; Thu, 4 Dec 2003 14:25:39 +0100 (MET) Received: from artemis.le.ac.uk (ntp2c.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB4DPdd8019101 for ; Thu, 4 Dec 2003 14:25:39 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1ARtUA-0006Qp-Ug for voql@ivoa.net; Thu, 04 Dec 2003 13:25:38 +0000 Received: (qmail 21658 invoked from network); 4 Dec 2003 13:25:59 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 4 Dec 2003 13:25:59 -0000 Date: Thu, 4 Dec 2003 13:25:37 +0000 (GMT) From: Clive Page To: Tony Linde , Subject: Comments on ADQL v0.6 - function list In-Reply-To: <20031202113824.D31268@skysrv.pha.jhu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Based on the recent messages and the analysis set out here: http://wiki.astrogrid.org/bin/view/Astrogrid/DBMSmathFunctions I would like to propose a change to the names of the log functions in ADQL. All the other names correspond to those in JDBC, and I expect that many projects will write software which interfaces to databases via JDBC (AstroGrid is certainly planning to do so). I note that the JDBC specification (which can be downloaded from http://java.sun.com/products/jdbc/) says "Because scalar functions are supported by different DBMSs with slightly different syntax, it is the driver's job either to map them into the appropriate syntax or to implement the functions directly in the driver". I guess this means that all standard-compliant JDBC drivers actually support all these functions. I would therefore like to suggest that ADQL changes the names: ln ==> log for the log to base e log ==> log10 for the log to base 10. This also makes ADQL consistent with MySQL, SQL Server, and Sybase (but of course inconsistent with DB2, Oracle, and Postgres, but complete consistency cannot be obtained). Because this changes the meaning of the the name "log" it seems better to make this change before people start using it significantly. Perhaps I can take this opportunity to report to the editors of the ADQL and SkyNode documents a few minor problems in v0.6 documents: Both documents have a date of 2003-06-02 at the top right of each page - should this be updated to reflect the date of the current revision? ADQL document section ADQL-5 lists the "floor" function twice. The PDF files linked from http://skyservice.pha.jhu.edu/develop/vo/adql/ appear to be defective - when I download each one I got a file of just a few hundred bytes. The Word versions seem fine. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-swg-at-large@eso.org Thu Dec 4 20:03:15 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 hB4J2HlK022810 for ; Thu, 4 Dec 2003 20:02:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4J2H6I022799 for swg-at-large-outgoing; Thu, 4 Dec 2003 20:02:17 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-swg-at-large@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-swg-at-large@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-voql@eso.org Mon Dec 8 18:18:27 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 hB8HHOFi012393 for ; Mon, 8 Dec 2003 18:17:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB8HHNYD012385 for voql-outgoing; Mon, 8 Dec 2003 18:17:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB8HGaFi012203 for ; Mon, 8 Dec 2003 18:16:36 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB8HGYUp021230 for ; Mon, 8 Dec 2003 18:16:35 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB8HGWj09428 for ; Mon, 8 Dec 2003 09:16:32 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv8.ipac.caltech.edu [134.4.40.117]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB8HGTV09419; Mon, 8 Dec 2003 09:16:29 -0800 (PST) Message-ID: <3FD4B1E6.9585F894@ipac.caltech.edu> Date: Mon, 08 Dec 2003 09:16:23 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: voql@ivoa.net CC: gbb@ipac.caltech.edu Subject: Comments of SkyNode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: General Comments My last email engendered enough discussion that I thought it would be wise to actually thoroughly read *both* documents before venturing to make further comment. First, let me say that I completely endorse the general approach, both of separating the language definition from the service definition and of casting the language into an XML form; It is quite easy to reform the XML into SQL but rather difficult to do the reverse. I also think it is a good idea to define the language so that it supports future expansion, though I have some reservations about inventing too much ourselves that may prove to be at odds with current and future activities in related disciplines (notably the GIS community). We don't have much of a choice right now since there is no real concensus there but they are much bigger than we are. Second, Wil was quite right to point out that my issues are really more related to SkyNode than ADQL. Even though I raised it, I don't really see the issue of function names as that serious. This is in part, frankly, that I expect the vast majority of real use will not need them. Please take what I say below in the above spirit. My worries are not theoretical but pragmatic; I have no objection to where the we are going, just the steps along the way. SkyNode Concerns My main concern at this point is that I think the SkyNode approach as currently written sets the bar much too high. It relies heavily on things like SOAP, JDBC, adaptive clients and the like. We need to take a pragmatic approach to system design, building what will work in the real world of funding, general programmer abilities, and real user preconceptions. This means concentrating first on simple queries through basic Apache, etc. installations using HTTP GET/POST. That doesn't have to be the only thing we do, but it should be the first. The orinal Cone Search had some fatal flaws -- It didn't allow field lists or relational constraints and it only supported a cone area -- but otherwise was on the right track: a simple HTTP GET/POST query with a single table returned. I have no objection to more complex constructs but only if they are in *addition* to the simple form (which is what the vast majority of service providers will opt for, given the chance). Almost all the real value of these services (in the forseeable future) is going to come out of basic catalog subsetting queries ("SELECT x, y, z FROM a WHERE b > c") augmented with spatial constraints ("WITHIN 5 arcmin OF M31" or "POLYGON 10 40, 11, 40, 11, 41, 10, 41"). I would be very surprised if more than a fraction of a percent of queries (and I mean that literally) used anything more this simple interaction. We have, within IRSA, 2MASS and NED, several instances of tables that explicitly refer to other tables but we consciously expose these as "views" (i.e. joins that look like tables) since it would be very difficult for any outside party (and especially an end user) to understand enough to construct joined queries themselves. This is a thousand times worse in a distributed environment. Distributed heterogenous DBMSs are pretty much a myth and I don't like to see the VO effort going down that well-worn path. Frankly, I suspect that even if we were to build everything we can think of into our database services, we would find not only that most users would not need such advanced features but that even those users who were doing advanced work would use simple queries upon which they would layer their own "advanced" post-processing. Also, as I said in an earlier email, I suspect that many (if not most) managers of large DBMS installations will not allow their facilities to be used in this way. We can bury our heads in the sand any deny this or think that they will become enlightened but this is both a political and a monetary issue and we can't really solve that with software design, no matter how progressive. There seems to be an unspoken presumption (here and elsewhere in the VO effort) that these standards are aimed at "us" (the VO crowd and like-minded people) and that we will have dedicated resources to implement a System. I prefer to think that we are attempting to define ifrastructure components that will have wide applicability and very low buy-in and would be used widely even if the funded VO projects go away. Our use cases should include, for instance, an individual researcher who publishes a formatted table as a Web document with no active service at all and relies on VO tools to make this searchable (without it being ingested in someone else's DBMS). I disagree with the approach alluded to in a couple of emails that has to do with "adaptive" processing. If the standard allows for a broad range of capabilities, with each server required to provide a minimum set and then publishing which of the others they do and don't provide, all that will happen is that software developers will program to the lowest common denominator (and possible add some of the advanced features to the client side even when they are available on a particular server). Conclusions OK, that's my diatribe. I have a few more issues associated with catalog cross-comparison but that is really a separate issue and should be handled in a separate email. Bottom line: We need, as part of our first step, simple HTTP GET/POST single table subsetting services and toolkits for potential service providers to aid them in making this a reality. From owner-voql@eso.org Tue Dec 9 06:15:37 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 hB95EQ3q018720 for ; Tue, 9 Dec 2003 06:14:26 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB95EQgL018719 for voql-outgoing; Tue, 9 Dec 2003 06:14:26 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB95Dq3q018629 for ; Tue, 9 Dec 2003 06:13:53 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB95Do5E003683 for ; Tue, 9 Dec 2003 06:13:51 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id OAA11889 for ; Tue, 9 Dec 2003 14:13:48 +0900 (JST) Message-Id: <6.0.0.20.2.20031209141257.02ea8528@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 09 Dec 2003 14:13:51 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Fwd: Re: Comments of SkyNode Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Sorry I did not c/c to voql@ivoa.net. Masatoshi >Date: Tue, 09 Dec 2003 14:12:43 +0900 >To: John Good >From: Masatoshi OHISHI >Subject: Re: Comments of SkyNode > >John, > >As many of our WG members already pointed out, the proposed standards >do not mention anything how to implement them. We discussed which >functionalities are necessary. Therefore you may use HTTP GET/POST >in your implementation, if you decide to do so in your site. >What VO users want is correct results regardless how the system is implemented. > >Cheers, > > Masatoshi From owner-voql@eso.org Tue Dec 9 16:23:52 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 hB9FMpbJ017768 for ; Tue, 9 Dec 2003 16:22:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB9FLr7C017615 for voql-outgoing; Tue, 9 Dec 2003 16:21:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB9FLJ3q017443 for ; Tue, 9 Dec 2003 16:21:19 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB9FLI5E017300 for ; Tue, 9 Dec 2003 16:21:19 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB9FLGj18855 for ; Tue, 9 Dec 2003 07:21:16 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv7.ipac.caltech.edu [134.4.40.116]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hB9FLEV18852; Tue, 9 Dec 2003 07:21:14 -0800 (PST) Message-ID: <3FD5E864.A7B7AA5E@ipac.caltech.edu> Date: Tue, 09 Dec 2003 07:21:08 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: voql@ivoa.net CC: gbb@ipac.caltech.edu Subject: Re: Comments of SkyNode References: <3FD4B1E6.9585F894@ipac.caltech.edu> <6.0.0.20.2.20031209140612.02ea88e8@mail.mtk.nao.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Masatoshi - That isn't how the document comes across. I was also reacting to some other things I have seen, including what looks like an ADASS poster with several of this group's names on it which says: "All data servers joining the International Virtual Observatory would implement a standard IVOA SkyNode Interface based on SOAP (Simple Object Access Protocol)" Of course VO science users want correct results; that goes without saying. What VO service users (i.e. builders of client software) want is clear details on how to interface to those services. Is the above quote no longer valid? - John Masatoshi OHISHI wrote: > John, > > As many of our WG members already pointed out, the proposed standards > do not mention anything how to implement them. We discussed which > functionalities are necessary. Therefore you may use HTTP GET/POST > in your implementation, if you decide to do so in your site. > What VO users want is correct results regardless how the system is implemented. > > Cheers, > > Masatoshi From owner-voql@eso.org Tue Dec 9 17:47:13 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 hB9GkObJ009548 for ; Tue, 9 Dec 2003 17:46:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB9GkOKJ009546 for voql-outgoing; Tue, 9 Dec 2003 17:46:24 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hB9GjobJ009457 for ; Tue, 9 Dec 2003 17:45:50 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB9Gjn5E019761 for ; Tue, 9 Dec 2003 17:45:50 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hB9GjkO01480; Tue, 9 Dec 2003 11:45:46 -0500 Date: Tue, 9 Dec 2003 11:45:46 -0500 From: "Wil O'Mullane" To: John Good Cc: voql@ivoa.net, gbb@ipac.caltech.edu Subject: Re: Comments of SkyNode Message-ID: <20031209114546.F31702@skysrv.pha.jhu.edu> References: <3FD4B1E6.9585F894@ipac.caltech.edu> <6.0.0.20.2.20031209140612.02ea88e8@mail.mtk.nao.ac.jp> <3FD5E864.A7B7AA5E@ipac.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FD5E864.A7B7AA5E@ipac.caltech.edu>; from jcg@ipac.caltech.edu on Tue, Dec 09, 2003 at 07:21:08AM -0800 X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: My idea was certainly to use SOAP .. wil On Tue, Dec 09, 2003 at 07:21:08AM -0800, John Good wrote: > > > Masatoshi - > > That isn't how the document comes across. I was also > reacting to some other things I have seen, including > what looks like an ADASS poster with several of this > group's names on it which says: > > "All data servers joining the International Virtual > Observatory would implement a standard IVOA > SkyNode Interface based on SOAP (Simple Object > Access Protocol)" > > Of course VO science users want correct results; > that goes without saying. What VO service users > (i.e. builders of client software) want is clear details > on how to interface to those services. > > Is the above quote no longer valid? > > - John > > > > > Masatoshi OHISHI wrote: > > > John, > > > > As many of our WG members already pointed out, the proposed standards > > do not mention anything how to implement them. We discussed which > > functionalities are necessary. Therefore you may use HTTP GET/POST > > in your implementation, if you decide to do so in your site. > > What VO users want is correct results regardless how the system is implemented. > > > > Cheers, > > > > Masatoshi From owner-voql@eso.org Sat Dec 13 08:15:56 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 hBD7EeEg005510 for ; Sat, 13 Dec 2003 08:14:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBD7EeeG005507 for voql-outgoing; Sat, 13 Dec 2003 08:14:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBD7E4Eg005440 for ; Sat, 13 Dec 2003 08:14:05 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBD7E1Up020986 for ; Sat, 13 Dec 2003 08:14:03 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id QAA18976; Sat, 13 Dec 2003 16:13:47 +0900 (JST) Message-Id: <6.0.0.20.2.20031213161243.02f5fcb0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 13 Dec 2003 16:13:47 +0900 To: "Wil O'Mullane" , John Good From: Masatoshi OHISHI Subject: Re: Comments of SkyNode Cc: voql@ivoa.net, gbb@ipac.caltech.edu In-Reply-To: <20031209114546.F31702@skysrv.pha.jhu.edu> References: <3FD4B1E6.9585F894@ipac.caltech.edu> <6.0.0.20.2.20031209140612.02ea88e8@mail.mtk.nao.ac.jp> <3FD5E864.A7B7AA5E@ipac.caltech.edu> <20031209114546.F31702@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, At 11:45 03/12/09 -0500, Wil O'Mullane wrote: > >My idea was certainly to use SOAP .. Since ADQL is expressed in XML format, this is quite natural selection. Masatoshi From owner-voql@eso.org Sat Dec 13 17:28:07 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 hBDGR8Eg024478 for ; Sat, 13 Dec 2003 17:27:08 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBDGR835024477 for voql-outgoing; Sat, 13 Dec 2003 17:27:08 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBDGQWEg024414 for ; Sat, 13 Dec 2003 17:26:33 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBDGQV5E021919 for ; Sat, 13 Dec 2003 17:26:31 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hBDGQTj21752 for ; Sat, 13 Dec 2003 08:26:29 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv2.ipac.caltech.edu [134.4.40.111]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hBDGQPV21743; Sat, 13 Dec 2003 08:26:25 -0800 (PST) Message-ID: <3FDB3DAA.5ADC23AB@ipac.caltech.edu> Date: Sat, 13 Dec 2003 08:26:18 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: Masatoshi OHISHI CC: "Wil O'Mullane" , voql@ivoa.net, gbb@ipac.caltech.edu Subject: Re: Comments of SkyNode References: <3FD4B1E6.9585F894@ipac.caltech.edu> <6.0.0.20.2.20031209140612.02ea88e8@mail.mtk.nao.ac.jp> <3FD5E864.A7B7AA5E@ipac.caltech.edu> <20031209114546.F31702@skysrv.pha.jhu.edu> <6.0.0.20.2.20031213161243.02f5fcb0@mail.mtk.nao.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Masatoshi OHISHI wrote: > Hi Wil, > > At 11:45 03/12/09 -0500, Wil O'Mullane wrote: > > > >My idea was certainly to use SOAP .. > > Since ADQL is expressed in XML format, this is quite natural selection. > > Masatoshi I disagree. Just because SOAP uses XML doesn't imply that anything that uses XML is best served using SOAP. The choice of protocol should not be predicated on message content but on what is most effective for the community. Here the nature of the interaction is stateless, the requests and responses single text blocks (even if in XML), and the services of general interest (i.e., lots of people -- many of them pretty IT-naive astronomers would like direct access). That argues against SOAP as the only (or even the primary) access mechanism. You are running a very decided risk of alienating the very people most likely to make (or break) this system. The VO efforts have already be characterized as "welfare for IT researchers". You don't want to perpetuate that. - John From owner-voql@eso.org Sun Dec 14 04:34:48 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 hBE3XhGl006137 for ; Sun, 14 Dec 2003 04:33:43 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBE3XhGI006136 for voql-outgoing; Sun, 14 Dec 2003 04:33:43 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBE3X8Gl006038 for ; Sun, 14 Dec 2003 04:33:09 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBE3X65E001569 for ; Sun, 14 Dec 2003 04:33:07 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id MAA16488; Sun, 14 Dec 2003 12:32:52 +0900 (JST) Message-Id: <6.0.0.20.2.20031214122748.02d5cb00@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 14 Dec 2003 12:32:21 +0900 To: John Good From: Masatoshi OHISHI Subject: Re: Comments of SkyNode Cc: "Wil O'Mullane" , voql@ivoa.net, gbb@ipac.caltech.edu In-Reply-To: <3FDB3DAA.5ADC23AB@ipac.caltech.edu> References: <3FD4B1E6.9585F894@ipac.caltech.edu> <6.0.0.20.2.20031209140612.02ea88e8@mail.mtk.nao.ac.jp> <3FD5E864.A7B7AA5E@ipac.caltech.edu> <20031209114546.F31702@skysrv.pha.jhu.edu> <6.0.0.20.2.20031213161243.02f5fcb0@mail.mtk.nao.ac.jp> <3FDB3DAA.5ADC23AB@ipac.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: John, As I and other people mentioned before many times, this WG is to discuss standard query language to communicate between VOs. This WG doesn't discuss on SOAP, XML, HTTP GET/PUT and so on. If you want disscuss on such issues, why don't you propose to set up other WG. Masatoshi From owner-voql@eso.org Tue Dec 16 03:15:09 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 hBG2EWxc001633 for ; Tue, 16 Dec 2003 03:14:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBG2EWZ4001632 for voql-outgoing; Tue, 16 Dec 2003 03:14:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBG2EUxc001624 for ; Tue, 16 Dec 2003 03:14:30 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBG2ERT9020739 for ; Tue, 16 Dec 2003 03:14:28 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id LAA09539 for ; Tue, 16 Dec 2003 11:14:25 +0900 (JST) Message-Id: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Tue, 16 Dec 2003 11:14:28 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: SOAP / HTTP GET ? Mime-Version: 1.0 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi VOQL members, As you may have seen, a hot discussion is going on which physical protocol is preferable to exchange ADQL. I have several questions to you all. I have got the following message from the NVO team: >In the NVO team meeting last week the broad agreement for this was to use >SOAP. There are a few reasons for this. > >HTTP/GET in any case will not work for some of the SkyNode capabilities. >So we need to do POST and most of the returns are XML already - >SOAP is really not much more complex then HTTP POST returning XML. You still >do POST just that you sent up XML as well as get it back. > >Having WSDL gives a very solid definition of the service interface much >more so than a document as we had for CONE. > >The NVO and IVOA ( web and grid/services IVOA meeting Strasbourg) have elected >to do SOAP as a stepping stone to Grid Services. > >So I think SOAP and WSDL are the way to do this. > >This does not preclude a Portal which does some form of HTTP/GET for some of >the simpler interfaces and makes the SOAP request for you. The .NET framework >does this in any case. I would like to hear from you which physical protocol do other VO teams want to adopt. This is just to "measure" the atomosphre of our community before proceeding further. Another important item: do everybody agree with the current contents of two working drafts (ADQL and SkyNode) except for editorial modifications ? If so, may we approve these documents and send them to draft IVOA recs ? Please note that I won't send these docs to IVOA executive committee in a case when many people have strong objections. Merry Christmas and a Happy New Year!! Masatoshi From owner-voql@eso.org Tue Dec 16 06:25:33 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 hBG5P4xc020196 for ; Tue, 16 Dec 2003 06:25:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBG5P4nE020195 for voql-outgoing; Tue, 16 Dec 2003 06:25:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBG5P1xc020176 for ; Tue, 16 Dec 2003 06:25:02 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBG5OvT9022784 for ; Tue, 16 Dec 2003 06:24:58 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hBG5Otj08690 for ; Mon, 15 Dec 2003 21:24:55 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv7.ipac.caltech.edu [134.4.40.116]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id hBG5OpV08682; Mon, 15 Dec 2003 21:24:51 -0800 (PST) Message-ID: <3FDE971F.62BB5174@ipac.caltech.edu> Date: Mon, 15 Dec 2003 21:24:47 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: Masatoshi OHISHI CC: voql@ivoa.net Subject: Re: SOAP / HTTP GET ? References: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> Content-Type: multipart/alternative; boundary="------------065EB8EBF8FEF3E3C11D3550" 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-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: --------------065EB8EBF8FEF3E3C11D3550 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Masatoshi - I think you message may be just a tiny bit biased ;=). You are forgetting that the rest of group hasn't seen the email you, Wil, and I exchanged earlier today. Wil can send his out if he likes, here's the one I sent this morning. As I said there, I don't see this as an either/or but rather as defining the range of implementation strategies that will be most effective in supporting the community. - John ---------------------------------------------------------------------------------------------------------------------------- Subject: Re: Comments of SkyNode Date: Mon, 15 Dec 2003 11:31:53 -0800 From: John Good Organization: IPAC / Caltech To: "Wil O'Mullane" CC: masatoshi.ohishi@nao.ac.jp, gbb@ipac.caltech.edu, szalay@pha.jhu.edu, hanisch@stsci.edu Wil - I have no objection to SOAP where warranted (and even in places where it isn't). I do think the community would be best served if 1) everyone making data available provided a direct HTTP GET for those functions where it makes sense and 2) data providers who wish to provide no other mechanism were accepted as peers with everyone else. IRSA will certainly provide the full range of functionality through SOAP, GET, JAVA RMI, and anything else the user community wants. There may indeed be some functions that need the SOAP or equivalent, but, as I said earlier, the vast majority of queries are going to be simple table subsets. We've had services for a few years now that do just this: http://irsa.ipac.caltech.edu/cgi-bin/Oasis/CatSearch/nph-catsearch? server=%40rmt_gravel& database=iras& catalog=iraspsc& sql=select+ra%2C+dec%2C+fnu_12+from+iraspsc+where+fnu_12%3E1.0& within=2+degrees& objstr=M31 Don't underestimate the power of being able to embed such a link on a web page as (hopefully) here. You can't really do that with SOAP. Obviously, it will be easy to wrap this same functionality as a SOAP service. My point was that it is also easy and powerful to provide it via HTTP GET. I suggest you poll a few "outside" data suppliers and scientific consumers (i.e. people not associated with any VO activity and not professional IT people) and see what they think. I'm really not resisting SOAP. I'm just afraid that if you focus on it alone you will disconnect from the community. This isn't an all-or-nothing situation; I agree completely that if one wants to implement all of the functions defined for a full SkyNode SOAP is much more appropriate than anything one could set up using HTTP GET. Of course, JAVA RMI or CORBA would be even more efficient but that would be even more restrictive from a community buy-in point of view. Where I disagree is with the conclusion that we should therefore use nothing but SOAP. I'd give pretty good odds that if VO defined both SOAP and GET interfaces for those functions where GET makes sense, that the GET services would be both more implemented and more used. Two minor points: 1) WSDL can describe a GET application perfectly well; and 2) SOAP is not particularly prevalent in the GRID community (not that it isn't used, it just isn't all that pervasive). - John --------------065EB8EBF8FEF3E3C11D3550 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Masatoshi -

I think you message may be just a tiny bit biased ;=).

You are forgetting that the rest of group hasn't seen the
email you, Wil, and I exchanged earlier today.  Wil can
send his out if he likes, here's the one I sent this morning.

As I said there, I don't see this as an either/or but rather
as defining the range of implementation strategies that
will be most effective in supporting the community.

-  John
 

----------------------------------------------------------------------------------------------------------------------------

Subject:           Re: Comments of SkyNode
Date:                Mon, 15 Dec 2003 11:31:53 -0800
From:                John Good <jcg@ipac.caltech.edu>
Organization:  IPAC / Caltech
To:                    "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
CC:                    masatoshi.ohishi@nao.ac.jp, gbb@ipac.caltech.edu, szalay@pha.jhu.edu, hanisch@stsci.edu
 

Wil -

I have no objection to SOAP where warranted (and even in places where
it isn't).  I do think the community would be best served if  1) everyone
making data available provided a direct HTTP GET for those functions
where it makes sense and  2) data providers who wish to provide no
other mechanism were accepted as peers with everyone else.

IRSA will certainly provide the full range of functionality through SOAP,
GET, JAVA RMI, and anything else the user community wants.

There may indeed be some functions that need the SOAP or equivalent,
but, as I said earlier, the vast majority of queries are going to be simple
table subsets.  We've had services for a few years now that do just this:

   http://irsa.ipac.caltech.edu/cgi-bin/Oasis/CatSearch/nph-catsearch?
   server=%40rmt_gravel&
   database=iras&
   catalog=iraspsc&
   sql=select+ra%2C+dec%2C+fnu_12+from+iraspsc+where+fnu_12%3E1.0&
   within=2+degrees&
   objstr=M31

Don't underestimate the power of being able to embed such a link on a web page
as (hopefully) <a
href=http://irsa.ipac.caltech.edu/cgi-bin/Oasis/CatSearch/nph-catsearch?server=%40rmt_gravel&database=iras&amp;catalog=iraspsc&amp;sql=select+ra%2C+dec%2C+fnu_12+from+iraspsc+where+fnu_12%3E1.0&amp;within=2+degrees&amp;objstr=M31>

here</a>.  You can't really do that with SOAP.

Obviously, it will be easy to wrap this same functionality as a SOAP service.
My point was that it is also easy and powerful to provide it via HTTP GET.
I suggest you poll a few "outside" data suppliers and scientific consumers
(i.e. people not associated with any VO activity and not professional IT
people) and see what they think.

I'm really not resisting SOAP.  I'm just afraid that if you focus on it alone
you will disconnect from the community.  This isn't an all-or-nothing situation;
I agree completely that if one wants to implement all of the functions defined
for a full SkyNode SOAP is much more appropriate than anything one could
set up using HTTP GET.   Of course, JAVA RMI or CORBA would be
even more efficient but that would be even more restrictive from a community
buy-in point of view.

Where I disagree is with the conclusion that we should therefore use nothing
but SOAP.  I'd give pretty good odds that if VO defined both SOAP and
GET interfaces for those functions where GET makes sense, that the GET
services would be both more implemented and more used.

Two minor points:  1) WSDL can describe a GET application perfectly well;
and  2) SOAP is not particularly prevalent in the GRID community (not that
it isn't used, it just isn't all that pervasive).

- John --------------065EB8EBF8FEF3E3C11D3550-- From owner-voql@eso.org Tue Dec 16 10:51:32 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 hBG9pAVK026097 for ; Tue, 16 Dec 2003 10:51:10 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBG9pAKZ026095 for voql-outgoing; Tue, 16 Dec 2003 10:51:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBG9p7VK026080 for ; Tue, 16 Dec 2003 10:51:07 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBG9p44B006078 for ; Tue, 16 Dec 2003 10:51:04 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id hBG9p3m7010952; Tue, 16 Dec 2003 09:51:03 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id hBG9p1LO010951; Tue, 16 Dec 2003 09:51:01 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 16 Dec 2003 09:51:01 +0000 Message-ID: <1071568261.3fded585894e4@netmail.pipex.net> Date: Tue, 16 Dec 2003 09:51:01 +0000 From: martin hill To: Masatoshi OHISHI Cc: voql@ivoa.net Subject: Re: SOAP / HTTP GET ? References: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> In-Reply-To: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: (Including comments on your later email of GET vs POST etc) One of the problems with opening up a range of options is that it makes it harder to connect them together. A single standard that, as you say, is straightforward to implement, will help get the interoperability we want early on. Building SOAP-based servers is not actually that hard, even compared to relatively straightforward script-based ones. There are a few more terms to learn, and tools to use to generate the stuff you need, but it's not a large leap on from NVO-cone-search style GETs etc. I think the hardest thing is going to be implementing general ADQL-Region (ie circle, rectangle, polygon, etc) searches for all databases... Also, as I understand it, you can reach Tomcat/Axis-hosted service methods using a url something like this: http://grendel12.roe.ac.uk/pal? methodname&par1=a&par2=b , so you can insert such links into documents. Can anyone tell me if this is 'standard' for most web service implementations? Generally speaking I think we (astrogrid datacenter) are happy with SkyNode; however we have some comments on ADQL. Now that we're actually using it in practice we're finding it very verbose, with a few awkwardnesses in processing/extracting. But we'll come back to you with something more thorough on that, 'real soon now'. Quoting Masatoshi OHISHI : > Hi VOQL members, > > As you may have seen, a hot discussion is going on which physical protocol > is preferable to exchange ADQL. I have several questions to you all. > > I have got the following message from the NVO team: > > >In the NVO team meeting last week the broad agreement for this was to use > >SOAP. There are a few reasons for this. > > > >HTTP/GET in any case will not work for some of the SkyNode capabilities. > >So we need to do POST and most of the returns are XML already - > >SOAP is really not much more complex then HTTP POST returning XML. You > still > >do POST just that you sent up XML as well as get it back. > > > >Having WSDL gives a very solid definition of the service interface much > >more so than a document as we had for CONE. > > > >The NVO and IVOA ( web and grid/services IVOA meeting Strasbourg) have > elected > >to do SOAP as a stepping stone to Grid Services. > > > >So I think SOAP and WSDL are the way to do this. > > > >This does not preclude a Portal which does some form of HTTP/GET for some > of > >the simpler interfaces and makes the SOAP request for you. The .NET > framework > >does this in any case. > > I would like to hear from you which physical protocol do other VO teams want > to > adopt. This is just to "measure" the atomosphre of our community before > proceeding further. > > Another important item: do everybody agree with the current contents of two > working drafts (ADQL and SkyNode) except for editorial modifications ? > If so, may we approve these documents and send them to draft IVOA recs ? > Please note that I won't send these docs to IVOA executive committee > in a case when many people have strong objections. > > Merry Christmas and a Happy New Year!! > > Masatoshi > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Tue Dec 16 23:07:48 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 hBGM7LHX006427 for ; Tue, 16 Dec 2003 23:07:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBGM7Lge006426 for voql-outgoing; Tue, 16 Dec 2003 23:07:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBGM7JHX006416 for ; Tue, 16 Dec 2003 23:07:19 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBGM7G4B025591 for ; Tue, 16 Dec 2003 23:07:17 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id hBGM79b25780; Tue, 16 Dec 2003 17:07:09 -0500 Date: Tue, 16 Dec 2003 17:07:09 -0500 From: "Wil O'Mullane" To: Masatoshi OHISHI Cc: voql@ivoa.net Subject: Readyness of Specifications Message-ID: <20031216170709.Y25226@skysrv.pha.jhu.edu> References: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp>; from masatoshi.ohishi@nao.ac.jp on Tue, Dec 16, 2003 at 11:14:28AM +0900 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > Another important item: do everybody agree with the current contents of two > working drafts (ADQL and SkyNode) except for editorial modifications ? > If so, may we approve these documents and send them to draft IVOA recs ? > Please note that I won't send these docs to IVOA executive committee > in a case when many people have strong objections. Obviously I have no strong objections but the SkyNode spec for Full Sky Node will undergo Serious revision in the new year as we work more on the portal. Again I feel this was acknowledged at Strasbourg and agreed it would not prevent us moving forward. I suppose even if adopted by IVOA it does not stop new versions. ADQL is more stable but a new version is in the works (mainly editorial). wil From owner-voql@eso.org Wed Dec 17 04:34:55 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 hBH3YCiX008264 for ; Wed, 17 Dec 2003 04:34:12 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hBH3YCGp008262 for voql-outgoing; Wed, 17 Dec 2003 04:34:12 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 hBH3Y8iX008251 for ; Wed, 17 Dec 2003 04:34:08 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hBH3Y3T9020371 for ; Wed, 17 Dec 2003 04:34:05 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id MAA00526; Wed, 17 Dec 2003 12:33:54 +0900 (JST) Message-Id: <6.0.0.20.2.20031217122256.02e8cec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 17 Dec 2003 12:33:53 +0900 To: "Wil O'Mullane" From: Masatoshi OHISHI Subject: Re: Readyness of Specifications Cc: voql@ivoa.net In-Reply-To: <20031216170709.Y25226@skysrv.pha.jhu.edu> References: <6.0.0.20.2.20031216110455.02e18ec0@mail.mtk.nao.ac.jp> <20031216170709.Y25226@skysrv.pha.jhu.edu> Mime-Version: 1.0 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil, At 17:07 03/12/16 -0500, Wil O'Mullane wrote: >it would not >prevent us moving forward. I suppose even if adopted by IVOA it does not >stop new versions. Of course !! > >ADQL is more stable but a new version is in the works (mainly editorial). If your revision will be done so soon, it woud be better to wait for that before approving these WD in our WG. How long do you expect it will take ? Cheers, Masatoshi From owner-voql@eso.org Tue Jan 13 11:13:58 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 i0DACwNd006077 for ; Tue, 13 Jan 2004 11:12:58 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0DACw8c006076 for voql-outgoing; Tue, 13 Jan 2004 11:12:58 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0DACuNd006067 for ; Tue, 13 Jan 2004 11:12:56 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0DACqt4023605 for ; Tue, 13 Jan 2004 11:12:54 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id TAA08682 for ; Tue, 13 Jan 2004 19:12:51 +0900 (JST) Message-Id: <6.0.0.20.2.20040113190100.0304a8f0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Tue, 13 Jan 2004 19:12:51 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: ADQL-0.7 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi VOQL friends, Wil O'Mullane of JHU has made a minor revision to our ADQL working document, and ADQL-0.7.pdf has been uploaded to the IVOA WG area. Please download the document from the URL below. http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL/ADQL-0.7.pdf If you have comments (objections) to this document, please circulate your comment(s) to our mail exploder list (voql@ivoa.net). If I see no major objections before 0000 hours ,January 24th, (GMT), I will forward this document to the IVOA executive committee for their approval. Because I received no major objections to our another working document on the SkyNode (the document is SkyNodeInterface-0.5.pdf), I would like to approve the SkyNode document in our group. If you agree with me (or you show no objections to do so), I would like to send two documents to the IVOA executive committee as proposed Recommendation documents. Any comments ? Cheers, Masatoshi From owner-voql@eso.org Tue Jan 13 21:50:06 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 i0DKmpjS004632 for ; Tue, 13 Jan 2004 21:48:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0DKmp32004631 for voql-outgoing; Tue, 13 Jan 2004 21:48:51 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0DKmnjS004623 for ; Tue, 13 Jan 2004 21:48:49 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0DKmjJX008411 for ; Tue, 13 Jan 2004 21:48:46 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id i0DKmgj12745 for ; Tue, 13 Jan 2004 12:48:42 -0800 (PST) Received: from ipac.caltech.edu (oasis.ipacds.ipac.caltech.edu [134.4.70.173]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id i0DKmeV12736; Tue, 13 Jan 2004 12:48:40 -0800 (PST) Message-ID: <400459A8.2A0B5452@ipac.caltech.edu> Date: Tue, 13 Jan 2004 12:48:40 -0800 From: John Good Organization: IPAC / Caltech X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Masatoshi OHISHI CC: voql@ivoa.net Subject: Re: ADQL-0.7 References: <6.0.0.20.2.20040113190100.0304a8f0@mail.mtk.nao.ac.jp> Content-Type: text/plain; charset=us-ascii 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-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Masatoshi - The link below does not seem to work for me. - John Masatoshi OHISHI wrote: > Hi VOQL friends, > > Wil O'Mullane of JHU has made a minor revision to our ADQL > working document, and ADQL-0.7.pdf has been uploaded to the > IVOA WG area. Please download the document from the URL below. > > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL/ADQL-0.7.pdf > > If you have comments (objections) to this document, please circulate > your comment(s) to our mail exploder list (voql@ivoa.net). If I see no > major objections before 0000 hours ,January 24th, (GMT), I will > forward this document to the IVOA executive committee for their > approval. > > Because I received no major objections to our another working document > on the SkyNode (the document is SkyNodeInterface-0.5.pdf), > I would like to approve the SkyNode document in our group. > > If you agree with me (or you show no objections to do so), I would like to > send two documents to the IVOA executive committee as proposed > Recommendation documents. > > Any comments ? > > Cheers, > > Masatoshi From owner-voql@eso.org Tue Jan 13 21:59:10 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 i0DKw2jS006115 for ; Tue, 13 Jan 2004 21:58:02 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0DKw2Rk006114 for voql-outgoing; Tue, 13 Jan 2004 21:58:02 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0DKw0jS006098 for ; Tue, 13 Jan 2004 21:58:00 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0DKvwJX008651 for ; Tue, 13 Jan 2004 21:57:59 +0100 (CET) Received: from localhost (nieto@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i0DKvtM04749; Tue, 13 Jan 2004 15:57:55 -0500 Date: Tue, 13 Jan 2004 15:57:55 -0500 (EST) From: "Maria A. Nieto-Santisteban" To: John Good cc: voql@ivoa.net Subject: Re: ADQL-0.7 In-Reply-To: <400459A8.2A0B5452@ipac.caltech.edu> 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-voql@eso.org Precedence: bulk Reply-To: "Maria A. Nieto-Santisteban" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Try http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL and click on the pdf file Maria On Tue, 13 Jan 2004, John Good wrote: > Masatoshi - > > The link below does not seem to work for me. > > - John > > > Masatoshi OHISHI wrote: > > > Hi VOQL friends, > > > > Wil O'Mullane of JHU has made a minor revision to our ADQL > > working document, and ADQL-0.7.pdf has been uploaded to the > > IVOA WG area. Please download the document from the URL below. > > > > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL/ADQL-0.7.pdf > > > > If you have comments (objections) to this document, please circulate > > your comment(s) to our mail exploder list (voql@ivoa.net). If I see no > > major objections before 0000 hours ,January 24th, (GMT), I will > > forward this document to the IVOA executive committee for their > > approval. > > > > Because I received no major objections to our another working document > > on the SkyNode (the document is SkyNodeInterface-0.5.pdf), > > I would like to approve the SkyNode document in our group. > > > > If you agree with me (or you show no objections to do so), I would like to > > send two documents to the IVOA executive committee as proposed > > Recommendation documents. > > > > Any comments ? > > > > Cheers, > > > > Masatoshi > -- ------------------------------------------------ Maria A. Nieto-Santisteban (nieto@pha.jhu.edu) Johns Hopkins University 3400 N. Charles St. Physics & Astronomy Department Baltimore, MD 21218 (USA) Tel: 1 410 516-7679 Fax: 1 410 516-5096 From owner-voql@eso.org Wed Jan 14 07:09: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 i0E68Ci6005879 for ; Wed, 14 Jan 2004 07:08:12 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0E68Crq005878 for voql-outgoing; Wed, 14 Jan 2004 07:08:12 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0E689i6005867 for ; Wed, 14 Jan 2004 07:08:09 +0100 (MET) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0E687JX018665 for ; Wed, 14 Jan 2004 07:08:07 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040114060751.RIXU5098.mta02-svc.ntlworld.com@gnowee>; Wed, 14 Jan 2004 06:07:51 +0000 From: "Tony Linde" To: "'Masatoshi OHISHI'" , Subject: SkyNodeInterface V0.6 Date: Wed, 14 Jan 2004 06:09:08 -0000 Organization: University of Leicester Message-ID: <003d01c3da64$ec2e7c00$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 In-Reply-To: <6.0.0.20.2.20040113190100.0304a8f0@mail.mtk.nao.ac.jp> 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 i0E68Bi6005874 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi, > SkyNode (the document is SkyNodeInterface-0.5.pdf), I would like to Current document is SkyNodeInterface-0.6.pdf and I have significant objections to it, many as I have already stated regarding the original version. The document wraps too much into a single spec. VOQL has been split out but this doc still contains Open SkyQuery Portal which is inappropriate as an IVOA standard; we do not need a portal standard. Even if we did, it should not be included in the SkyNode spec. I understand the intention to present an architectural whole but this could be done in a Note which cross-refers to the individual specs. What is the intention of the SkyNode interface? Is it to be the *only* way in which any VOQL query can be submitted? Does every data query service have to implement this interface? If not, what others are there and where do they fit in? Even the SkyNode interface wraps up too much: Wil has already proposed a standard 'service' interface and I think this needs to be worked on first before SkyNode can even be considered. I think the SkyNode spec will then need to be radically worked on before it can go forward even as a proposed standard. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 13 January 2004 10:13 > To: voql@ivoa.net > Subject: ADQL-0.7 > > > Hi VOQL friends, > > Wil O'Mullane of JHU has made a minor revision to our ADQL > working document, and ADQL-0.7.pdf has been uploaded to the > IVOA WG area. Please download the document from the URL below. > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL/ADQL-0.7.pdf If you have comments (objections) to this document, please circulate your comment(s) to our mail exploder list (voql@ivoa.net). If I see no major objections before 0000 hours ,January 24th, (GMT), I will forward this document to the IVOA executive committee for their approval. Because I received no major objections to our another working document on the SkyNode (the document is SkyNodeInterface-0.5.pdf), I would like to approve the SkyNode document in our group. If you agree with me (or you show no objections to do so), I would like to send two documents to the IVOA executive committee as proposed Recommendation documents. Any comments ? Cheers, Masatoshi From owner-voql@eso.org Wed Jan 14 08:57:11 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 i0E7u4i6018320 for ; Wed, 14 Jan 2004 08:56:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0E7u4gZ018319 for voql-outgoing; Wed, 14 Jan 2004 08:56:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0E7u0i6018300 for ; Wed, 14 Jan 2004 08:56:00 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0E7tut4020213 for ; Wed, 14 Jan 2004 08:55:58 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id QAA09730 for ; Wed, 14 Jan 2004 16:55:54 +0900 (JST) Message-Id: <6.0.0.20.2.20040114165254.04a81ec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 14 Jan 2004 16:55:56 +0900 To: voql@ivoa.net From: Masatoshi OHISHI Subject: Re: SkyNodeInterface V0.6 In-Reply-To: <003d01c3da64$ec2e7c00$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040113190100.0304a8f0@mail.mtk.nao.ac.jp> <003d01c3da64$ec2e7c00$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, I scanned past emails to VOQLWG between last October and today, but I couldn't find your past objections m(_ _)m Could you resend you opinions ? At 06:09 04/01/14 +0000, Tony Linde wrote: >Current document is SkyNodeInterface-0.6.pdf and I have significant >objections to it, many as I have already stated regarding the original >version. Cheers, Masatoshi From owner-voql@eso.org Wed Jan 14 10:07:17 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 i0E96Bi6000299 for ; Wed, 14 Jan 2004 10:06:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0E96BY7000294 for voql-outgoing; Wed, 14 Jan 2004 10:06:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0E968i6000276 for ; Wed, 14 Jan 2004 10:06:08 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0E966t4021783 for ; Wed, 14 Jan 2004 10:06:06 +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 1AggyT-0000km-G4 for voql@ivoa.net; Wed, 14 Jan 2004 09:06:05 +0000 Received: (qmail 2043 invoked from network); 14 Jan 2004 09:06:26 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 09:06:26 -0000 From: "Tony Linde" To: Subject: RE: comments Date: Wed, 14 Jan 2004 09:07:05 -0000 Organization: University of Leicester Message-ID: <004301c3da7d$c821c790$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 In-Reply-To: <001401c37837$72e94350$0a01a8c0@gnowee> 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 i0E96Ai6000287 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: My comments on the original skyquery spec... > -----Original Message----- > From: owner-registry@eso.org [mailto:owner-registry@eso.org] > On Behalf Of Tony Linde > Sent: 11 September 2003 08:37 > To: openskyquery@pha.jhu.edu > Cc: registry@ivoa.net > Subject: comments > > > Some comments on the latest version of the IVOA SkyNode > Interface (apologies for cross-posting but there are registry > issues in this). > > First comment is really about the scope of the document. I > think it really encompasses three or four separate areas that > ought to be addressed each in its own recommendation: > > 1. Section 4 refers to a 'Standard VO Interface', ie the > minimum interface that *any* service must meet to be > registered on the VO. (I guess this document would fit into > the DAL stream of IVOA?) > > 2. The sections 5 & 6, ADQL and SkyQL, ought to be a single > document under the VOQL stream: SkyQL can be subsumed under > the ADQL document as the string representation of an ADQL > query. I think the ability to accept a SkyQL string ought to > be optional for a skynode, while ADQL is mandatory: xml is > much easier to decode than straight text. Any portal which > allows the user to enter text queries ought to translate it > to ADQL before submitting to a skynode. > > 3. Section 8, SkyNode Interface, ought to specify the minimum > interface that > *any* sky service must meet to be registered on the VO. > Note: the new resource schema devised by Ray and me refers to > a SkyService, but I'd be happy to accept SkyNode as a name > (much more catchy :) ) > > 4. There are references in the document to query functions: > REGION and XMATCH. We should think about whether these should > each be addressed by simple single recommendations or all > included in the ADQL one. (Also part of the VOQL stream.) > > 5. Section 7, SkyQuery Portal: this is certainly separate > from the above two concepts but I don't think it really needs > to be an IVOA standard. It will be up to individual projects > how they construct portals for users. > > > More general comments on the content of the document: > > A. ADQL needs some means of identifying both column names and > UCDs, along the lines of my example at > http://www.ivoa.net/twiki/bin/view/IVOA/TonyOnUCDs#Example_query . See the rest of that document for the reason why. B. I find the explanation of the different levels very confusing. I assume that you're trying to identify how complex a query that a given skynode can handle. Is it wise to second guess which combination of functions a service will choose to implement? Maybe we need some way to identify the functions offered: a list of namespace defined enumerated list of functions (so some functions coould be namespaced from the VOQL recommendation above, others namespaced for that specific service). C. I like the idea of using, in the short term, the ShortName as the unique identifier of mirrored datasets, but see also my idea for a more complex Relationship type in http://ivoa.net/forum/registry/0440.htm . D. re QI-19: I don't see any benefit to adding the need to accept SQL-92 queries as well as ADQL ones. This might be an option which some skynodes offer but it should not be mandatory. It is enough for each skynode to translate ADQL into its own query language without also having to do so for SkyQL and ADQL. I'm impressed with the amount of work that has gone into this document and hope my comments help. Cheers, Tony. __ Tony Linde Phone: +44 (0)116 223 1292 AstroGrid Project Manager Fax: +44 (0)116 252 3311 Dept of Physics & Astronomy Mobile: +44 (0)7753 603356 University of Leicester Email: ael@star.le.ac.uk Leicester, UK LE1 7RH Web: http://www.astrogrid.org From owner-voql@eso.org Wed Jan 14 10:33:09 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 i0E9Vui6004735 for ; Wed, 14 Jan 2004 10:31:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0E9VuAB004732 for voql-outgoing; Wed, 14 Jan 2004 10:31:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0E9Vqi6004710 for ; Wed, 14 Jan 2004 10:31:52 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0E9VoJX021922 for ; Wed, 14 Jan 2004 10:31:51 +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 1AghNO-0002qA-2b for voql@ivoa.net; Wed, 14 Jan 2004 09:31:50 +0000 Received: (qmail 3205 invoked from network); 14 Jan 2004 09:32:11 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 09:32:11 -0000 From: "Tony Linde" To: Subject: RE: SkyNodeInterface V0.6 Date: Wed, 14 Jan 2004 09:32:50 -0000 Organization: University of Leicester Message-ID: <004701c3da81$61066030$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 In-Reply-To: <6.0.0.20.2.20040114165254.04a81ec0@mail.mtk.nao.ac.jp> 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 i0E9Vti6004727 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Done. I'll try to post comments specific to the current versions of the specs later today (after spending so much time on Registry stuff last year I had to get some AstroGrid work done so have not had time to look at the latest specs in any detail). Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 14 January 2004 07:56 > To: voql@ivoa.net > Subject: Re: SkyNodeInterface V0.6 > > > Tony, > > I scanned past emails to VOQLWG between last October and > today, but I couldn't find your past objections m(_ _)m > > Could you resend you opinions ? > > At 06:09 04/01/14 +0000, Tony Linde wrote: > >Current document is SkyNodeInterface-0.6.pdf and I have > significant >objections to it, many as I have already stated > regarding the original >version. > > Cheers, > > Masatoshi > > From owner-voql@eso.org Wed Jan 14 13:18: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 i0ECHRi6001307 for ; Wed, 14 Jan 2004 13:17:27 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0ECHRd5001305 for voql-outgoing; Wed, 14 Jan 2004 13:17:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0ECHOi6001287 for ; Wed, 14 Jan 2004 13:17:24 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0ECHMt4025737 for ; Wed, 14 Jan 2004 13:17:23 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1Agjxa-0004Ao-32 for voql@ivoa.net; Wed, 14 Jan 2004 12:17:22 +0000 Received: (qmail 21383 invoked from network); 14 Jan 2004 12:17:42 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 12:17:42 -0000 From: "Tony Linde" To: Subject: RE: ADQL-0.7 Date: Wed, 14 Jan 2004 12:18:22 -0000 Organization: University of Leicester Message-ID: <005201c3da98$809b4750$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 In-Reply-To: <6.0.0.20.2.20040113190100.0304a8f0@mail.mtk.nao.ac.jp> 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 i0ECHQi6001299 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: A few general comments: A. including the schema diagrams is pointless as they are unreadable. The spec should describe the elements of the ADQL in english and link to the xsd as the definitive version (along the lines of the RM document and the registry schema). B. I don't think we need a definition of SkyQL (makes it sound like a separate language). Just need to describe how an ADQL document may be represented in string form (even provide an XSL translation tool). C. the XSD should be made available before we start the clock ticking on a deadline for feedback. D. Basically, I agree with everything in the ADQL (I think) but the spec needs to be formulated in a way that describes every aspect of the ADQL before we can really ask people to comment on it. But if everyone else feels that the XSD is the only necessary defintion of ADQL then I'll withdraw the idea. ADQL-2: - this illustrates my point. If the xsd IS the standard then we don't need to state this, if not, then all the other aspects of the ADQL also deserve explanation. ADQL-4: - if region is a standard or a draft then we should reference the document, if not then either submit it or include the description/defintion here. ADQL-6: - what form does the version number take? String only or full xml breakdown? What does it mean to services which implement the ADQL? Should a service state which version it implements? How does it signify backwards compatibility and to how many levels? What changes are needed to the Registry to accommodate this? ADQL-8/9/10: - this is confusing and suggests that SkyQL is different to ADQL. Why do we need all this description? Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 13 January 2004 10:13 > To: voql@ivoa.net > Subject: ADQL-0.7 > > > Hi VOQL friends, > > Wil O'Mullane of JHU has made a minor revision to our ADQL > working document, and ADQL-0.7.pdf has been uploaded to the > IVOA WG area. Please download the document from the URL below. > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL/ADQL-0.7.pdf If you have comments (objections) to this document, please circulate your comment(s) to our mail exploder list (voql@ivoa.net). If I see no major objections before 0000 hours ,January 24th, (GMT), I will forward this document to the IVOA executive committee for their approval. Because I received no major objections to our another working document on the SkyNode (the document is SkyNodeInterface-0.5.pdf), I would like to approve the SkyNode document in our group. If you agree with me (or you show no objections to do so), I would like to send two documents to the IVOA executive committee as proposed Recommendation documents. Any comments ? Cheers, Masatoshi From owner-voql@eso.org Wed Jan 14 16:14:12 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 i0EFD8oJ004575 for ; Wed, 14 Jan 2004 16:13:08 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0EFD7XG004570 for voql-outgoing; Wed, 14 Jan 2004 16:13:08 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0EFD3oJ004544 for ; Wed, 14 Jan 2004 16:13:03 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0EFD0JX000169 for ; Wed, 14 Jan 2004 16:13:01 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1AgmhY-00006I-09 for voql@ivoa.net; Wed, 14 Jan 2004 15:13:00 +0000 Received: (qmail 3747 invoked from network); 14 Jan 2004 15:13:20 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 14 Jan 2004 15:13:20 -0000 From: "Tony Linde" To: "'Tony Linde'" , "'Masatoshi OHISHI'" , Subject: RE: SkyNodeInterface V0.6 Date: Wed, 14 Jan 2004 15:13:59 -0000 Organization: University of Leicester Message-ID: <006501c3dab1$098e1980$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 In-Reply-To: <003d01c3da64$ec2e7c00$6124d28f@STAR.LE.AC.UK> 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 i0EFD6oJ004558 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Comments on SkyNode spec: in addition to general comments below. Firstly, I am glad we're getting to this and the generic service spec that Wil posted in the grid list - it is much needed as a basis for future specs. 4. QI-1/2: - this is/should be part of the service spec, not this one. 5.2: - is the basic/full distinction valid? What if a basic service can return a QueryCost: how is this specified? The functions that a query service can perform should be in the metadata; they should each be namespaced and versioned with their own specs (which might be part of this one). 5.2.1: QI-3: - we need a better way of signifying features than is extensible and does not require hard-coding of metadata in the registry xsd. QI-4/5/6...: - these ports need to be better specified or is this in the wsdl? What is the format of the return data? Xml? If so, we need a validating xsd. - Tables, Columns, Formats and Functions are/should be part of the metadata and so do not need separate calls. QI-8: - don't understand this. Is this saying that one query can return the data in multiple formats or just that a query can specify the format (*should be from a namespaced list*) it wants the data returned in? what do the abstract class and subclasses mean? Are these Java classes or XSD classes? QI-9: - why do we need this? The metadata for the service should cover all this. If it doesn't then we need to change the metadata (tables and columns are covered). QI-10: - I found the name of this misleading: I assumed it was referring to the cost of the query in runtime, memory or storage units of some kind. Can we have an explanation of how this is done and what the calling service would use it for? QI-12: - this seems to wrap several functions which are better split out: the ability to *create* a table and populate it (whether via VOTable or via some other ADQL query); the ability to Xmatch. If this function is saying that VOTable and some query result can be cross-matched without loading the the VOTable as a db table, how is this supposed to be done? Are the calculations provided the *only* way of doing XMatching? What if someone wants to provide the same funciton but with a better method? QI-13: - what is the purpose of this function? What structure is the ExecPlan? Why do results have to come back as VOTable? There must be a more efficient way of passing data between DBMSs. Why do we need a portal url? All the 'nodes' should be other skynode services, shouldn't they? In which case, we only need their ResourceIDs to identify them? **surely all this is workflow functionality, rather than data query. If a query service can support cross-db querying then we just need the ADQL to reflect that** 6.: - this is not relevant to the data query service ==== Basically, I think we need an ADQL spec and a spec which states how to submit an ADQL query to a SkyNode (or SkyQuery service or whatever). The service will inherit from the interface of the basic IVOA service. The ADQL spec should include the optional capability to do multi-table and multi-db queries, region searches, cross-matching etc. The query service, in its metadata, needs to be able to identify which version of ADQL it can take and which capabilities of ADQL it supports (eg multi-table and xmatch but not multi-db and region search). Identifying all these features should be via namespaces with associated mini-specs. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Tony Linde > Sent: 14 January 2004 06:09 ... > > The document wraps too much into a single spec. VOQL has been > split out but this doc still contains Open SkyQuery Portal > which is inappropriate as an IVOA standard; we do not need a > portal standard. Even if we did, it should not be included in > the SkyNode spec. > > I understand the intention to present an architectural whole > but this could be done in a Note which cross-refers to the > individual specs. > > What is the intention of the SkyNode interface? Is it to be > the *only* way in which any VOQL query can be submitted? Does > every data query service have to implement this interface? If > not, what others are there and where do they fit in? > > Even the SkyNode interface wraps up too much: Wil has already > proposed a standard 'service' interface and I think this > needs to be worked on first before SkyNode can even be > considered. I think the SkyNode spec will then need to be > radically worked on before it can go forward even as a > proposed standard. From owner-voql@eso.org Thu Jan 15 12:49: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 i0FBlstK019536 for ; Thu, 15 Jan 2004 12:47:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FBlrP0019535 for voql-outgoing; Thu, 15 Jan 2004 12:47:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FBlktK019511 for ; Thu, 15 Jan 2004 12:47:46 +0100 (MET) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FBlit4024390 for ; Thu, 15 Jan 2004 12:47:44 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040115114744.CXWE22499.mta06-svc.ntlworld.com@gnowee> for ; Thu, 15 Jan 2004 11:47:44 +0000 From: "Tony Linde" To: Subject: SkyNodeInterface: DAL? Date: Thu, 15 Jan 2004 11:48:46 -0000 Organization: University of Leicester Message-ID: <00ac01c3db5d$88ae1f60$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <006501c3dab1$098e1980$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Quick point: shouldn't the SkyNodeInterface be proposed and discussed on the DAL list rather than here? Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Tony Linde > Sent: 14 January 2004 15:14 > To: 'Tony Linde'; 'Masatoshi OHISHI'; voql@ivoa.net > Subject: RE: SkyNodeInterface V0.6 > ... From owner-voql@eso.org Thu Jan 15 16:10:46 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 i0FF9WtK005629 for ; Thu, 15 Jan 2004 16:09:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FF9WSs005628 for voql-outgoing; Thu, 15 Jan 2004 16:09:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FF9TtK005608 for ; Thu, 15 Jan 2004 16:09:30 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FF9St4029614 for ; Thu, 15 Jan 2004 16:09:28 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.24) id 1Ah97f-0002UB-MM for voql@ivoa.net; Thu, 15 Jan 2004 15:09:27 +0000 Received: (qmail 8061 invoked from network); 15 Jan 2004 15:09:48 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 15 Jan 2004 15:09:48 -0000 Date: Thu, 15 Jan 2004 15:09:27 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Comments on ADQL-0.7 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I agree with most of Tony's comments. As the version number creeps towards the magic number 1.0 we really ought to make this look more like a specification, and not merely a casual description. The language used needs to be tightened up to make it clear what is required and what optional. If essential parts of the specification have to be given only in the form of .xsd files, then these also have to be referenced properly, with a URL to the master copy in some repository, and brought under version control. But I think that for the benefit of any astronomers who might be curious, it is extremely desirable that this document should also include a text description of the features of the SkyQL/ADQL language. Maybe this can be done by reference to an existing specification of SQL, e.g. the entry level of SQL92, I don't know? The list of functions is now identical to that in section 1 of appendix C of the JDBC-3.0 specification, as downloadable from http://java.sun.com/products/jdbc/index.jsp - maybe it's worth stating that? The schema diagrams are indeed illegible, and even than only show a very small part of the schema. I don't their presence adds much. A few paragraphs of text explaining the facilities in outline would be better. The REGION spec is also important, and again only referenced by an xml. Google found several versions for me, it's not clear which is the master. The only reference here is an example: Region('CIRCLE J2000 19.5 -36.7 0.02') The alternatives to CIRCLE need to be specified; as do the possible equinoxes as alternatives to J2000. I presume the other values are in degrees, but this is nowhere stated. This brings me on to another topic, what units are to be used by ADQL queries, and how do users (and software) find out? But I'll post something on that separately. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Thu Jan 15 18:06:25 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 i0FH5QtK004152 for ; Thu, 15 Jan 2004 18:05:26 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FH5QIs004151 for voql-outgoing; Thu, 15 Jan 2004 18:05:26 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FH5LtK004134 for ; Thu, 15 Jan 2004 18:05:21 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FH5KJX003297 for ; Thu, 15 Jan 2004 18:05:20 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.24) id 1AhAvn-0000Bk-Qi for voql@ivoa.net; Thu, 15 Jan 2004 17:05:19 +0000 Received: (qmail 20109 invoked from network); 15 Jan 2004 17:05:40 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 15 Jan 2004 17:05:40 -0000 Date: Thu, 15 Jan 2004 17:05:19 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Units needed in ADQL-0.7 In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: It seems to me (following valuable discussions with Guy Rixon, Patricio Ortiz, Tony Linde and others) that we cannot ignore the need for physical units in our queries. For example if one specifies (using SkyQL to avoid the verboseness of XML) something like: SELECT * FROM sometable t WHERE ABS(t.galactic_latitude) > 10.0 ; The meaning to an astronomer is fairly clear: you only want sources more than 10 degrees from the galactic plane. But how does the specifier, or the database access layer, know that 10.0 means degrees and not say radians or pixels? There are only two possibilities that I can think of: (a) the physical units for each column must be standardised so that everyone in the community knows that galactic latitude must be in degrees and any data centre using anything different has a mandatory permanent conversion job to do. or (b) we need a way of specifying units in the string (and in the XML). I think that (a) is too difficult, as there are just too many different columns and possible units, and argument as to what should be the "standard" would never cease. Using (b) we need a notation for units. The nearest thing to a standard notation that has so far been proposed is in section 3.2 of this document from CDS: http://vizier.u-strasbg.fr/doc/catstd.htx I think this looks a pretty good solution to the problem. Of course we still need a way of marking the syntax of the string in the pseudo-sql, for example in brackets, it would become SELECT * FROM sometable t WHERE ABS(t.galactic_latitude) > 10.0[deg] ; The data access layer at each site would have to interpret the units and do the appropriate conversion, so that if its table used radians, it would simply provide the conversion on the fly. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Thu Jan 15 18:57:39 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 i0FHujtK014371 for ; Thu, 15 Jan 2004 18:56:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FHujKv014370 for voql-outgoing; Thu, 15 Jan 2004 18:56:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FHuftK014346 for ; Thu, 15 Jan 2004 18:56:41 +0100 (MET) Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FHucJX004810 for ; Thu, 15 Jan 2004 18:56:39 +0100 (CET) Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id i0FHubGP002743; Thu, 15 Jan 2004 12:56:37 -0500 Message-ID: <4006D464.1080007@lheapop.gsfc.nasa.gov> Date: Thu, 15 Jan 2004 12:56:52 -0500 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page CC: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 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-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive Page wrote: ... > (a) the physical units for each column must be standardised so that > everyone in the community knows that galactic latitude must be in > degrees and any data centre using anything different has a mandatory > permanent conversion job to do. > > or > (b) we need a way of specifying units in the string (and in the XML). > > I think that (a) is too difficult, as there are just too many different > columns and possible units, and argument as to what should be the > "standard" would never cease. Using (b) we need a notation for units. > > The nearest thing to a standard notation that has so far been proposed is > in section 3.2 of this document from CDS: > http://vizier.u-strasbg.fr/doc/catstd.htx > I think this looks a pretty good solution to the problem. ... There is a standard string format for units defined in the second FITS WCS paper (e.g., http://www.edpsciences.org/articles/aa/pdf/2002/45/aah3859.pdf). Since this is nominally (or will soon be) an accepted astronomical standard that might be a better starting point for standard units string. However, I'm not convinced that standardized units might not be feasible. If we are able to convert units, why not convert them as we are sending queries onto the wire. So what flows over the wire is always in standard units. Otherwisee every site is faced with supporting transformations between every possible pair of compatible units rather than just between standard and local units. I think it makes the problem easier for everyone if we standardize units over the wire. query/local units for querier -> query/standard units -> query/local units for database response/local units for database -> response/standard units -> response/local units for querier While there are a lot of units used, I don't know that it would be too difficult to build a rule that gave the standard form of a unit given some non-standard form. Getting people to agree on one rule might be harder! Tom From owner-voql@eso.org Thu Jan 15 19:18:14 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 i0FIH6tK017116 for ; Thu, 15 Jan 2004 19:17:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FIH64K017115 for voql-outgoing; Thu, 15 Jan 2004 19:17:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FIH2tK017090 for ; Thu, 15 Jan 2004 19:17:02 +0100 (MET) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FIH0JX005199 for ; Thu, 15 Jan 2004 19:17:00 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040115181636.HNDI14639.mta03-svc.ntlworld.com@gnowee>; Thu, 15 Jan 2004 18:16:37 +0000 From: "Tony Linde" To: "'Thomas McGlynn'" , "'Clive Page'" Cc: Subject: RE: Units needed in ADQL-0.7 Date: Thu, 15 Jan 2004 18:17:26 -0000 Organization: University of Leicester Message-ID: <00be01c3db93$e4c33660$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 In-Reply-To: <4006D464.1080007@lheapop.gsfc.nasa.gov> 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 i0FIH5tK017112 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > query/local units for querier -> > query/standard units -> > query/local units for database > response/local units for database -> > response/standard units -> > response/local units for querier The registry entry for a data source (or rather for the service that fronts that source) will include the columns in that dataset and should include the units used for each column. When a user is sitting in front of a portal or query constructor and has targeted a data source, he/she can use the units of that source or some preferred units. The translation can then happen before the query is sent off to the data source so we don't need to worry about how the units are represented in the query. If the user wants to broadcast a query to a number of sources, they can use their preferred units and the portal or workflow engine can then translate each query into the appropriate units for each source. Thus we don't need to force every data centre to install conversion software and keep it up to date. This is only required by anyone constructing a portal, query constructor, workflow engine etc. - a much smaller number of sites and all with an interest in getting it right at the beginning of the VO revolution. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Thomas McGlynn > Sent: 15 January 2004 17:57 > To: Clive Page > Cc: voql@ivoa.net > Subject: Re: Units needed in ADQL-0.7 > > > Clive Page wrote: > > ... > > > (a) the physical units for each column must be standardised so that > > everyone in the community knows that galactic latitude must be in > > degrees and any data centre using anything different has a > mandatory > > permanent conversion job to do. > > > > or > > (b) we need a way of specifying units in the string (and in > the XML). > > > > I think that (a) is too difficult, as there are just too many > > different columns and possible units, and argument as to > what should > > be the "standard" would never cease. Using (b) we need a > notation for > > units. > > > > The nearest thing to a standard notation that has so far > been proposed > > is in section 3.2 of this document from CDS: > > http://vizier.u-strasbg.fr/doc/catstd.htx > > I think this looks a pretty good solution to the problem. > ... > There is a standard string format for units defined in the > second FITS WCS paper (e.g., > http://www.edpsciences.org/articles/aa/pdf/2002/45/aah3859.pdf ). Since this is nominally (or will soon be) an accepted astronomical standard that might be a better starting point for standard units string. However, I'm not convinced that standardized units might not be feasible. If we are able to convert units, why not convert them as we are sending queries onto the wire. So what flows over the wire is always in standard units. Otherwisee every site is faced with supporting transformations between every possible pair of compatible units rather than just between standard and local units. I think it makes the problem easier for everyone if we standardize units over the wire. query/local units for querier -> query/standard units -> query/local units for database response/local units for database -> response/standard units -> response/local units for querier While there are a lot of units used, I don't know that it would be too difficult to build a rule that gave the standard form of a unit given some non-standard form. Getting people to agree on one rule might be harder! Tom From owner-voql@eso.org Thu Jan 15 19:58:54 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 i0FIw2tK025696 for ; Thu, 15 Jan 2004 19:58:02 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FIw2Zx025695 for voql-outgoing; Thu, 15 Jan 2004 19:58:02 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FIvxtK025685 for ; Thu, 15 Jan 2004 19:57:59 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FIvvJX006199 for ; Thu, 15 Jan 2004 19:57:58 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0FIvtJ17357; Thu, 15 Jan 2004 13:57:55 -0500 Date: Thu, 15 Jan 2004 13:57:55 -0500 From: "Wil O'Mullane" To: Clive Page Cc: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 Message-ID: <20040115135755.L28523@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Thu, Jan 15, 2004 at 05:05:19PM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I saw this a 3rd way. Consider that the SkyNode spec tells you units of columns for each node so you know the units of 10 for any given node. Why should the node expect anything except the units it specified ? If you wish to send the same query to 10 nodes then you are either e.g. in a portal, it is your responsibility to make the unit conversions appropriately. Hence everyone may have their own units and units need never be specified in the query. Now what you are doing below could be done with a region specification and that has units built in and implies many conversions may need to be done but even there I have been discussing with Arnold how we might simplify or limit this for our work in progress.. On Thu, Jan 15, 2004 at 05:05:19PM +0000, Clive Page wrote: > It seems to me (following valuable discussions with Guy Rixon, Patricio > Ortiz, Tony Linde and others) that we cannot ignore the need for physical > units in our queries. For example if one specifies (using SkyQL to avoid > the verboseness of XML) something like: > > SELECT * FROM sometable t WHERE ABS(t.galactic_latitude) > 10.0 ; > > The meaning to an astronomer is fairly clear: you only want sources more > than 10 degrees from the galactic plane. But how does the specifier, or > the database access layer, know that 10.0 means degrees and not say > radians or pixels? There are only two possibilities that I can think of: > > (a) the physical units for each column must be standardised so that > everyone in the community knows that galactic latitude must be in > degrees and any data centre using anything different has a mandatory > permanent conversion job to do. > > or > (b) we need a way of specifying units in the string (and in the XML). > > I think that (a) is too difficult, as there are just too many different > columns and possible units, and argument as to what should be the > "standard" would never cease. Using (b) we need a notation for units. > > The nearest thing to a standard notation that has so far been proposed is > in section 3.2 of this document from CDS: > http://vizier.u-strasbg.fr/doc/catstd.htx > I think this looks a pretty good solution to the problem. > > Of course we still need a way of marking the syntax of the string in the > pseudo-sql, for example in brackets, it would become > > SELECT * FROM sometable t WHERE ABS(t.galactic_latitude) > 10.0[deg] ; > > The data access layer at each site would have to interpret the units and > do the appropriate conversion, so that if its table used radians, it would > simply provide the conversion on the fly. > > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Thu Jan 15 21:15: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 i0FKETtK022600 for ; Thu, 15 Jan 2004 21:14:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0FKETeb022599 for voql-outgoing; Thu, 15 Jan 2004 21:14:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0FKEOtM022557 for ; Thu, 15 Jan 2004 21:14:26 +0100 (MET) Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0FJOmt4006429 for ; Thu, 15 Jan 2004 20:24:49 +0100 (CET) Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id i0FJOlGP013761 for ; Thu, 15 Jan 2004 14:24:47 -0500 Message-ID: <4006E90E.8020706@lheapop.gsfc.nasa.gov> Date: Thu, 15 Jan 2004 14:25:02 -0500 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 References: <00be01c3db93$e4c33660$6124d28f@STAR.LE.AC.UK> In-Reply-To: <00be01c3db93$e4c33660$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony Linde wrote: >> query/local units for querier -> >> query/standard units -> >> query/local units for database >> response/local units for database -> >> response/standard units -> >> response/local units for querier > > > The registry entry for a data source (or rather for the service that fronts > that source) will include the columns in that dataset and should include the > units used for each column. > > When a user is sitting in front of a portal or query constructor and has > targeted a data source, he/she can use the units of that source or some > preferred units. The translation can then happen before the query is sent > off to the data source so we don't need to worry about how the units are > represented in the query. > > If the user wants to broadcast a query to a number of sources, they can use > their preferred units and the portal or workflow engine can then translate > each query into the appropriate units for each source. > > Thus we don't need to force every data centre to install conversion software > and keep it up to date. This is only required by anyone constructing a > portal, query constructor, workflow engine etc. - a much smaller number of > sites and all with an interest in getting it right at the beginning of the > VO revolution. > > Cheers, Not entirely sure whether you were disagreeing or agreeing... However, as I read the discussion, Clive was thinking that any unit conversion would occur at the database, while you are suggesting that the full unit conversion occur at the query originator site. In both these scenarios the implication is that the software at some local site is capable of converting units to any other (valid) units. In my scenario, each site is responsible only for the translation between their own local units and the standard set. It also means that the people who know the peculiarities of their units are responsible for taking care of those issues, not someone at another site which is what either Clive or your suggestion would require. Here's a contrived but not inconceivable example... Suppose our system stores fluxes in linear units in a certain range of fluxes and logarithmic units for larger values. If our system happens to be portal site, then Clive would seem to require remote databases to know about this when we send them queries. If our system happens to be a database, the Tony requires the portals to know about our peculiar system of units. Clearly it's much nicer if we alone need to handle this special case and don't burden other users. Another advantage to putting standard units on the wire is touched on in Tony's paper. Since the query is standardized it's easy to send it to multiple sites. Tony's proposal requires us to explicitly customize the query to each site. There are a lot of ancillary advantages to a nominal form. It's easy to store the query and re-issue it against new services that might be discovered later since the query syntax is not tied to its initial place of origin. It's much easier to discover if the query is the same as some other query for which results have been cached. It suggests to builders of new database systems and portals a framework to use for units. ... I don't think Tony's suggestion that the user reads the registry and then adjusts the query is appropriate. I'm certainly not competent to translate from janskies to magnitudes per square arcsecond. I guess a user could select databases that have familiar units, but this scenario of the user picking out resources individually isn't the real issue -- we can always punt to an interactive user. The hard problem is the one where we are trying to do things automagically on the user's behalf. If it is possible to put standardized units on the wire I think it would be an enormous win. However while I am not as pessimistic as Clive regarding its feasiblity, it may not be possible. If not then I don't really know whether it's better for the translations to be the responsibility of the portal/user site or the database. I'm not sure which we will have more of... Tom From owner-voql@eso.org Fri Jan 16 12:43:25 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 i0GBgriL022655 for ; Fri, 16 Jan 2004 12:42:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GBgr3G022654 for voql-outgoing; Fri, 16 Jan 2004 12:42:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GBgoiL022643 for ; Fri, 16 Jan 2004 12:42:50 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GBgmJX024600 for ; Fri, 16 Jan 2004 12:42:49 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.24) id 1AhSND-0006fx-Fj for voql@ivoa.net; Fri, 16 Jan 2004 11:42:47 +0000 Received: (qmail 4469 invoked from network); 16 Jan 2004 11:43:06 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 16 Jan 2004 11:43:06 -0000 Date: Fri, 16 Jan 2004 11:42:44 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 In-Reply-To: <4006E90E.8020706@lheapop.gsfc.nasa.gov> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think that what Tony is saying is that the AstroGrid model of how the VO works is like this (if I've got this wrong no doubt he will correct me): Every query from an astronomer using the VO has to go via a Portal and (though the astronomer need not know this) a Registry: direct access to data centers is not allowed, except wholly outside the VO. The user accesses a Portal to compose a query and does so using agreed standards for units: say degrees for all celestial coordinates, or milliarcseconds/year for proper motions, or Janskys for fluxes, or whatever we come up with; no doubt a good portal will support sexagesimals for RA/DEC. The Portal then fans this query out to one or more data centres and in each case does the appropriate translation, but not of the syntax only the units, since we have agreed to use ADQL. Of course if a Portal allows a power user to enter an SQL-like string query, this does have its syntax translated to the ADQL equivalent, along with the units conversions, but the current thinking in AstroGrid seems to be that queries will all be generated using drop-down lists and similar, in which the user can be notified of the column names allowed, and the units to be used in expressions. This translation is possible because the Registry is omniscient: it knows the units of every column in every table in every database of every data center in the VO world, it can therefore translate every numerical constant in every query to the units actually appropriate for each column. Since ADQL is only used for these translated queries, units are not needed in ADQL, provided we have agreed standards for them. The query parser obviously has to be quite good to work out, for each numerical constant, which column it is being applied to, and therefore the appropriate units conversion, but since we are translating SQL to XML form anyway, this may not be too difficult. The other aspect of the design is that it should be possible to send a query to more than one destination using UCDs rather than column names. The translation again being done by the Registry, upon request by the Portal. This requires us to define a standard set of units for each UCD, as at present UCDs and units have been carefully decoupled. The alternative model, of course, is that the same query is sent to each data center, and translated to specific JDBC/SQL locally, when both the syntax and the units are converted. This does require either standard units in each ADQL query, or a notation for specifying them. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Fri Jan 16 15:41: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 i0GEfIiL005709 for ; Fri, 16 Jan 2004 15:41:18 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GEfIxJ005705 for voql-outgoing; Fri, 16 Jan 2004 15:41:18 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GEfAiL005660 for ; Fri, 16 Jan 2004 15:41:11 +0100 (MET) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GEf8JX029303 for ; Fri, 16 Jan 2004 15:41:08 +0100 (CET) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 16 Jan 2004 06:41:06 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 16 Jan 2004 06:41:06 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 16 Jan 2004 06:41:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Units needed in ADQL-0.7 Date: Fri, 16 Jan 2004 06:41:03 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD44901F2036F@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Units needed in ADQL-0.7 Thread-Index: AcPcJ8BRUPh3VEOdSS+0xkwCyqrqNAAFc+lQ From: "Jim Gray" To: X-OriginalArrivalTime: 16 Jan 2004 14:41:06.0513 (UTC) FILETIME=[C609F410:01C3DC3E] 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 i0GEfFiL005680 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive: The registry will not know everything (as you postulate) about everyone, it will only know what it is told. Every column of every table in the registry does indeed carry a ucd that gives its units (among other things). The UCD model gives conversions among units (where conversion is possible). I assume most archives will have their own "portal" that gives direct access to the archive's data in the form it thinks best. So, there is no "exclusivity" of portals, that would not be workable. Archives can do whatever they want, but if they want to talk to the Portal we are implementing then they have to follow our rules. Queries involving data from multiple sources are teased apart by the portal and just the relevant parts are sent to each archive. SkQuery does not send the same query to every archive. We want it to be EASY to implement an archive and put most of the burden on the portal since they must deal with heterogeneity (and hence there are fewer of them). Jim Jim Gray Microsoft Research, Suite 1690, SF CA 94105, tel: 415 778 8222 fax: 425 706 7329 Gray@Microsoft.com http://research.Microsoft.com/~gray -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Clive Page Sent: Friday, January 16, 2004 3:43 AM To: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 I think that what Tony is saying is that the AstroGrid model of how the VO works is like this (if I've got this wrong no doubt he will correct me): Every query from an astronomer using the VO has to go via a Portal and (though the astronomer need not know this) a Registry: direct access to data centers is not allowed, except wholly outside the VO. The user accesses a Portal to compose a query and does so using agreed standards for units: say degrees for all celestial coordinates, or milliarcseconds/year for proper motions, or Janskys for fluxes, or whatever we come up with; no doubt a good portal will support sexagesimals for RA/DEC. The Portal then fans this query out to one or more data centres and in each case does the appropriate translation, but not of the syntax only the units, since we have agreed to use ADQL. Of course if a Portal allows a power user to enter an SQL-like string query, this does have its syntax translated to the ADQL equivalent, along with the units conversions, but the current thinking in AstroGrid seems to be that queries will all be generated using drop-down lists and similar, in which the user can be notified of the column names allowed, and the units to be used in expressions. This translation is possible because the Registry is omniscient: it knows the units of every column in every table in every database of every data center in the VO world, it can therefore translate every numerical constant in every query to the units actually appropriate for each column. Since ADQL is only used for these translated queries, units are not needed in ADQL, provided we have agreed standards for them. The query parser obviously has to be quite good to work out, for each numerical constant, which column it is being applied to, and therefore the appropriate units conversion, but since we are translating SQL to XML form anyway, this may not be too difficult. The other aspect of the design is that it should be possible to send a query to more than one destination using UCDs rather than column names. The translation again being done by the Registry, upon request by the Portal. This requires us to define a standard set of units for each UCD, as at present UCDs and units have been carefully decoupled. The alternative model, of course, is that the same query is sent to each data center, and translated to specific JDBC/SQL locally, when both the syntax and the units are converted. This does require either standard units in each ADQL query, or a notation for specifying them. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Fri Jan 16 16:02:23 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 i0GF1piL011342 for ; Fri, 16 Jan 2004 16:01:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GF1ooo011341 for voql-outgoing; Fri, 16 Jan 2004 16:01:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GF1NiL011181 for ; Fri, 16 Jan 2004 16:01:23 +0100 (MET) Received: from mail630.gsfc.nasa.gov (mail630.gsfc.nasa.gov [128.183.190.39]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GF1JJX029924 for ; Fri, 16 Jan 2004 16:01:20 +0100 (CET) Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id i0GF1HAM022757; Fri, 16 Jan 2004 10:01:17 -0500 Message-ID: <4007FE5E.6020403@gsfc.nasa.gov> Date: Fri, 16 Jan 2004 10:08:14 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page CC: voql@ivoa.net, "Wil O'Mullane" Subject: Re: Units needed in ADQL-0.7 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil, I thought that it would always be permissible for the user to form their query directly in ADQL. If so, then even just within the portal, the user needs to be able to specify units in ADQL. Also, it is not clear that the portal will know every place that a query will go. I can imagine a not too complicated query that first needs to go out to the grid for computation. Further breakdown of the query followed by several database queries all happening somewhere in the netherworld of the grid. Ed Clive Page wrote: >I think that what Tony is saying is that the AstroGrid model of how the VO >works is like this (if I've got this wrong no doubt he will correct me): > >Every query from an astronomer using the VO has to go via a Portal and >(though the astronomer need not know this) a Registry: direct access to >data centers is not allowed, except wholly outside the VO. The user >accesses a Portal to compose a query and does so using agreed standards >for units: say degrees for all celestial coordinates, or >milliarcseconds/year for proper motions, or Janskys for fluxes, or >whatever we come up with; no doubt a good portal will support sexagesimals >for RA/DEC. The Portal then fans this query out to one or more data >centres and in each case does the appropriate translation, but not of the >syntax only the units, since we have agreed to use ADQL. Of course if a >Portal allows a power user to enter an SQL-like string query, this does >have its syntax translated to the ADQL equivalent, along with the units >conversions, but the current thinking in AstroGrid seems to be that >queries will all be generated using drop-down lists and similar, in which >the user can be notified of the column names allowed, and the units to be >used in expressions. > >This translation is possible because the Registry is omniscient: it knows >the units of every column in every table in every database of every data >center in the VO world, it can therefore translate every numerical >constant in every query to the units actually appropriate for each column. >Since ADQL is only used for these translated queries, units are not >needed in ADQL, provided we have agreed standards for them. > >The query parser obviously has to be quite good to work out, for each >numerical constant, which column it is being applied to, and therefore the >appropriate units conversion, but since we are translating SQL to XML >form anyway, this may not be too difficult. > >The other aspect of the design is that it should be possible to send a >query to more than one destination using UCDs rather than column names. >The translation again being done by the Registry, upon request by the >Portal. This requires us to define a standard set of units for each UCD, >as at present UCDs and units have been carefully decoupled. > > >The alternative model, of course, is that the same query is sent to each >data center, and translated to specific JDBC/SQL locally, when both the >syntax and the units are converted. This does require either standard >units in each ADQL query, or a notation for specifying them. > > > > From owner-voql@eso.org Fri Jan 16 16:26: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 i0GFPriL017710 for ; Fri, 16 Jan 2004 16:25:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GFPrYa017709 for voql-outgoing; Fri, 16 Jan 2004 16:25:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GFPmiL017687 for ; Fri, 16 Jan 2004 16:25:49 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GFPlJX000730 for ; Fri, 16 Jan 2004 16:25:47 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.24) id 1AhVr0-0001pc-PD for voql@ivoa.net; Fri, 16 Jan 2004 15:25:46 +0000 Received: (qmail 21723 invoked from network); 16 Jan 2004 15:25:50 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 16 Jan 2004 15:25:50 -0000 Date: Fri, 16 Jan 2004 15:25:29 +0000 (GMT) From: Clive Page To: Jim Gray cc: voql@ivoa.net Subject: RE: Units needed in ADQL-0.7 In-Reply-To: <25603A6EFF8BA34AB2A49615383CD44901F2036F@RED-MSG-31.redmond.corp.microsoft.com> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 16 Jan 2004, Jim Gray wrote: > The registry will not know everything (as you postulate) about > everyone, it will only know what it is told. Of course; when I said "omniscient" I meant it purely in the VO context. It won't have my fingerprints, for example, (at least unless I visit the US with a passport issued after 2004 October 26, and there's some leakage of information out of some government's computers :-). The AstroGrid model does require any registry which is accessed by the user's chosen Portal to have, or be able to get hold of, all the necessary metadata about each table (units, UCD, etc) in the VO. Furthermore the translation from user query to SQL then takes place in at least three places: (1) from user language to ADQL in the Portal where, for example, physical units get converted, (2) from ADQL to JDBC/ODBC in the data access layer at the data center, where (3) from JDBC/ODBC to SQL inside the DBMS wrapper as usual. ADQL and SkyQL are then strictly just specifications for the transport layer, neither created directly by the user, nor used directly by the DBMS. That isn't stated explicitly in the document, and maybe it should be. I _think_ this model is a good one, and it does seem similar to that used at JHU for SkyServer etc. (if I understand things correctly), but not everyone seems to realise the implications for the design of the registry and the pivotal role it will play. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Fri Jan 16 16:59:13 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 i0GFwsiL025591 for ; Fri, 16 Jan 2004 16:58:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GFwsTH025590 for voql-outgoing; Fri, 16 Jan 2004 16:58:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GFwqiL025577 for ; Fri, 16 Jan 2004 16:58:52 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GFwnJX001674 for ; Fri, 16 Jan 2004 16:58:50 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 52D8D46092; Fri, 16 Jan 2004 15:58:49 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 5923; Fri, 16 Jan 2004 15:58:48 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7872546091; Fri, 16 Jan 2004 15:58:48 +0000 (GMT) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.109]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 7512746092; Fri, 16 Jan 2004 15:58:47 +0000 (GMT) Message-ID: <40080A37.5030304@dial.pipex.com> Date: Fri, 16 Jan 2004 15:58:47 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 References: <4007FE5E.6020403@gsfc.nasa.gov> In-Reply-To: <4007FE5E.6020403@gsfc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,USER_AGENT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: That's a fair point that the translation need not happen at the portal either. In fact I would see it much more likely to happen around whatever job/workflow step that will also be working out how and where to do joins, where best to gather results, etc. We *could* argue that if the user is submitting a query directly to a datacenter, then the user should use the datacenters units. On the other hand, it would be 'nice' if we could develop - once - libraries for datacenters so that users wouldn't have to care. And the datacenters will understand their own data units best. Which is basically the rub - the more functionality we put in the datacenter, the harder it may be for data owners to publish their data. And we want it to be *really easy* at least to begin with. I suggest: Add it as 'optional' in the ADQL schema for now. If no unit is given, the units of the column are assumed. We can then try out the conversion processes at various spots - and if any datacenter cannot handle the unit conversion in these early days, it can throw an exception or we can mark it in the metadata. Ed Shaya wrote: > Wil, > > I thought that it would always be permissible for the user to form their > query directly in ADQL. If so, then even just within the portal, the > user needs to be able to specify units in ADQL. > Also, it is not clear that the portal will know every place that a query > will go. I can imagine a not too complicated query that first needs to > go out to the grid for computation. Further breakdown of the query > followed by several database queries all happening somewhere in the > netherworld of the grid. > > Ed > > > Clive Page wrote: > >> I think that what Tony is saying is that the AstroGrid model of how >> the VO >> works is like this (if I've got this wrong no doubt he will correct me): >> >> Every query from an astronomer using the VO has to go via a Portal and >> (though the astronomer need not know this) a Registry: direct access to >> data centers is not allowed, except wholly outside the VO. The user >> accesses a Portal to compose a query and does so using agreed standards >> for units: say degrees for all celestial coordinates, or >> milliarcseconds/year for proper motions, or Janskys for fluxes, or >> whatever we come up with; no doubt a good portal will support >> sexagesimals >> for RA/DEC. The Portal then fans this query out to one or more data >> centres and in each case does the appropriate translation, but not of the >> syntax only the units, since we have agreed to use ADQL. Of course if a >> Portal allows a power user to enter an SQL-like string query, this does >> have its syntax translated to the ADQL equivalent, along with the units >> conversions, but the current thinking in AstroGrid seems to be that >> queries will all be generated using drop-down lists and similar, in which >> the user can be notified of the column names allowed, and the units to be >> used in expressions. >> >> This translation is possible because the Registry is omniscient: it knows >> the units of every column in every table in every database of every data >> center in the VO world, it can therefore translate every numerical >> constant in every query to the units actually appropriate for each >> column. >> Since ADQL is only used for these translated queries, units are not >> needed in ADQL, provided we have agreed standards for them. >> >> The query parser obviously has to be quite good to work out, for each >> numerical constant, which column it is being applied to, and therefore >> the >> appropriate units conversion, but since we are translating SQL to XML >> form anyway, this may not be too difficult. >> >> The other aspect of the design is that it should be possible to send a >> query to more than one destination using UCDs rather than column names. >> The translation again being done by the Registry, upon request by the >> Portal. This requires us to define a standard set of units for each UCD, >> as at present UCDs and units have been carefully decoupled. >> >> >> The alternative model, of course, is that the same query is sent to each >> data center, and translated to specific JDBC/SQL locally, when both the >> syntax and the units are converted. This does require either standard >> units in each ADQL query, or a notation for specifying them. >> >> >> >> > > -- Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Jan 16 17:07:41 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 i0GG7SiL027477 for ; Fri, 16 Jan 2004 17:07:28 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GG7Swp027476 for voql-outgoing; Fri, 16 Jan 2004 17:07:28 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GG7QiL027459 for ; Fri, 16 Jan 2004 17:07:26 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GG7Ot4029658 for ; Fri, 16 Jan 2004 17:07:24 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id C68C3460D4; Fri, 16 Jan 2004 16:07:23 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 7054; Fri, 16 Jan 2004 16:07:23 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 210BD460FA; Fri, 16 Jan 2004 16:07:23 +0000 (GMT) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.109]) by kintyre.roe.ac.uk (Postfix) with ESMTP id ABB15460D4; Fri, 16 Jan 2004 16:07:22 +0000 (GMT) Message-ID: <40080C3A.1020309@dial.pipex.com> Date: Fri, 16 Jan 2004 16:07:22 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: Units needed in ADQL-0.7 References: <25603A6EFF8BA34AB2A49615383CD44901F2036F@RED-MSG-31.redmond.corp.microsoft.com> In-Reply-To: <25603A6EFF8BA34AB2A49615383CD44901F2036F@RED-MSG-31.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.5 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Jim Gray wrote: > The registry will not know everything (as you postulate) about > everyone, it will only know what it is told. > Every column of every table in the registry does indeed carry a ucd > that gives its units (among other things). > The UCD model gives conversions among units (where conversion is > possible). Unfortunately the UCDs don't actually give us units. For example, the UCD POS_RA_MAIN can have associated values in degrees (and they can be in dd mm ss.s or decimal) or radians. And one of the big arguments surrounding UCDs at the moment is that even when combined with units, this may not be enough for converting between magnitudes & fluxes. > > I assume most archives will have their own "portal" that gives direct > access to the archive's data in the form it thinks best. > So, there is no "exclusivity" of portals, that would not be workable. > Archives can do whatever they want, but if they want to talk to the > Portal we are implementing then they have to follow our rules. We are hoping to do this the other way around - if we give our archives common interfaces, then many different portals can access them all. I don't envisage any datacenters talking to portals... or? > > Queries involving data from multiple sources are teased apart by the > portal and just the relevant parts are sent to each archive. I see the portal as just being the UI, and there will be many services behind it that will handle the grid-side workflows and assignments, and this might be the place to do the appropriate translations. But maybe this is what you call the portal? > SkQuery does not send the same query to every archive. > We want it to be EASY to implement an archive and put most of the > burden on the portal since they must deal with heterogeneity (and hence > there are fewer of them). Yes - datacenters should be easy to implement as these are going to be different every instance. Whereas the layers that use the datacenters are likely to be lots of instances of the same (or very few) applications, so we can build the conversions into that once. But - is it really possible to build generic unit converters in the astronomical world? Martin -- Martin Hill www.astrogrid.org > > Jim > > Jim Gray > Microsoft Research, Suite 1690, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Clive > Page > Sent: Friday, January 16, 2004 3:43 AM > To: voql@ivoa.net > Subject: Re: Units needed in ADQL-0.7 > > I think that what Tony is saying is that the AstroGrid model of how the > VO works is like this (if I've got this wrong no doubt he will correct > me): > > Every query from an astronomer using the VO has to go via a Portal and > (though the astronomer need not know this) a Registry: direct access to > data centers is not allowed, except wholly outside the VO. The user > accesses a Portal to compose a query and does so using agreed standards > for units: say degrees for all celestial coordinates, or > milliarcseconds/year for proper motions, or Janskys for fluxes, or > whatever we come up with; no doubt a good portal will support > sexagesimals for RA/DEC. The Portal then fans this query out to one or > more data centres and in each case does the appropriate translation, but > not of the syntax only the units, since we have agreed to use ADQL. Of > course if a Portal allows a power user to enter an SQL-like string > query, this does have its syntax translated to the ADQL equivalent, > along with the units conversions, but the current thinking in AstroGrid > seems to be that queries will all be generated using drop-down lists and > similar, in which the user can be notified of the column names allowed, > and the units to be used in expressions. > > This translation is possible because the Registry is omniscient: it > knows the units of every column in every table in every database of > every data center in the VO world, it can therefore translate every > numerical constant in every query to the units actually appropriate for > each column. > Since ADQL is only used for these translated queries, units are not > needed in ADQL, provided we have agreed standards for them. > > The query parser obviously has to be quite good to work out, for each > numerical constant, which column it is being applied to, and therefore > the appropriate units conversion, but since we are translating SQL to > XML form anyway, this may not be too difficult. > > The other aspect of the design is that it should be possible to send a > query to more than one destination using UCDs rather than column names. > The translation again being done by the Registry, upon request by the > Portal. This requires us to define a standard set of units for each > UCD, as at present UCDs and units have been carefully decoupled. > > > The alternative model, of course, is that the same query is sent to each > data center, and translated to specific JDBC/SQL locally, when both the > syntax and the units are converted. This does require either standard > units in each ADQL query, or a notation for specifying them. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > -- Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Jan 16 18:24: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 i0GHNiiL010963 for ; Fri, 16 Jan 2004 18:23:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GHNiGU010961 for voql-outgoing; Fri, 16 Jan 2004 18:23:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GHNWiL010903 for ; Fri, 16 Jan 2004 18:23:32 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GHNUt4001451 for ; Fri, 16 Jan 2004 18:23:31 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 78B8E4603B; Fri, 16 Jan 2004 17:23:30 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 15828; Fri, 16 Jan 2004 17:23:30 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C5EAA45E81; Fri, 16 Jan 2004 17:23:29 +0000 (GMT) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.109]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 86E9F4603B; Fri, 16 Jan 2004 17:23:23 +0000 (GMT) Message-ID: <40081E0A.3040507@dial.pipex.com> Date: Fri, 16 Jan 2004 17:23:22 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: ADQL simplified Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=1000.0 tests=USER_AGENT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'm working on a simpler ADQL that is less verbose and so easier for humans and tools to process. However I wanted to check first, is there a particular reason why values are so fully (and somewhat redundantly) specified? eg 3 rather than just (or indeed ) Would anyone have any objections to removing these redundant nested tags? Or point out which wrong end of the stick I'm holding? Cheers, Martin -- Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Jan 16 19:32: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 i0GIVxiL021169 for ; Fri, 16 Jan 2004 19:31:59 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0GIVx0Y021168 for voql-outgoing; Fri, 16 Jan 2004 19:31:59 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0GIVuiL021159 for ; Fri, 16 Jan 2004 19:31:56 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0GIVst4002952 for ; Fri, 16 Jan 2004 19:31:55 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0GIVk703008; Fri, 16 Jan 2004 13:31:46 -0500 Date: Fri, 16 Jan 2004 13:31:46 -0500 From: "Wil O'Mullane" To: Martin Hill Cc: voql@ivoa.net Subject: Re: ADQL simplified Message-ID: <20040116133146.D30657@skysrv.pha.jhu.edu> References: <40081E0A.3040507@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40081E0A.3040507@dial.pipex.com>; from mchill@dial.pipex.com on Fri, Jan 16, 2004 at 05:23:22PM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: My understanding of what was wanted from ADQL was a Parse tree for computers to work with. Not something human readable. We took a BNF for SQL changed it a little and fed it through Visual Parse to generate a Parser for the language. The then took classes from the parser and generated XSD for those. SO it is a completely automatic process which leaves in some redundancy but does make for much consistency.. Now that is assuming we wanted a parse tree.. wil On Fri, Jan 16, 2004 at 05:23:22PM +0000, Martin Hill wrote: > I'm working on a simpler ADQL that is less verbose and so easier for humans and > tools to process. However I wanted to check first, is there a particular reason > why values are so fully (and somewhat redundantly) specified? eg > 3 values fully? > > As far as I can tell, specifying type (ie integer, string or real) offers no > extra checking in practice, as we can't tell what types the columns are that are > being compared with (and it would be hard to validate anyway). Also, it doesn't > match the way that numbers are used in the Region schema. And we lose this > information when we convert backwards and forwards to the SQL-like string format > - or is this no longer considered important? > > Similarly with the functions - we have eg > rather than just (or indeed ) > > Would anyone have any objections to removing these redundant nested tags? Or > point out which wrong end of the stick I'm holding? > > Cheers, > > Martin > > > > -- > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > From owner-voql@eso.org Mon Jan 19 00:26: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 i0INQJKC003304 for ; Mon, 19 Jan 2004 00:26:19 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0INQJ7H003303 for voql-outgoing; Mon, 19 Jan 2004 00:26:19 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0INQFKC003293 for ; Mon, 19 Jan 2004 00:26:15 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0INQDJX014538 for ; Mon, 19 Jan 2004 00:26:13 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i0INQCm7009637; Sun, 18 Jan 2004 23:26:12 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i0INQCuM009636; Sun, 18 Jan 2004 23:26:12 GMT Received: from 81.86.221.91 ( [81.86.221.91]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Sun, 18 Jan 2004 23:26:12 +0000 Message-ID: <1074468372.400b161461319@netmail.pipex.net> Date: Sun, 18 Jan 2004 23:26:12 +0000 From: martin hill To: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: ADQL simplified References: <40081E0A.3040507@dial.pipex.com> <20040116133146.D30657@skysrv.pha.jhu.edu> In-Reply-To: <20040116133146.D30657@skysrv.pha.jhu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 81.86.221.91 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thanks for the history! I remember ADQL/XML was originally going to be a machine-only language. However now that we're using it, we're finding that in practice it's useful to work with it directly as well. Partly it is just that while testing and prototyping it's easier to work with directly as the ADQL/String -> ADQL/XML translations are not wholly reliable yet*. But also I think there may be a human place for it, as it can be validated directly (so errors can be reported meaningfully to the user) and we can write tools more easily I think to handle the XML structure than the SQL one. But yes we definitely need to make sure ADQL/XML is still defined so that the maximum number of XML tools can be used to process/generate/edit it. Cheers, Martin *How do the ADQL String->XML translators make type decisions with the existing structure - eg how does a statement like 'WHERE X > 2' get translated when '2' might be a real or integer, or even a string...? Quoting Wil O'Mullane : > My understanding of what was wanted from ADQL was a Parse tree for > computers to work with. Not something human readable. > We took a BNF for SQL changed it a little and fed it through > Visual Parse to generate a Parser for the language. > The then took classes from the parser and generated XSD for those. > SO it is a completely automatic process which leaves in some redundancy > but does make for much consistency.. > > Now that is assuming we wanted a parse tree.. > > wil > > On Fri, Jan 16, 2004 at 05:23:22PM +0000, Martin Hill wrote: > > I'm working on a simpler ADQL that is less verbose and so easier for humans > and > > tools to process. However I wanted to check first, is there a particular > reason > > why values are so fully (and somewhat redundantly) specified? eg > > 3 specify the > > values fully? > > > > As far as I can tell, specifying type (ie integer, string or real) offers > no > > extra checking in practice, as we can't tell what types the columns are > that are > > being compared with (and it would be hard to validate anyway). Also, it > doesn't > > match the way that numbers are used in the Region schema. And we lose this > > > information when we convert backwards and forwards to the SQL-like string > format > > - or is this no longer considered important? > > > > Similarly with the functions - we have eg > > > rather than just (or indeed ) > > > > Would anyone have any objections to removing these redundant nested tags? > Or > > point out which wrong end of the stick I'm holding? > > > > Cheers, > > > > Martin > > > > > > > > -- > > Software Engineer > > AstroGrid @ ROE > > Tel: +44 7901 55 24 66 > > www.astrogrid.org > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Mon Jan 19 10:06:04 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 i0J95TKC028734 for ; Mon, 19 Jan 2004 10:05:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0J95TFg028724 for voql-outgoing; Mon, 19 Jan 2004 10:05:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0J95OKC028700 for ; Mon, 19 Jan 2004 10:05:24 +0100 (MET) Received: from artemis.le.ac.uk (ntp2c.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0J95Mt4017105 for ; Mon, 19 Jan 2004 10:05:23 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.24) id 1AiVLV-0007Xb-Vf for voql@ivoa.net; Mon, 19 Jan 2004 09:05:21 +0000 Received: (qmail 9360 invoked from network); 19 Jan 2004 09:05:42 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 19 Jan 2004 09:05:42 -0000 From: "Tony Linde" To: Subject: RE: ADQL simplified Date: Mon, 19 Jan 2004 09:06:26 -0000 Organization: University of Leicester Message-ID: <003c01c3de6b$849bdd20$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 In-Reply-To: <20040116133146.D30657@skysrv.pha.jhu.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/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i0J95SKC028719 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: That does explain the structure, Wil. But do we need parsing relationships in the specification of the language itself? It seems a bit like mixing the schema and data for an xml document. (This *is* a genuine question, not a criticism: I am far from being knowledgeable about language design.) May be worth looking at the definition of XQueryX (http://www.w3.org/TR/xqueryx/). There does seem to be a lot of parsing info in the actual language spec: an expression () contains a forClause, whereClause and returnClause. But it doesn't go down to the level of specifying that the Expr contains a ExprSingle which then contains a FLWORExpr (at http://www.w3.org/TR/xquery/#nt-bnf see definitions [40], [41], [42]). So maybe there is a case for pruning the parsing constructs a little. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 16 January 2004 18:32 > To: Martin Hill > Cc: voql@ivoa.net > Subject: Re: ADQL simplified > > > My understanding of what was wanted from ADQL was a Parse > tree for computers to work with. Not something human > readable. We took a BNF for SQL changed it a little and fed > it through Visual Parse to generate a Parser for the > language. The then took classes from the parser and generated > XSD for those. SO it is a completely automatic process which > leaves in some redundancy but does make for much consistency.. > > Now that is assuming we wanted a parse tree.. > > wil > > On Fri, Jan 16, 2004 at 05:23:22PM +0000, Martin Hill wrote: > > I'm working on a simpler ADQL that is less verbose and so > easier for > > humans and > > tools to process. However I wanted to check first, is > there a particular reason > > why values are so fully (and somewhat redundantly) specified? eg > > 3 it just to specify the > > values fully? > > > > As far as I can tell, specifying type (ie integer, string or real) > > offers no > > extra checking in practice, as we can't tell what types the > columns are that are > > being compared with (and it would be hard to validate > anyway). Also, it doesn't > > match the way that numbers are used in the Region schema. > And we lose this > > information when we convert backwards and forwards to the > SQL-like string format > > - or is this no longer considered important? > > > > Similarly with the functions - we have eg > > > > rather than just (or indeed ) > > > > Would anyone have any objections to removing these redundant nested > > tags? Or > > point out which wrong end of the stick I'm holding? > > > > Cheers, > > > > Martin > > > > > > > > -- > > Software Engineer > > AstroGrid @ ROE > > Tel: +44 7901 55 24 66 > > www.astrogrid.org > > > From owner-voql@eso.org Thu Jan 22 04:47:51 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 i0M3lRli011360 for ; Thu, 22 Jan 2004 04:47:27 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0M3lRdi011359 for voql-outgoing; Thu, 22 Jan 2004 04:47:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0M3lOli011346 for ; Thu, 22 Jan 2004 04:47:24 +0100 (MET) Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0M3lLWR015722 for ; Thu, 22 Jan 2004 04:47:22 +0100 (CET) Received: from lepus.tuc.noao.edu (dtody [209.155.156.44]) by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i0M3lJoB017497; Wed, 21 Jan 2004 20:47:19 -0700 Date: Wed, 21 Jan 2004 20:47:14 -0700 (MST) From: Doug Tody X-X-Sender: dtody@lepus.tuc.noao.edu To: Tony Linde cc: voql@ivoa.net Subject: Re: SkyNodeInterface: DAL? In-Reply-To: <00ac01c3db5d$88ae1f60$6124d28f@STAR.LE.AC.UK> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo) 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-voql@eso.org Precedence: bulk Reply-To: Doug Tody X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 15 Jan 2004, Tony Linde wrote: > Quick point: shouldn't the SkyNodeInterface be proposed and discussed on the > DAL list rather than here? The plan is for the new DAL catalog access interface (replacement for cone search) to be based on ADQL. ADQL is being developed by the VOQL WG. It is appropriate to do some service prototyping as part of the VOQL development, but when we get to the point of specifying a new interface for basic catalog access to supplant cone search, then yes this should be proposed and discussed within DAL, and integrated with the other DAL services. Doug From owner-voql@eso.org Fri Jan 23 18:04:52 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 i0NH4NgK006042 for ; Fri, 23 Jan 2004 18:04:23 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0NH4Nqr006040 for voql-outgoing; Fri, 23 Jan 2004 18:04:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0NH4IgK006015 for ; Fri, 23 Jan 2004 18:04:18 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0NFbUEY006480 for ; Fri, 23 Jan 2004 16:37:31 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0NFbUC04995 for voql@ivoa.net; Fri, 23 Jan 2004 10:37:30 -0500 Date: Fri, 23 Jan 2004 10:37:30 -0500 From: "Wil O'Mullane" To: voql@ivoa.net Subject: New SkyNode and ADQL - reply to many emails (esp. Tony) Message-ID: <20040123103730.A4059@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: New ADQL and SkyNode spec have been posted on twiki .. http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL Please note links to the Skynode WSDL and ADQL XSD are also there. Tony & Clive had many questions and issues - I try to deal with each below. You may or may not wish to read all of it . You have been warned.. SKYNODE +++++++++++ SINGLE SPEC- Too wide in scope --- All agreed too much was in the original spec. This is now split into ADQL and SkyNode. Recently The Standard Interfaces Spec has been made available. So section 4 is replaced with a single requirement referencing the standard interfaces spec. The portal part indeed should also be removed. The Architecture sections says enough and the Portal sections should be put in a new Portal spec coming latter. So Section 6 goes. >What is the intention of the SkyNode interface? Is it to be the *only* way >in which any VOQL query can be submitted? Does every data query service have >to implement this interface? If not, what others are there and where do they >fit in? The intention for SkyNode Spec was as a standard way to accept and ADQL query (not VOQL) . Almost certainly it would not be the only way but it would be standard way. Many people already want to implement this interface but there is no standard so I don't think we should not do anything about it for now - it should move forward. This is meant to be a step on from Cone service - a little more useful. >- is the basic/full distinction valid? What if a basic service can return a >QueryCost: how is this specified? The functions that a query service can >perform should be in the metadata; they should each be namespaced and >versioned with their own specs (which might be part of this one). I think this is valid - in another one of your mails you ask that we state what is the minimum a node needs to do to be IVOA - that is BASIC. The document goes on to describe other desirable features to enable portals to do more advanced queries. Any particular node code exist anywhere in the spectrum. I have added text to clarify this. >5.2.1: >QI-3: >- we need a better way of signifying features than is extensible and does >not require hard-coding of metadata in the registry xsd. But this is what the metadata is for is it not. Granted though Xmatch and Region may be in the functions list but the accepts UCDS really has no other place unless it is done using a translation function like findColNameForUCD. I happily remove the other two but think we need to keep AcceptsUCDS. >QI-4/5/6...: >- these ports need to be better specified or is this in the wsdl? What is >the format of the return data? Xml? If so, we need a validating xsd. Yes they are specified in the WSDL which was the intention. I shall post the WSDL alongside the next version of the DOC. >- Tables, Columns, Formats and Functions are/should be part of the metadata >and so do not need separate calls. There well long discussions on this also at several meetings and the only solution I could see was to stick to the skyquery way of doing things. If you want this metadata in the registry you go back and get it from each call. The Resource Metadata only contains the description of the node and the base url. >QI-8: >- don't understand this. Is this saying that one query can return the data >in multiple formats or just that a query can specify the format (*should be >from a namespaced list*) it wants the data returned in? what do the abstract >class and subclasses mean? Are these Java classes or XSD classes? The formats are listed by a call to the Formats interface. I am assuming a string token- formats gives you a list of strings you give back one. You get your result in that one format. The subclasses are detailed in the WSDL. Extra text added about QueryCost >QI-12: >- this seems to wrap several functions which are better split out: the >ability to *create* a table and populate it (whether via VOTable or via some >other ADQL query); the ability to Xmatch. If this function is saying that >VOTable and some query result can be cross-matched without loading the the >VOTable as a db table, how is this supposed to be done? Are the calculations >provided the *only* way of doing XMatching? What if someone wants to provide >the same funciton but with a better method? This is the part which I had said needed more work in Decemeber and why I suggested perhaps delaying this spec going forward for recommendation. Theoretically yes you may do any Xmatch you like. How you do the Xmatch is your decision. We will load the table in a temporary space and then perform the Xmatch. This is and Exec plan are purely for OpenSkyQuery. >QI-13: >- what is the purpose of this function? What structure is the ExecPlan? Why >do results have to come back as VOTable? There must be a more efficient way >of passing data between DBMSs. Why do we need a portal url? All the 'nodes' >should be other skynode services, shouldn't they? In which case, we only >need their ResourceIDs to identify them? >**surely all this is workflow functionality, rather than data query. If a >query service can support cross-db querying then we just need the ADQL to >reflect that** As stated above this is ofr OpenSkyQuery - this is the way SkyQuery currently works and it has been bough in here also. Yes this is work flow. I am not sure I want to turn every node into a portal though. SkyQuery broke this apart nicely and this spec attempts to do the same. There is a minimum a node needs to do the portal does all the really nasty parts. ADQL ++++++++ Reference added to region specification - no spec actually available yet. >ADQL-2: >- this illustrates my point. If the xsd IS the standard then we don't need >to state this, if not, then all the other aspects of the ADQL also deserve >explanation. I am unsure a truly exhaustive document is useful here. There is a premise that we are based on SQL. The document tries to detail where we are tighter or differ from SQL . This is surly more useful than an exhaustive SQL description where inevitably subtleties would be lost. Perhaps we need a new ADQL-1 ADQL shall be based on SQL. >ADQL-6 Added more text to clarify version and its meaning. >The REGION spec is also important, and again only referenced by an xml. >Google found several versions for me, it's not clear which is the master. >The only reference here is an example: > Region('CIRCLE J2000 19.5 -36.7 0.02') AH! There was a reference to HTMDLL which seems to have disappeared ! The current Parser only deals with Circle this will be remedied in the near future. SKYQL. -- Tony suggests dropping this term. I think this would be fine so in place of SKYQL we simply have ADQL string representation. ALL -> Is there any Consensus opinion on that ?? >ADQL-8/9/10: >- this is confusing and suggests that SkyQL is different to ADQL. Why do we >need all this description? There was extensive discussion on how to include regions in the Text representation. These iterate the ways in which this may be done. I would not remove them without saying this in some other way. UNITS We had some discussion in NVO about this. We feel this may be added to ADQL later if needed. For now it will bring more problems than solutions. We feel we should continue with ADQL as is for the near term Phew ... wil From owner-voql@eso.org Tue Jan 27 01:21:59 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 i0R0LWHe029705 for ; Tue, 27 Jan 2004 01:21:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0R0LWn2029704 for voql-outgoing; Tue, 27 Jan 2004 01:21:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0R0LTHe029690 for ; Tue, 27 Jan 2004 01:21:29 +0100 (MET) Received: from argo.act.cmis.CSIRO.AU (argo.act.cmis.CSIRO.AU [152.83.72.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0R0LRWR009686 for ; Tue, 27 Jan 2004 01:21:28 +0100 (CET) Received: from saab-bt.act.cmis.csiro.au (saab-bt.act.cmis.CSIRO.AU [152.83.70.2]) by argo.act.cmis.CSIRO.AU (Postfix) with ESMTP id 25A5C28503 for ; Tue, 27 Jan 2004 11:21:12 +1100 (EST) Received: by saab-bt.act.cmis.CSIRO.AU with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 11:21:12 +1100 Message-ID: <57C87AAEA6B0BC479B69F110575ECCCF09AFEC@saab-bt.act.cmis.CSIRO.AU> From: Robert.Power@csiro.au To: voql@ivoa.net Subject: RE: ADQL simplified Date: Tue, 27 Jan 2004 11:21:12 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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-voql@eso.org Precedence: bulk Reply-To: Robert.Power@csiro.au X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Martin, This was from a while ago, but a couple of queries re your simplified ADQL: Why can't we tell what the types are of the columns? I would have thought this could be determined (from the registry or if being performed at the data centre, some other portal specific way). If this information is available, then the type of literals should be preserved in the ADQL query and type checking performed. Similarly for functions. is an aggregate function and so can only be used in this context. This is assuming that the translation of ADQL to SQL should be "smart" (does type checking, syntax checking etc). If this is not the case, just blindly converts ADQL to SQL, then if the generated SQL is wrong (due to a problem with the original ADQL query) then there is an SQL error reported further down the line and user/tool will have to deal with this. I personally prefer a "non-blind" approach where as much checking is done when converting the ADQL to SQL, but that's just me. This doesn't mean it can't be trimmed, but I would like the level of information to be preserved. Rob > -----Original Message----- > From: Martin Hill [mailto:mchill@dial.pipex.com] > Sent: Saturday, January 17, 2004 4:23 AM > To: voql@ivoa.net > Subject: ADQL simplified > > I'm working on a simpler ADQL that is less verbose and so easier for > humans and > tools to process. However I wanted to check first, is there a particular > reason > why values are so fully (and somewhat redundantly) specified? eg > 3 specify the > values fully? > > As far as I can tell, specifying type (ie integer, string or real) offers > no > extra checking in practice, as we can't tell what types the columns are > that are > being compared with (and it would be hard to validate anyway). Also, it > doesn't > match the way that numbers are used in the Region schema. And we lose > this > information when we convert backwards and forwards to the SQL-like string > format > - or is this no longer considered important? > > Similarly with the functions - we have eg > > rather than just (or indeed ) > > Would anyone have any objections to removing these redundant nested tags? > Or > point out which wrong end of the stick I'm holding? > > Cheers, > > Martin > > > > -- > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org From owner-voql@eso.org Tue Jan 27 10:48:50 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 i0R9luHe012310 for ; Tue, 27 Jan 2004 10:47:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0R9ltBt012302 for voql-outgoing; Tue, 27 Jan 2004 10:47:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0R9laHe012180 for ; Tue, 27 Jan 2004 10:47:37 +0100 (MET) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0R9lYWR025106 for ; Tue, 27 Jan 2004 10:47:35 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by pengo.systems.pipex.net (Postfix) with ESMTP id DAE164C01379; Tue, 27 Jan 2004 09:47:33 +0000 (GMT) Message-ID: <40163360.800@dial.pipex.com> Date: Tue, 27 Jan 2004 09:46: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: Robert.Power@csiro.au Cc: voql@ivoa.net Subject: Re: ADQL simplified References: <57C87AAEA6B0BC479B69F110575ECCCF09AFEC@saab-bt.act.cmis.CSIRO.AU> In-Reply-To: <57C87AAEA6B0BC479B69F110575ECCCF09AFEC@saab-bt.act.cmis.CSIRO.AU> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Robert Hmmm didn't think of that. At the moment there is not in fact any column-based type information; and as you say we could add it, but it's not straightforward. It means that any SQL-like string should include a reference to the datacenter/registry entry it is expected to run on, so doing the SQL/ADQL -> XML/ADQL translation can be done. There's a fair amount of extra (programming) work doing the transformation & validation, to include the lookup, and we need to allow for not finding the registry entry. We could add this as an *extra* validation somewhere... Or we could get datacenters to publish their own ADQL schema to validate against. This datacenter-ADQL would have to be like the ordinary one but with the extra type info included - does anyone do/know of anyone who does this kind of derivation? Sounds like it might be useful for other things. (In fact at the moment the type is usually derived from the way the number is specified: 2 is an integer, 2.0 is a real, '2' is a string). As for functions, etc, where we want to specify that a value must be a number, we can do this in the schema so that the values are restricted. So a schema might include (I think, without reference book to hand): to allow us a simpler document element like this, that only takes real numbers as arguments: 2.234 Which satisfies my usual criteria: it's simple to read and write, and easy to decode when parsed! Cheers, Martin Robert.Power@csiro.au wrote: > Hi Martin, > > This was from a while ago, but a couple of queries re > your simplified ADQL: > > Why can't we tell what the types are of the columns? > I would have thought this could be determined (from the > registry or if being performed at the data centre, some > other portal specific way). If this information is > available, then the type of literals should be preserved > in the ADQL query and type checking performed. > > Similarly for functions. is an aggregate function > and so can only be used in this context. > > This is assuming that the translation of ADQL to SQL > should be "smart" (does type checking, syntax checking etc). > If this is not the case, just blindly converts ADQL to SQL, > then if the generated SQL is wrong (due to a problem with > the original ADQL query) then there is an SQL error reported > further down the line and user/tool will have to deal > with this. > > I personally prefer a "non-blind" approach where as much > checking is done when converting the ADQL to SQL, but > that's just me. > > This doesn't mean it can't be trimmed, but I would like the > level of information to be preserved. > > Rob > > >>-----Original Message----- >>From: Martin Hill [mailto:mchill@dial.pipex.com] >>Sent: Saturday, January 17, 2004 4:23 AM >>To: voql@ivoa.net >>Subject: ADQL simplified >> >>I'm working on a simpler ADQL that is less verbose and so easier for >>humans and >>tools to process. However I wanted to check first, is there a particular >>reason >> why values are so fully (and somewhat redundantly) specified? eg >>3>specify the >>values fully? >> >>As far as I can tell, specifying type (ie integer, string or real) offers >>no >>extra checking in practice, as we can't tell what types the columns are >>that are >>being compared with (and it would be hard to validate anyway). Also, it >>doesn't >>match the way that numbers are used in the Region schema. And we lose >>this >>information when we convert backwards and forwards to the SQL-like string >>format >>- or is this no longer considered important? >> >>Similarly with the functions - we have eg >> >>rather than just (or indeed ) >> >>Would anyone have any objections to removing these redundant nested tags? >>Or >>point out which wrong end of the stick I'm holding? >> >>Cheers, >> >>Martin >> >> >> >>-- >>Software Engineer >>AstroGrid @ ROE >>Tel: +44 7901 55 24 66 >>www.astrogrid.org > > From owner-voql@eso.org Tue Jan 27 23:56:20 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 i0RMu5DO027590 for ; Tue, 27 Jan 2004 23:56:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0RMu5IT027585 for voql-outgoing; Tue, 27 Jan 2004 23:56:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0RMu3DO027577 for ; Tue, 27 Jan 2004 23:56:03 +0100 (MET) Received: from argo.act.cmis.CSIRO.AU (argo.act.cmis.CSIRO.AU [152.83.72.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0RMu0WR007614 for ; Tue, 27 Jan 2004 23:56:01 +0100 (CET) Received: from saab-bt.act.cmis.csiro.au (saab-bt.act.cmis.CSIRO.AU [152.83.70.2]) by argo.act.cmis.CSIRO.AU (Postfix) with ESMTP id 7542B28504; Wed, 28 Jan 2004 09:55:59 +1100 (EST) Received: by saab-bt.act.cmis.CSIRO.AU with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 09:55:58 +1100 Message-ID: <57C87AAEA6B0BC479B69F110575ECCCF09AFF5@saab-bt.act.cmis.CSIRO.AU> From: Robert.Power@csiro.au To: mchill@dial.pipex.com Cc: voql@ivoa.net Subject: RE: ADQL simplified Date: Wed, 28 Jan 2004 09:55:57 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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-voql@eso.org Precedence: bulk Reply-To: Robert.Power@csiro.au X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, I'm making an analogy with SQL: select from where By specifying a particular table(s), the types of the columns can be determined either locally at the portal or via the registry. When you mention the query will " ... include a reference to the datacenter/registry entry it is expected to run on ", I'm assuming that since the ADQL will reference a particular table (VOResource) then its description should be same regardless at which data centre it as at (the same table might be replicated at various data centres). So the column based type information need not be included in the ADQL itself, but it can be determined during query processing (ADQL->SQL). Perhaps this is too much effort and a barrier to entry to be required for all portal developers, but it could be an extra capability. Rob > -----Original Message----- > From: Martin Hill [mailto:mchill@dial.pipex.com] > Sent: Tuesday, January 27, 2004 8:46 PM > To: Robert.Power@csiro.au > Cc: voql@ivoa.net > Subject: Re: ADQL simplified > > Hi Robert > > Hmmm didn't think of that. > > At the moment there is not in fact any column-based type information; > and as you say we could add it, but it's not straightforward. It means > that any SQL-like string should include a reference to the > datacenter/registry entry it is expected to run on, so doing the > SQL/ADQL -> XML/ADQL translation can be done. There's a fair amount of > extra (programming) work doing the transformation & validation, to > include the lookup, and we need to allow for not finding the registry > entry. We could add this as an *extra* validation somewhere... Or we > could get datacenters to publish their own ADQL schema to validate > against. This datacenter-ADQL would have to be like the ordinary one > but with the extra type info included - does anyone do/know of anyone > who does this kind of derivation? Sounds like it might be useful for > other things. > > (In fact at the moment the type is usually derived from the way the > number is specified: 2 is an integer, 2.0 is a real, '2' is a string). > > As for functions, etc, where we want to specify that a value must be a > number, we can do this in the schema so that the values are restricted. > So a schema might include (I think, without reference book to hand): > > > > to allow us a simpler document element like this, that only takes real > numbers as arguments: > > 2.234 > > Which satisfies my usual criteria: it's simple to read and write, and > easy to decode when parsed! > > Cheers, > > Martin > > > > > Robert.Power@csiro.au wrote: > > Hi Martin, > > > > This was from a while ago, but a couple of queries re > > your simplified ADQL: > > > > Why can't we tell what the types are of the columns? > > I would have thought this could be determined (from the > > registry or if being performed at the data centre, some > > other portal specific way). If this information is > > available, then the type of literals should be preserved > > in the ADQL query and type checking performed. > > > > Similarly for functions. is an aggregate function > > and so can only be used in this context. > > > > This is assuming that the translation of ADQL to SQL > > should be "smart" (does type checking, syntax checking etc). > > If this is not the case, just blindly converts ADQL to SQL, > > then if the generated SQL is wrong (due to a problem with > > the original ADQL query) then there is an SQL error reported > > further down the line and user/tool will have to deal > > with this. > > > > I personally prefer a "non-blind" approach where as much > > checking is done when converting the ADQL to SQL, but > > that's just me. > > > > This doesn't mean it can't be trimmed, but I would like the > > level of information to be preserved. > > > > Rob > > > > > >>-----Original Message----- > >>From: Martin Hill [mailto:mchill@dial.pipex.com] > >>Sent: Saturday, January 17, 2004 4:23 AM > >>To: voql@ivoa.net > >>Subject: ADQL simplified > >> > >>I'm working on a simpler ADQL that is less verbose and so easier for > >>humans and > >>tools to process. However I wanted to check first, is there a > particular > >>reason > >> why values are so fully (and somewhat redundantly) specified? eg > >>3 >>specify the > >>values fully? > >> > >>As far as I can tell, specifying type (ie integer, string or real) > offers > >>no > >>extra checking in practice, as we can't tell what types the columns are > >>that are > >>being compared with (and it would be hard to validate anyway). Also, it > >>doesn't > >>match the way that numbers are used in the Region schema. And we lose > >>this > >>information when we convert backwards and forwards to the SQL-like > string > >>format > >>- or is this no longer considered important? > >> > >>Similarly with the functions - we have eg > >> > >>rather than just (or indeed ) > >> > >>Would anyone have any objections to removing these redundant nested > tags? > >>Or > >>point out which wrong end of the stick I'm holding? > >> > >>Cheers, > >> > >>Martin > >> > >> > >> > >>-- > >>Software Engineer > >>AstroGrid @ ROE > >>Tel: +44 7901 55 24 66 > >>www.astrogrid.org > > > > From owner-voql@eso.org Wed Jan 28 01:23:38 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 i0S0JMDO007072 for ; Wed, 28 Jan 2004 01:19:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0S0JMV3007071 for voql-outgoing; Wed, 28 Jan 2004 01:19:22 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0S0JKDO007060 for ; Wed, 28 Jan 2004 01:19:20 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0S0JIEY020443 for ; Wed, 28 Jan 2004 01:19:18 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0S0J9O22383; Tue, 27 Jan 2004 19:19:09 -0500 Date: Tue, 27 Jan 2004 19:19:09 -0500 From: "Wil O'Mullane" To: Robert.Power@csiro.au Cc: voql@ivoa.net Subject: Re: ADQL simplified Message-ID: <20040127191909.X10420@skysrv.pha.jhu.edu> References: <57C87AAEA6B0BC479B69F110575ECCCF09AFF5@saab-bt.act.cmis.CSIRO.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <57C87AAEA6B0BC479B69F110575ECCCF09AFF5@saab-bt.act.cmis.CSIRO.AU>; from Robert.Power@csiro.au on Wed, Jan 28, 2004 at 09:55:57AM +1100 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > When you mention the query will " ... include a reference > to the datacenter/registry entry it is expected to run on ", > I'm assuming that since the ADQL will reference a particular > table (VOResource) then its description should be same regardless > at which data centre it as at (the same table might be > replicated at various data centres). To follow your SQL analogy you would assume that a table named X was the same in any SQL database. This is probably not a particularly fair assumption. ADQL allows for an alias representing the archive to appear in front of the table name. There is noting in the ADQL spec as of now to force to destination of the query to be in the query. I do not think that is a necessary or good idea. It seems however some people feel ADQL will linger and they will be unable to know what it was meant to do and what the types of the columns were without know where it was intended to go to. > > So the column based type information need not be included > in the ADQL itself, but it can be determined during query > processing (ADQL->SQL). Correct - each NODE publishes its type info and the assumption is the ADQL coming to it is in the correct types and UNITS! But since SQL is as typeless as ADQL I fail to see what extra processing you have to do here. From owner-voql@eso.org Wed Jan 28 19:35: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 i0SIZEDO026230 for ; Wed, 28 Jan 2004 19:35:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0SIZEpF026229 for voql-outgoing; Wed, 28 Jan 2004 19:35:14 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0SIZADO026209 for ; Wed, 28 Jan 2004 19:35:10 +0100 (MET) Received: from kintyre.roe.ac.uk (kintyre.roe.ac.uk [195.194.120.72]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0SIZ8WR001665 for ; Wed, 28 Jan 2004 19:35:08 +0100 (CET) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by kintyre.roe.ac.uk (Postfix) with ESMTP id D587145C88; Wed, 28 Jan 2004 18:35:07 +0000 (GMT) Received: from somehost by kintyre.roe.ac.uk (postfixilter 1.3) with SMTP id 7252; Wed, 28 Jan 2004 18:35:07 +0000 (GMT) Received: from kintyre.roe.ac.uk (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2733C45CE3; Wed, 28 Jan 2004 18:35:07 +0000 (GMT) Received: from dial.pipex.com (IFA19P.roe.ac.uk [195.194.122.57]) by kintyre.roe.ac.uk (Postfix) with ESMTP id 9604145C88; Wed, 28 Jan 2004 18:35:06 +0000 (GMT) Message-ID: <401800D9.1050209@dial.pipex.com> Date: Wed, 28 Jan 2004 18:35:05 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" Cc: Robert.Power@csiro.au, voql@ivoa.net Subject: Re: ADQL simplified not - Column typing References: <57C87AAEA6B0BC479B69F110575ECCCF09AFF5@saab-bt.act.cmis.CSIRO.AU> <20040127191909.X10420@skysrv.pha.jhu.edu> In-Reply-To: <20040127191909.X10420@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.9 required=1000.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,USER_AGENT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'm confused... easily done... Certainly, if we're doing the type checking at the datacenter backend, where the ADQL is being parsed for meaning (whether to convert to SQL to submit to an RDBMS, or for other searches on other data types) then it's 'too late' to worry about typing, as that will occur naturally at that stage. I was thinking there might be a case (a long time down the line so this is a bit pie in the sky just now) where type information on columns could be made available to the ADQL validator. This would mean (presumably) some kind of restricted ADQL schema based on a combination of the normal ADQL schema and the registry information _on the particular datacenter the ADQL will be applied to_ . You could restrict not just types but also names of columns, tables, etc.... Hmmmm... So any such specific ADQL query would need to have a reference to the datacenter it is being applied to - or rather, the restricted schema for that datacenter. If there are mirrors or similar datacenters, I suppose one ought to be able to lookup all datacenters that will take that schema.... As I say, this may be some time off! But I'm wondering now whether being able to generate such a restricted, data-center specific ADQL schema for a datacenter would help us build fancy GUI pick-from-list ADQL query-generating tools... Hmmm Martin Wil O'Mullane wrote: >>When you mention the query will " ... include a reference >>to the datacenter/registry entry it is expected to run on ", >>I'm assuming that since the ADQL will reference a particular >>table (VOResource) then its description should be same regardless >>at which data centre it as at (the same table might be >>replicated at various data centres). > > To follow your SQL analogy you would assume that a table named > X was the same in any SQL database. > This is probably not a particularly fair assumption. > > ADQL allows for an alias representing the archive to appear in > front of the table name. > > There is noting in the ADQL spec as of now to force to destination of the > query to be in the query. I do not think that is a necessary or > good idea. It seems however some people feel ADQL will linger and > they will be unable to know what it was meant to do and what the > types of the columns were without know where it was intended to go to. > >>So the column based type information need not be included >>in the ADQL itself, but it can be determined during query >>processing (ADQL->SQL). > > Correct - each NODE publishes its type info and the assumption is > the ADQL coming to it is in the correct types and UNITS! > > But since SQL is as typeless as ADQL I fail to see what extra processing you have to do here. > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Thu Jan 29 10:47:33 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 i0T9lFOG022715 for ; Thu, 29 Jan 2004 10:47:15 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0T9lFUI022714 for voql-outgoing; Thu, 29 Jan 2004 10:47:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0T9lCOG022705 for ; Thu, 29 Jan 2004 10:47:12 +0100 (MET) Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0T9lAWR012025 for ; Thu, 29 Jan 2004 10:47:11 +0100 (CET) Received: from star1.jb.man.ac.uk ([130.88.24.176]) by gannet.scg.man.ac.uk with esmtp (Exim 4.20) id 1Am8lS-000KSn-IN for voql@ivoa.net; Thu, 29 Jan 2004 09:47:10 +0000 Received: from [130.88.24.80] (helo=aten) by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2) id 1Am8lS-0001sI-00 for voql@ivoa.net; Thu, 29 Jan 2004 09:47:10 +0000 Date: Thu, 29 Jan 2004 09:47:10 +0000 (GMT) From: Anita Richards X-X-Sender: amsr@aten To: voql@ivoa.net Subject: Re: ADQL simplified Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1Am8lS-000KSn-IN*lAtR21XLcPk* 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-voql@eso.org Precedence: bulk Reply-To: Anita Richards X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > (In fact at the moment the type is usually derived from the way the > number is specified: 2 is an integer, 2.0 is a real, '2' is a string). A comment from a 'user' point of view: This seems a sensible rule of thumb, similarly if one encountered an expression "thing > 2" or even "thing > stuff" it should be assumed that 2 was a number not a string, and "stuff" was a string variable representing a number (as was "thing") (that also assumes that numbers can't be string variables ... ). However assumptions/defaults should only be applied as a last resort (however they are then invaluable....) Here's why I think it is a last resort: We need a way to tell the difference between ONE (ehex for some large number), ONE (string) and 1 Some languages require values ie numbers to be in "" in some cases. Moreover, it is very dangerous to assume that 2 is an integer if that can lead to a round number aquiring a definition as an integer and then being used in a language like fortran where 1.27389/2 can give a result different from 1.27389/2.0 (this may not be a real example but you see what I mean). The question of how much specification can affect precision is already a troublesome issue for VO tools. Example 1: Aladin/AVO-Aladin, especially ACE, does not transport data with enough precision to measure and plot position with milli-arcsec accuracy. Example 2: Whilst the datacube renderer was being developed there were stages when positions only known to e.g. 1 arcmin were given to an arbitrary and excessive number of d.p. What I am saying in a confused way, I think, is that 1) Information should not be lost. If it is _known_ (e.g. from service provider) that a number is a (why is Value twice? by the way...) then we should keep all the baggage. 2) If information is not given, then any assumptions have to be applied with great care. e.g. 2 is assumed to be a number but it is safer to leave the type unspecified and make sure that if an application is expecting a real, it gets 2.0 (but not 2.0000000 or 1.99999985457965478007 etc....). Perl is the most intelligent language I have come across in this respect and might have some good things to copy if we need? But probably you guys know much more sophisticated ways. 3) This probably goes beyond the ADQL remit and should be passed on to people wrapping tools and to the Registry as the implications are really for how we validate and manipulate data. 4) The issue for astronomer queries is, how much can we guide the querier to express a query sensibly (e.g. don't use numbers as string variables!), how much can be done by checking and reporting apparent errors in input queries, how can we guide the querier to ask for an appropriate precision explicitly if needed, and how can we report accuracy. I don't mean the accuracy of the data in the sense of instrumental position errors etc. (although that has to be included), I mean being able to decide whether a query needs double precision, or avoiding falling into traps like using a full Julian day as an integer 2451516 for tools that can't handle long integers, or using decimal radians and single precision for milli-arccsec positions - or using 32-bit arithmetic and replies when only arcmin precision is needed. Cheers a - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Anita M. S. Richards, AVO Astronomer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax). From owner-voql@eso.org Thu Jan 29 16:03:14 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 i0TEwCpg003815 for ; Thu, 29 Jan 2004 15:58:12 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0TEwCWM003801 for voql-outgoing; Thu, 29 Jan 2004 15:58:12 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0TEvqpg003699 for ; Thu, 29 Jan 2004 15:57:52 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0TEvnEY011011 for ; Thu, 29 Jan 2004 15:57:50 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0TEvnb32044 for voql@ivoa.net; Thu, 29 Jan 2004 09:57:49 -0500 Date: Thu, 29 Jan 2004 09:57:49 -0500 From: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: ADQL simplified Message-ID: <20040129095749.T10420@skysrv.pha.jhu.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from amsr@jb.man.ac.uk on Thu, Jan 29, 2004 at 09:47:10AM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > What I am saying in a confused way, I think, is that > > 1) Information should not be lost. If it is _known_ (e.g. from service > provider) that a number is a > > (why is Value twice? by the way...) > then we should keep all the baggage. Again I must reiterate. The call/agreement for ADQL was a parse tree for SQL strings. As user I should hope you would never see the XML representation but would use the string representation. In which case you would like to say select * from stars where mag < 15.5 The current ADQL parse will simply parse this according to SQL gramme and give you the tokens. Perhaps when people asked for a parse tree they expected something else ? The notion was to give something pre parsed to the node so node developers did not have to develop SQL parsers. Not that users should construct such documents. Portals perhaps from screens and forms but not users. > > 2) If information is not given, then any assumptions have to be applied > with great care. e.g. 2 is assumed to be a number but it is safer to > leave the type unspecified and make sure that if an application is > expecting a real, it gets 2.0 (but not 2.0000000 or > 1.99999985457965478007 etc....). Perl is the most intelligent language I > have come across in this respect and might have some good things to copy > if we need? But probably you guys know much more sophisticated ways. When transmitting data I can see this being an issue. In a query I do not see a problem with the SQL approach. The value on the right 15.5 above will have to be coercible to the type of the column on the left. As you point out Perl is very good at this type of coercion - so are most databases. > From owner-voql@eso.org Sat Jan 31 16:34:43 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 i0VFTudt006950 for ; Sat, 31 Jan 2004 16:29:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0VFTuZc006949 for voql-outgoing; Sat, 31 Jan 2004 16:29:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@eso.org using -f From: Noel Winstanley Organization: Jodrell Bank Observatory To: Martin Hill Subject: ADQL - it aint so great Date: Fri, 30 Jan 2004 15:46:25 +0000 User-Agent: KMail/1.5.4 In-Reply-To: <401A4AB2.1000109@dial.pipex.com> Cc: voql@ivoa.net MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200401301546.25998.nw@jb.man.ac.uk> 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 Sender: owner-voql@eso.org Precedence: bulk Reply-To: Noel Winstanley X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Bah! I tried and I failed. I can;t get any joy with the latest version of ADQL. I had to hunt for the two sub-schemas it relies on - they're not pointed to from the adql webpage. only 2 results for each in google - so not exactly popular! I managed to generate code from the ADQL schema using Castor, after editing it to define a targetNamespace, and to point at the sub-schemas. The generated code compiles up properly, which is something. Then I needed some test documents to exercise the code with. I thought it would be a simple matter to take the test documents I have for a previous version of adql, and make a few changes. Errm, no. They've added even more superfluous tags. In the simpler cases, I managed to work out from the schema what extra verbage I had to add. Note that the schema has _no_ documentation, and the specification contains no useful description. There are diagrams, but again, no text describing what it all means. So I had a bright idea - use the sql-adql translator web service to generate the test documents. At least this service working now - but it generates a different, incompatible version of ADQL to that given in the schema. Gah. >From what I can tell, the translator generates the latest version of ADQL, while the downloadable schema is a bit out of date. There's so many faults here - no version information or namespacing in the generated adql; - no version information or namespacing in the schema; - no schema in the specification document!!! so its just waffle, nothing concrete, and the real schema lags behind. Then there's the design decision that 'adql is just a representation of the parse tree of sql' and the oft-repeated statement on the mailing list that users should never see ADQL. Well, I'm a developer, and I need to see ADQL. I'd just like to know what it means. The specification is inadequate - it should contain an annotated xml schema, (maybe defining a new namespace for each version). The specification should also define the semantics of ADQL, probably as a translation between sql and adql, and vice versa. At the moment, it is simpler and more correct just to pass SQL to a service - parsers for most languages already exist that will process SQL., and the tokens of sql language has a defined meaning. ADQL has lacks this. It seems baroquely complicated to translate from [Sky|S]QL at the user end to ADQL on the wire, and back to (probably) SQL at the service end. Why not just pass SQL straight through? I'm really beginning to wonder whether ADQL is the most suitable query language for astrogrid datacenters. What are its benefits? right. I've vented my spleen. I'm knocking off for the weekend. noel On Friday 30 Jan 2004 12:14 pm, you wrote: > Excellent thanks. I think you can pretty much copy the old cone search > over - we don't need to worry too much yet about making it spot on as I > think Clive P is still working on that. > > I shall be off this afternoon & this weekend (TA), back on Monday. > > Thanks! > > Martin > > Noel Winstanley wrote: > > Hi martin, > > Its a bit of work, but shouldn't be too much trouble. After all we've > > solved the problem already for one version of the language - so hopefully > > there shouldn't be any new invention required for this on. > > > > I'll give it a go this afternoon. > > > > It'll involve using castor to generate a new object model (in a fresh set > > of packages). > > > > then taking the translation rules for the existing adql, and adapting a > > copy of them for the new language. > > > > then adding another translator to the plugins, that can handle this new > > version of adql. there'll need to be a new namespace defined, etc. > > > > so I can get the bulk of it done quickly. there'll probalby need to be > > some tweaks done later - like implementing the region / cone searches -- > > needs an astronomer to do this. > > > > so I reckon I can get it cracked today, with tidying up next week. > > > > On Friday 30 Jan 2004 11:42 am, you wrote: > >>Hi Noel > >> > >>Depending on how much of a loose end you're at, would you be able to do a > >>translator for the v0.6 ADQL? That is, for the current schema at > >>http://skyservice.pha.jhu.edu/develop/vo/adql/doc/ADQLSchema.xsd ? I'm > >>being a bit slow on the simplifying schema front (partly cos of all this > >>pontificating on the mailing lists which have gone ominously quiet > >> today!). Also though I think it may take some time to get it approved, > >> and in the meantime people are starting to use the query boxes you > >> created. I've added a link to an SQL->ADQL translator on that page, but > >> of course the translator gives the wrong version of ADQL for us! > >> > >>If you can do it, how long do you think it will take? > >> > >>Cheers, > >> > >>Martin -- Dr Noel Winstanley - nw@jb.man.ac.uk 01477 572689 Senior Java Developer, Astrogrid Project. Jodrell Bank Observatory, University of Manchester. From owner-voql@eso.org Sat Jan 31 17:45: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 i0VGeGdt013696 for ; Sat, 31 Jan 2004 17:40:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0VGeGX0013695 for voql-outgoing; Sat, 31 Jan 2004 17:40:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0VGeEdt013687 for ; Sat, 31 Jan 2004 17:40:14 +0100 (MET) Received: from apollo.le.ac.uk (mailsend.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0VGeDWR029238 for ; Sat, 31 Jan 2004 17:40:13 +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 1AmyAF-0006eW-V3 for voql@ivoa.net; Sat, 31 Jan 2004 16:40:11 +0000 Received: (qmail 18306 invoked from network); 31 Jan 2004 16:40:32 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 31 Jan 2004 16:40:32 -0000 Date: Sat, 31 Jan 2004 16:40:11 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: ADQL - it aint so great In-Reply-To: <200401301546.25998.nw@jb.man.ac.uk> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 30 Jan 2004, Noel Winstanley wrote: > I tried and I failed. > > I can;t get any joy with the latest version of ADQL. > I'm really beginning to wonder whether ADQL is the most suitable query > language for astrogrid datacenters. What are its benefits? I agree with your comments, Noel, and I've been asking for some time why we need ADQL. The only answer I was able to get was that it made the checking of the query simpler and improves security. I am not convinced that we need to be all that fussy in checing syntax: if the user generates the query from our menu-style registry-driven portal then it will be hard to make a syntax mistake; power users who generate their own SQL by typing it into a text box will find out soon enough if they make a mistake: any DBMS parses the query and returns an error message instantly. The experience of JHU with their skyserver was given at the last ADASS meeting by Wil O'Mullane: indeed he made a mistake in his live demo and got a message back, allowing him to correct it. This isn't a perfectly user-friendly system, but it seems adequate to me. As far as security goes, a simple solution initially is to restrict the first keyword of any query to be SELECT, and in particular prevent non-authenticated users from issuing DROP or DELETE statements. Later, maybe, we can allow things like CREATE TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard even without ADQL. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Sat Jan 31 20:31:18 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 i0VJR6dt000712 for ; Sat, 31 Jan 2004 20:27:06 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i0VJR6Jp000706 for voql-outgoing; Sat, 31 Jan 2004 20:27:06 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i0VJR3dt000669 for ; Sat, 31 Jan 2004 20:27:04 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i0VJQvWR004951 for ; Sat, 31 Jan 2004 20:26:58 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i0VJQuC08054 for voql@ivoa.net; Sat, 31 Jan 2004 14:26:56 -0500 Date: Sat, 31 Jan 2004 14:26:56 -0500 From: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: ADQL - it aint so great Message-ID: <20040131142656.A7886@skysrv.pha.jhu.edu> References: <200401301546.25998.nw@jb.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Sat, Jan 31, 2004 at 04:40:11PM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Personally I also do not feel we need an XML form of ADQL. But at IVOA meetings there was a general request to have ADQL in XML format. I made a stab at and XML format. Modified it etc ... This of course may be discussed again at the meeting. Even internal to SkyServer there is some parsing going on as Clive suggests. People generally felt having a parsed version would help in this area. We are aware of some of the problems mentioned especially with java. Vivek is currently working on this and I believe will post some new tutorials etc in the coming days. wil On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > I tried and I failed. > > > > I can;t get any joy with the latest version of ADQL. > > > I'm really beginning to wonder whether ADQL is the most suitable query > > language for astrogrid datacenters. What are its benefits? > > I agree with your comments, Noel, and I've been asking for some time why > we need ADQL. The only answer I was able to get was that it made the > checking of the query simpler and improves security. I am not convinced > that we need to be all that fussy in checing syntax: if the user generates > the query from our menu-style registry-driven portal then it will be hard > to make a syntax mistake; power users who generate their own SQL by typing > it into a text box will find out soon enough if they make a mistake: any > DBMS parses the query and returns an error message instantly. The > experience of JHU with their skyserver was given at the last ADASS meeting > by Wil O'Mullane: indeed he made a mistake in his live demo and got a > message back, allowing him to correct it. This isn't a perfectly > user-friendly system, but it seems adequate to me. As far as security > goes, a simple solution initially is to restrict the first keyword of any > query to be SELECT, and in particular prevent non-authenticated users from > issuing DROP or DELETE statements. Later, maybe, we can allow things like > CREATE TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard > even without ADQL. > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Sun Feb 1 11:31: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 i11ARMjV024122 for ; Sun, 1 Feb 2004 11:27:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i11ARMvp024121 for voql-outgoing; Sun, 1 Feb 2004 11:27:22 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i11ARJjV024107 for ; Sun, 1 Feb 2004 11:27:19 +0100 (MET) Received: from apollo.le.ac.uk (mailsend.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i11ARHWR029787 for ; Sun, 1 Feb 2004 11:27:17 +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 1AnEot-0004Pg-UO for voql@ivoa.net; Sun, 01 Feb 2004 10:27:15 +0000 Received: (qmail 11326 invoked from network); 1 Feb 2004 10:27:35 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 1 Feb 2004 10:27:35 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" Cc: Subject: RE: ADQL - it aint so great Date: Sun, 1 Feb 2004 10:28:27 -0000 Message-ID: <004701c3e8ae$217a1bb0$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 In-Reply-To: <20040131142656.A7886@skysrv.pha.jhu.edu> 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/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Personally I also do not feel we need an XML form of ADQL. > But at IVOA meetings there was a general request to have ADQL > in XML format. I made a stab at and XML format. Modified it I still think we need the xml version. Astronomy includes values which are not simple scalars; representing structures even as simple as a polar coordinate is messy in a textual language. As we add more complex features/funcitons to ADQL we don't want to have to invent text equivalents of vectors, arrays and more complex structured values. An xml document is also easier to construct from user selections in a query screen and much easier to translate into the many variants of SQL (and OQL and ...) that are used in astronomical repositories since you don't have to deconstruct the textual version first. Personally I'd drop the textual version of ADQL - if anyone wants to type the query in textual form, provide a pass-through option so they can type the end repository's SQL query (or whatever language it requires). (If they want the same query to go to multiple databases then they either construct ADQL using whatever portal front end they prefer or they type all the queries in manually.) Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 31 January 2004 19:27 > Cc: voql@ivoa.net > Subject: Re: ADQL - it aint so great > > > Personally I also do not feel we need an XML form of ADQL. > But at IVOA meetings there was a general request to have ADQL > in XML format. I made a stab at and XML format. Modified it > etc ... This of course may be discussed again at the meeting. > Even internal to SkyServer there is some parsing going on as Clive > suggests. People generally felt having a parsed version would > help in this area. > > > We are aware of some of the problems mentioned especially with > java. Vivek is currently working on this and I believe will > post some new tutorials etc in the coming days. > > > wil > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > I tried and I failed. > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > query language for astrogrid datacenters. What are its benefits? > > > > I agree with your comments, Noel, and I've been asking for > some time > > why we need ADQL. The only answer I was able to get was > that it made > > the checking of the query simpler and improves security. I am not > > convinced that we need to be all that fussy in checing > syntax: if the > > user generates the query from our menu-style registry-driven portal > > then it will be hard to make a syntax mistake; power users who > > generate their own SQL by typing it into a text box will > find out soon > > enough if they make a mistake: any DBMS parses the query > and returns > > an error message instantly. The experience of JHU with their > > skyserver was given at the last ADASS meeting by Wil > O'Mullane: indeed > > he made a mistake in his live demo and got a message back, allowing > > him to correct it. This isn't a perfectly user-friendly > system, but > > it seems adequate to me. As far as security goes, a simple > solution > > initially is to restrict the first keyword of any query to > be SELECT, > > and in particular prevent non-authenticated users from > issuing DROP or > > DELETE statements. Later, maybe, we can allow things like CREATE > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard > > even without ADQL. > > > > > > -- > > Clive Page > > Dept of Physics & Astronomy, > > University of Leicester, Tel +44 116 252 3551 > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > From owner-voql@eso.org Mon Feb 2 16:29: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 i12FSc9Z017977 for ; Mon, 2 Feb 2004 16:28:38 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i12FScQc017974 for voql-outgoing; Mon, 2 Feb 2004 16:28:38 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i12FSL9Z017913 for ; Mon, 2 Feb 2004 16:28:22 +0100 (MET) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i12FSFWR028994 for ; Mon, 2 Feb 2004 16:28:16 +0100 (CET) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 2 Feb 2004 07:28:13 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Feb 2004 07:28:12 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 07:29:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ADQL - Careful what you wish for Date: Mon, 2 Feb 2004 07:28:09 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD44902180539@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADQL - Careful what you wish for Thread-Index: AcPosXcDIFiwt4SVReafgMBu8ylZOwA7M/8Q From: "Jim Gray" To: "Tony Linde" , "Wil O'Mullane" Cc: X-OriginalArrivalTime: 02 Feb 2004 15:29:52.0858 (UTC) FILETIME=[674C83A0:01C3E9A1] 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 i12FSX9Z017946 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: sage advice: As one who has watched language designers struggle for many years with languages like Fortran, VisiCalc, SQL, and HTML, I have learned that it is not an occupation for dilettantes like us. So, to the extent that you can hijack an existing language like SQL, do it. There are no "minor" changes to these languages; they all have any tight interconnections. Adding XML data in the middle of some language is non trivial. If you really love XML, you might look at xQuery, but it has rather poor implementations so far, and it lacks update/inset/delete; and some describe the language as "ugly" . The Sky Query folks extended the table names with an extra level of qualification and added a function (cross match). That was safe and easy. I recommend you try to use SQL's built in extension mechanisms. It you really! want to do language design, do not couple that research with the main path of the VO effort. It would make a fine side-project for the computer science guys -but it should not be on the critical path for the VO Jim Gray Microsoft Research, Suite 1690, 455 Market, SF CA 94105, tel: 415 778 8222 fax: 425 706 7329 Gray@Microsoft.com http://research.Microsoft.com/~gray -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Tony Linde Sent: Sunday, February 01, 2004 2:28 AM To: 'Wil O'Mullane' Cc: voql@ivoa.net Subject: RE: ADQL - it aint so great > Personally I also do not feel we need an XML form of ADQL. > But at IVOA meetings there was a general request to have ADQL in XML > format. I made a stab at and XML format. Modified it I still think we need the xml version. Astronomy includes values which are not simple scalars; representing structures even as simple as a polar coordinate is messy in a textual language. As we add more complex features/funcitons to ADQL we don't want to have to invent text equivalents of vectors, arrays and more complex structured values. An xml document is also easier to construct from user selections in a query screen and much easier to translate into the many variants of SQL (and OQL and ...) that are used in astronomical repositories since you don't have to deconstruct the textual version first. Personally I'd drop the textual version of ADQL - if anyone wants to type the query in textual form, provide a pass-through option so they can type the end repository's SQL query (or whatever language it requires). (If they want the same query to go to multiple databases then they either construct ADQL using whatever portal front end they prefer or they type all the queries in manually.) Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil > O'Mullane > Sent: 31 January 2004 19:27 > Cc: voql@ivoa.net > Subject: Re: ADQL - it aint so great > > > Personally I also do not feel we need an XML form of ADQL. > But at IVOA meetings there was a general request to have ADQL in XML > format. I made a stab at and XML format. Modified it etc ... This of > course may be discussed again at the meeting. > Even internal to SkyServer there is some parsing going on as Clive > suggests. People generally felt having a parsed version would help in > this area. > > > We are aware of some of the problems mentioned especially with > java. Vivek is currently working on this and I believe will > post some new tutorials etc in the coming days. > > > wil > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > I tried and I failed. > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > query language for astrogrid datacenters. What are its benefits? > > > > I agree with your comments, Noel, and I've been asking for > some time > > why we need ADQL. The only answer I was able to get was > that it made > > the checking of the query simpler and improves security. I am not > > convinced that we need to be all that fussy in checing > syntax: if the > > user generates the query from our menu-style registry-driven portal > > then it will be hard to make a syntax mistake; power users who > > generate their own SQL by typing it into a text box will > find out soon > > enough if they make a mistake: any DBMS parses the query > and returns > > an error message instantly. The experience of JHU with their > > skyserver was given at the last ADASS meeting by Wil > O'Mullane: indeed > > he made a mistake in his live demo and got a message back, allowing > > him to correct it. This isn't a perfectly user-friendly > system, but > > it seems adequate to me. As far as security goes, a simple > solution > > initially is to restrict the first keyword of any query to > be SELECT, > > and in particular prevent non-authenticated users from > issuing DROP or > > DELETE statements. Later, maybe, we can allow things like CREATE > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard > > even without ADQL. > > > > > > -- > > Clive Page > > Dept of Physics & Astronomy, > > University of Leicester, Tel +44 116 252 3551 > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > From owner-voql@eso.org Mon Feb 2 17:14:58 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 i12GEa9Z000815 for ; Mon, 2 Feb 2004 17:14:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i12GEaKc000812 for voql-outgoing; Mon, 2 Feb 2004 17:14:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i12GEY9Z000798 for ; Mon, 2 Feb 2004 17:14:34 +0100 (MET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i12GEREY014269 for ; Mon, 2 Feb 2004 17:14:28 +0100 (CET) Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i12GEPtW020614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 2 Feb 2004 08:14:25 -0800 Message-ID: <0db701c3e9a7$ef51edc0$0c0ba8c0@cacr.caltech.edu> From: "Roy Williams" To: "Jim Gray" Cc: References: <25603A6EFF8BA34AB2A49615383CD44902180539@RED-MSG-31.redmond.corp.microsoft.com> Subject: Re: ADQL - Careful what you wish for Date: Mon, 2 Feb 2004 08:16:37 -0800 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.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 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-voql@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Jim Here are some neophyte questions. (1) Is there a "standard" SQL that all the databases understand, somthing that is least common denominator, somthing not tied to a vendor? I seem to recall SQL92, is that it? Is it ISO or ANSI approved? Is there a definition document? (2) If there is such a standard, is it reasonably competent, or are there gaping holes? In other words, can I do unjoined select statements in full glory? (3) Does the extension mechanism that you refer to exist within a "standard" SQL? Does it allow us extensions for sky regions, with things like radius and fuzzy join? Thank you Roy -------- Caltech Center for Advanced Computing Research roy@cacr.caltech.edu 626 395 3670 ----- Original Message ----- From: "Jim Gray" To: "Tony Linde" ; "Wil O'Mullane" Cc: Sent: Monday, February 02, 2004 7:28 AM Subject: RE: ADQL - Careful what you wish for > sage advice: > As one who has watched language designers struggle for many years with > languages like Fortran, VisiCalc, SQL, and HTML, I have learned that it > is not an occupation for dilettantes like us. > So, to the extent that you can hijack an existing language like SQL, do > it. > There are no "minor" changes to these languages; they all have any tight > interconnections. > Adding XML data in the middle of some language is non trivial. > If you really love XML, you might look at xQuery, but it has rather poor > implementations so far, and it lacks update/inset/delete; and some > describe the language as "ugly" . > The Sky Query folks extended the table names with an extra level of > qualification and added a function (cross match). > That was safe and easy. > I recommend you try to use SQL's built in extension mechanisms. > It you really! want to do language design, do not couple that research > with the main path of the VO effort. > It would make a fine side-project for the computer science guys -but it > should not be on the critical path for the VO > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Tony > Linde > Sent: Sunday, February 01, 2004 2:28 AM > To: 'Wil O'Mullane' > Cc: voql@ivoa.net > Subject: RE: ADQL - it aint so great > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have ADQL in XML > > format. I made a stab at and XML format. Modified it > > I still think we need the xml version. Astronomy includes values which > are not simple scalars; representing structures even as simple as a > polar coordinate is messy in a textual language. As we add more complex > features/funcitons to ADQL we don't want to have to invent text > equivalents of vectors, arrays and more complex structured values. > > An xml document is also easier to construct from user selections in a > query screen and much easier to translate into the many variants of SQL > (and OQL and ...) that are used in astronomical repositories since you > don't have to deconstruct the textual version first. > > Personally I'd drop the textual version of ADQL - if anyone wants to > type the query in textual form, provide a pass-through option so they > can type the end repository's SQL query (or whatever language it > requires). (If they want the same query to go to multiple databases then > they either construct ADQL using whatever portal front end they prefer > or they type all the queries in manually.) > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Wil > > O'Mullane > > Sent: 31 January 2004 19:27 > > Cc: voql@ivoa.net > > Subject: Re: ADQL - it aint so great > > > > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have ADQL in XML > > format. I made a stab at and XML format. Modified it etc ... This of > > course may be discussed again at the meeting. > > Even internal to SkyServer there is some parsing going on as Clive > > suggests. People generally felt having a parsed version would help in > > this area. > > > > > > We are aware of some of the problems mentioned especially with > > java. Vivek is currently working on this and I believe will > > post some new tutorials etc in the coming days. > > > > > > wil > > > > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > > > I tried and I failed. > > > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > > query language for astrogrid datacenters. What are its benefits? > > > > > > I agree with your comments, Noel, and I've been asking for > > some time > > > why we need ADQL. The only answer I was able to get was > > that it made > > > the checking of the query simpler and improves security. I am not > > > convinced that we need to be all that fussy in checing > > syntax: if the > > > user generates the query from our menu-style registry-driven portal > > > then it will be hard to make a syntax mistake; power users who > > > generate their own SQL by typing it into a text box will > > find out soon > > > enough if they make a mistake: any DBMS parses the query > > and returns > > > an error message instantly. The experience of JHU with their > > > skyserver was given at the last ADASS meeting by Wil > > O'Mullane: indeed > > > he made a mistake in his live demo and got a message back, allowing > > > him to correct it. This isn't a perfectly user-friendly > > system, but > > > it seems adequate to me. As far as security goes, a simple > > solution > > > initially is to restrict the first keyword of any query to > > be SELECT, > > > and in particular prevent non-authenticated users from > > issuing DROP or > > > DELETE statements. Later, maybe, we can allow things like CREATE > > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard > > > even without ADQL. > > > > > > > > > -- > > > Clive Page > > > Dept of Physics & Astronomy, > > > University of Leicester, Tel +44 116 252 3551 > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > > From owner-voql@eso.org Mon Feb 2 17:49: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 i12Gma9Z008718 for ; Mon, 2 Feb 2004 17:48:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i12GmaVu008717 for voql-outgoing; Mon, 2 Feb 2004 17:48:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i12GmW9Z008688 for ; Mon, 2 Feb 2004 17:48:32 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i12GmQEY016464 for ; Mon, 2 Feb 2004 17:48:27 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AnhFJ-0006cS-Tm for voql@ivoa.net; Mon, 02 Feb 2004 16:48:25 +0000 Received: (qmail 19085 invoked from network); 2 Feb 2004 16:48:45 -0000 Received: from morpheus.star.le.ac.uk (HELO gnowee) (143.210.36.121) by mail.star.le.ac.uk with SMTP; 2 Feb 2004 16:48:45 -0000 From: "Tony Linde" To: Subject: RE: ADQL - Careful what you wish for Date: Mon, 2 Feb 2004 16:49:38 -0000 Message-ID: <001801c3e9ac$8bf323c0$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 In-Reply-To: <25603A6EFF8BA34AB2A49615383CD44902180539@RED-MSG-31.redmond.corp.microsoft.com> 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 i12GmZ9Z008710 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Jim, I don't think anyone wants to create a 'new' language. Whatever form ADQL takes, it will always be based on SQL. The reason for having an xml-based rahter than text-based language is simply to make it easier to construct and parse and easier to translate into the (usually) SQL variants that the back-end repositories require. It will also make it easier to specify vectors, arrays and structures as values in WHERE clauses and as parameters in functions, all of which are in 'standard' SQL but which require messy representations in textual form (eg Region ('CIRCLE J2000 19.5 -36.7 0.02')). Cheers, Tony. > -----Original Message----- > From: Jim Gray [mailto:gray@microsoft.com] > Sent: 02 February 2004 15:28 > To: Tony Linde; Wil O'Mullane > Cc: voql@ivoa.net > Subject: RE: ADQL - Careful what you wish for > > > sage advice: > As one who has watched language designers struggle for many > years with languages like Fortran, VisiCalc, SQL, and HTML, I > have learned that it is not an occupation for dilettantes like us. > So, to the extent that you can hijack an existing language > like SQL, do it. > There are no "minor" changes to these languages; they all > have any tight interconnections. > Adding XML data in the middle of some language is non trivial. > If you really love XML, you might look at xQuery, but it has > rather poor implementations so far, and it lacks > update/inset/delete; and some describe the language as "ugly" . > The Sky Query folks extended the table names with an extra > level of qualification and added a function (cross match). > That was safe and easy. > I recommend you try to use SQL's built in extension > mechanisms. It you really! want to do language design, do not > couple that research with the main path of the VO effort. > It would make a fine side-project for the computer science > guys -but it should not be on the critical path for the VO > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Tony Linde > Sent: Sunday, February 01, 2004 2:28 AM > To: 'Wil O'Mullane' > Cc: voql@ivoa.net > Subject: RE: ADQL - it aint so great > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have > ADQL in XML > > format. I made a stab at and XML format. Modified it > > I still think we need the xml version. Astronomy includes > values which are not simple scalars; representing structures > even as simple as a polar coordinate is messy in a textual > language. As we add more complex features/funcitons to ADQL > we don't want to have to invent text equivalents of vectors, > arrays and more complex structured values. > > An xml document is also easier to construct from user > selections in a query screen and much easier to translate > into the many variants of SQL (and OQL and ...) that are used > in astronomical repositories since you don't have to > deconstruct the textual version first. > > Personally I'd drop the textual version of ADQL - if anyone > wants to type the query in textual form, provide a > pass-through option so they can type the end repository's SQL > query (or whatever language it requires). (If they want the > same query to go to multiple databases then they either > construct ADQL using whatever portal front end they prefer or > they type all the queries in manually.) > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil > > O'Mullane > > Sent: 31 January 2004 19:27 > > Cc: voql@ivoa.net > > Subject: Re: ADQL - it aint so great > > > > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have > ADQL in XML > > format. I made a stab at and XML format. Modified it etc > ... This of > > course may be discussed again at the meeting. > > Even internal to SkyServer there is some parsing going on as Clive > > suggests. People generally felt having a parsed version > would help in > > this area. > > > > > > We are aware of some of the problems mentioned especially with > > java. Vivek is currently working on this and I believe will > > post some new tutorials etc in the coming days. > > > > > > wil > > > > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > > > I tried and I failed. > > > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > > query language for astrogrid datacenters. What are its benefits? > > > > > > I agree with your comments, Noel, and I've been asking for > > some time > > > why we need ADQL. The only answer I was able to get was > > that it made > > > the checking of the query simpler and improves security. I am not > > > convinced that we need to be all that fussy in checing > > syntax: if the > > > user generates the query from our menu-style > registry-driven portal > > > then it will be hard to make a syntax mistake; power users who > > > generate their own SQL by typing it into a text box will > > find out soon > > > enough if they make a mistake: any DBMS parses the query > > and returns > > > an error message instantly. The experience of JHU with their > > > skyserver was given at the last ADASS meeting by Wil > > O'Mullane: indeed > > > he made a mistake in his live demo and got a message > back, allowing > > > him to correct it. This isn't a perfectly user-friendly > > system, but > > > it seems adequate to me. As far as security goes, a simple > > solution > > > initially is to restrict the first keyword of any query to > > be SELECT, > > > and in particular prevent non-authenticated users from > > issuing DROP or > > > DELETE statements. Later, maybe, we can allow things like CREATE > > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all > that hard > > > even without ADQL. > > > > > > > > > -- > > > Clive Page > > > Dept of Physics & Astronomy, > > > University of Leicester, Tel +44 116 252 3551 > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > From owner-voql@eso.org Mon Feb 2 17:51:04 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 i12Gop9Z009256 for ; Mon, 2 Feb 2004 17:50:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i12Gopx7009255 for voql-outgoing; Mon, 2 Feb 2004 17:50:51 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i12Gom9Z009238 for ; Mon, 2 Feb 2004 17:50:48 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i12GolEY016604 for ; Mon, 2 Feb 2004 17:50:47 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AnhHa-0006xN-Ip for voql@ivoa.net; Mon, 02 Feb 2004 16:50:46 +0000 Received: (qmail 19229 invoked from network); 2 Feb 2004 16:51:02 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 2 Feb 2004 16:51:02 -0000 Date: Mon, 2 Feb 2004 16:50:41 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: ADQL - Careful what you wish for In-Reply-To: <0db701c3e9a7$ef51edc0$0c0ba8c0@cacr.caltech.edu> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 2 Feb 2004, Roy Williams wrote: > (1) Is there a "standard" SQL that all the databases understand, somthing > that is least common denominator, somthing not tied to a vendor? I seem to > recall SQL92, is that it? Is it ISO or ANSI approved? Is there a definition > document? Roy I'm sure Jim will give you a much more authoritative answer than I can on the question of standards for SQL and their implementation in practice, but just to give you an idea of the problems you might look at my analysis here http://wiki.astrogrid.org/bin/view/Astrogrid/DBMSmathFunctions of support for mathematical functions in: - our very own ADQL version 0.7 - JDBC: a Sun-defined standard for connecting procedural languages to SQL - the SQL implementations of six relational DBMS in common use by astronomers. You will see that it's quite hard to write any mathematical function in SQL in a portable way. This site: http://troels.arvin.dk/db/rdbms/ will give you a flavour of other practical problems. Jim Gray wrote: > > As one who has watched language designers struggle for many years with > > languages like Fortran, VisiCalc, SQL, and HTML, I have learned that it > > is not an occupation for dilettantes like us. I agree that we ought to be very wary of inventing a new language of our own. Can I support that with a quotation which I came across recently, and which I fear which is not far from the truth: "Most scientists only know two programming languages: Fortran and Latex. They do their word-processing in Fortran, and their numerical analysis in Latex". -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-voql@eso.org Mon Feb 2 20:24:20 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 i12JNs9Z008292 for ; Mon, 2 Feb 2004 20:23:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i12JNsPm008291 for voql-outgoing; Mon, 2 Feb 2004 20:23:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i12JNp9Z008276 for ; Mon, 2 Feb 2004 20:23:51 +0100 (MET) Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i12JNmWR011953 for ; Mon, 2 Feb 2004 20:23:49 +0100 (CET) Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68]) by milkyway.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id i12JNpGP012435; Mon, 2 Feb 2004 14:23:51 -0500 Message-ID: <401EA3C6.9090901@lheapop.gsfc.nasa.gov> Date: Mon, 02 Feb 2004 14:23:50 -0500 From: Thomas McGlynn Organization: NASA Goddard Space Flight Center User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page CC: voql@ivoa.net Subject: Re: ADQL - Careful what you wish for 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-voql@eso.org Precedence: bulk Reply-To: Thomas McGlynn X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive Page wrote: > On Mon, 2 Feb 2004, Roy Williams wrote: > > >>(1) Is there a "standard" SQL that all the databases understand, somthing >>that is least common denominator, somthing not tied to a vendor? I seem to >>recall SQL92, is that it? Is it ISO or ANSI approved? Is there a definition >>document? > > > Roy > > I'm sure Jim will give you a much more authoritative answer than I can on > the question of standards for SQL and their implementation in practice, > but just to give you an idea of the problems you might look at my > analysis here > > http://wiki.astrogrid.org/bin/view/Astrogrid/DBMSmathFunctions > > of support for mathematical functions in: > - our very own ADQL version 0.7 > - JDBC: a Sun-defined standard for connecting procedural languages to SQL > - the SQL implementations of six relational DBMS in common use by > astronomers. > > You will see that it's quite hard to write any mathematical function in > SQL in a portable way. This site: http://troels.arvin.dk/db/rdbms/ > will give you a flavour of other practical problems. > Clearly there needs to be translation from the agreed upon standard to the internal query representation regardless of whether the standard is some particular version of SQL or some XML tree. For those of us with SQL based databases the question arises as to whether it is easier to modify an SQL string to accommodate changes in dialect, or to regenerate the entire SQL string from some preparsed XML. Just to give a data point here... The HEASARC's Browse service runs on both Oracle and Sybase databases and the answer we have adopted is to use simple regular expression transformations of the query. So for us Sybase SQL is the 'standard' and Oracle is a dialect that we need to translate to. Function names are relatively easy to isolate since they come immediately before '(' with no intervening operator. I'm sure that someone could deliberately craft a query that we'd have trouble with, but in several years of operation I don't recall it ever happening. However, we don't support users entering SQL directly. In practice the only issue we have is in the function to convert a number to a string (convert in Sybase and to_char in Oracle). We used to support Ingres and I believe there were rather more issues there, but there was no problem using the same approach. I see that 11 of the functions you list are identical in all systems and many of the one's that are not are easily mimicked using the standard set (e.g., cot = 1/tan).... So perhaps the glass is half full? Regards, Tom MCGlynn From owner-voql@eso.org Tue Feb 3 07:50:12 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 i136n2w9000546 for ; Tue, 3 Feb 2004 07:49:02 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i136n2sS000545 for voql-outgoing; Tue, 3 Feb 2004 07:49:02 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i136mxw9000534 for ; Tue, 3 Feb 2004 07:48:59 +0100 (MET) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i136muEY016544 for ; Tue, 3 Feb 2004 07:48:57 +0100 (CET) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 2 Feb 2004 22:48:54 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Feb 2004 22:48:54 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 22:52:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ADQL - Answering Roy Willims 3 questions re "standard SQL" Date: Mon, 2 Feb 2004 22:48:51 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490218112A@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ADQL - Answering Roy Willims 3 questions re "standard SQL" Thread-Index: AcPpp7jXdsKtDQVTQnyPBVUCPlex1QAdnz9w From: "Jim Gray" To: "Roy Williams" Cc: X-OriginalArrivalTime: 03 Feb 2004 06:52:29.0258 (UTC) FILETIME=[4A48D2A0:01C3EA22] 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 i136n1w9000542 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Roy, How embarrassing. The simple answer is no. The complex answer is: (Q1) is there a standard SQL that all database systems understand... NO. There is an ISO Standard but all the implementations support an extended subset of that standard (ie. Some overlap). There was an Xopen attempt to define a portable SQL, but that was long ago. To make things worse, each system has different datatypes, different functions, different function names, .... And there are some nasty corner cases, one popular vendor treats the empty string and the null string as the same, no other vendor does. It's a mess. To make things worse, MyDB requires that you be able to CREATE, DROP tables and INSERT and DELETE as well as SELECT. So, VO needs a fairly full version of SQL. We should probably write a parser for the subset that we can all agree to and that maps to the 6 popular systems (DB2, Oracle, MySql, PostSQL, SqlServer, Sybase). I think the JHU folks have a start on such a parser. We will then have to build the mapping matrix for each of the products. This is a pain, but I do not know of an open source tool that does it. Incidentally, contrary to Tony's experience "vectors, arrays, and structures" are not standard and are not in many of the SQL implementations. And no two implementations have the same way of doing these types (sigh!) It is non-trivial to add them (Q2) If there is such a standard,.... Nope. (Q3) Does the extension mechanism that you refer to exist within a "standard" SQL? The SQL Standard has extension mechanism (persistent stored modules), but only 2 vendors observe that standard and it requires you to write in a strange module language. The extensions to support the math library and other functions is not standardized. What I was advocating is something similar to what Clive Page started -- VOQL would be an extended subset of SQL, just like all the other SQL variants. I was thinking the extensions would be things like: (1) functions, (2) qualifying the table names by the Archive name, (3) allowing inner and outer spatial join, (4) support for MyDB naming, and perhaps a few more essential features. Jim Gray Microsoft Research, Suite 1690, 455 Market, SF CA 94105, tel: 415 778 8222 fax: 425 706 7329 Gray@Microsoft.com http://research.Microsoft.com/~gray -----Original Message----- From: Roy Williams [mailto:roy@cacr.caltech.edu] Sent: Monday, February 02, 2004 8:17 AM To: Jim Gray Cc: voql@ivoa.net Subject: Re: ADQL - Careful what you wish for Jim Here are some neophyte questions. (1) Is there a "standard" SQL that all the databases understand, somthing that is least common denominator, somthing not tied to a vendor? I seem to recall SQL92, is that it? Is it ISO or ANSI approved? Is there a definition document? (2) If there is such a standard, is it reasonably competent, or are there gaping holes? In other words, can I do unjoined select statements in full glory? (3) Does the extension mechanism that you refer to exist within a "standard" SQL? Does it allow us extensions for sky regions, with things like radius and fuzzy join? Thank you Roy -------- Caltech Center for Advanced Computing Research roy@cacr.caltech.edu 626 395 3670 ----- Original Message ----- From: "Jim Gray" To: "Tony Linde" ; "Wil O'Mullane" Cc: Sent: Monday, February 02, 2004 7:28 AM Subject: RE: ADQL - Careful what you wish for > sage advice: > As one who has watched language designers struggle for many years > with languages like Fortran, VisiCalc, SQL, and HTML, I have learned > that it is not an occupation for dilettantes like us. > So, to the extent that you can hijack an existing language like SQL, > do it. > There are no "minor" changes to these languages; they all have any > tight interconnections. > Adding XML data in the middle of some language is non trivial. > If you really love XML, you might look at xQuery, but it has rather > poor implementations so far, and it lacks update/inset/delete; and > some describe the language as "ugly" . > The Sky Query folks extended the table names with an extra level of > qualification and added a function (cross match). > That was safe and easy. > I recommend you try to use SQL's built in extension mechanisms. > It you really! want to do language design, do not couple that research > with the main path of the VO effort. > It would make a fine side-project for the computer science guys -but > it should not be on the critical path for the VO > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Tony > Linde > Sent: Sunday, February 01, 2004 2:28 AM > To: 'Wil O'Mullane' > Cc: voql@ivoa.net > Subject: RE: ADQL - it aint so great > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have ADQL in XML > > format. I made a stab at and XML format. Modified it > > I still think we need the xml version. Astronomy includes values which > are not simple scalars; representing structures even as simple as a > polar coordinate is messy in a textual language. As we add more > complex features/funcitons to ADQL we don't want to have to invent > text equivalents of vectors, arrays and more complex structured values. > > An xml document is also easier to construct from user selections in a > query screen and much easier to translate into the many variants of > SQL (and OQL and ...) that are used in astronomical repositories since > you don't have to deconstruct the textual version first. > > Personally I'd drop the textual version of ADQL - if anyone wants to > type the query in textual form, provide a pass-through option so they > can type the end repository's SQL query (or whatever language it > requires). (If they want the same query to go to multiple databases > then they either construct ADQL using whatever portal front end they > prefer or they type all the queries in manually.) > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > > Wil O'Mullane > > Sent: 31 January 2004 19:27 > > Cc: voql@ivoa.net > > Subject: Re: ADQL - it aint so great > > > > > > Personally I also do not feel we need an XML form of ADQL. > > But at IVOA meetings there was a general request to have ADQL in XML > > format. I made a stab at and XML format. Modified it etc ... This of > > course may be discussed again at the meeting. > > Even internal to SkyServer there is some parsing going on as Clive > > suggests. People generally felt having a parsed version would help > > in this area. > > > > > > We are aware of some of the problems mentioned especially with java. > > Vivek is currently working on this and I believe will post some new > > tutorials etc in the coming days. > > > > > > wil > > > > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > > > I tried and I failed. > > > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > > query language for astrogrid datacenters. What are its benefits? > > > > > > I agree with your comments, Noel, and I've been asking for > > some time > > > why we need ADQL. The only answer I was able to get was > > that it made > > > the checking of the query simpler and improves security. I am not > > > convinced that we need to be all that fussy in checing > > syntax: if the > > > user generates the query from our menu-style registry-driven > > > portal then it will be hard to make a syntax mistake; power users > > > who generate their own SQL by typing it into a text box will > > find out soon > > > enough if they make a mistake: any DBMS parses the query > > and returns > > > an error message instantly. The experience of JHU with their > > > skyserver was given at the last ADASS meeting by Wil > > O'Mullane: indeed > > > he made a mistake in his live demo and got a message back, > > > allowing him to correct it. This isn't a perfectly user-friendly > > system, but > > > it seems adequate to me. As far as security goes, a simple > > solution > > > initially is to restrict the first keyword of any query to > > be SELECT, > > > and in particular prevent non-authenticated users from > > issuing DROP or > > > DELETE statements. Later, maybe, we can allow things like CREATE > > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all that hard > > > even without ADQL. > > > > > > > > > -- > > > Clive Page > > > Dept of Physics & Astronomy, > > > University of Leicester, Tel +44 116 252 3551 > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > > From owner-voql@eso.org Tue Feb 3 12:14: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 i13BDpor020002 for ; Tue, 3 Feb 2004 12:13:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i13BDpE1020001 for voql-outgoing; Tue, 3 Feb 2004 12:13:51 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i13BDlor019975 for ; Tue, 3 Feb 2004 12:13:47 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i13BDiEY026982 for ; Tue, 3 Feb 2004 12:13:45 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i13BDim7013963; Tue, 3 Feb 2004 11:13:44 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i13BDiJ0013962; Tue, 3 Feb 2004 11:13:44 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 3 Feb 2004 11:13:44 +0000 Message-ID: <1075806824.401f826856138@netmail.pipex.net> Date: Tue, 3 Feb 2004 11:13:44 +0000 From: martin hill To: voql@ivoa.net Subject: RE: ADQL - Careful what you wish for References: <001801c3e9ac$8bf323c0$0b01a8c0@STAR.LE.AC.UK> In-Reply-To: <001801c3e9ac$8bf323c0$0b01a8c0@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I can appreciate that starting from scratch to build a completely new general query language would be a long, hard job. However we don't seem to have a suitable query language to hand that we can use, so we need to modify/adapt something. We can't use SQL: it's not standard. We can define an SQL-like language limited to the lowest common denominator but we have to write parsers etc that will handle them correctly, including our extensions. This is not trivial, whereas it is much easier to define these in XML. XQuery doesn't seem to be well understood by anyone on the list (or?) and could do with some more research. Even if there are no good implementations yet, we are going to have to write our own implementation (and have already written for AstroGrid) for whatever language we use, so this should not stop us. XQuery does not however look very easy to use... I'm putting the finishing touches to an XML query language (ADQL2?) based, like ADQL, on SQL. Being SQLish we borrow SQL principles. Being XML allows us all to look at, understand and (dis)agree its syntax, gives us tools to validate it, tools to build GUIs around it (in fact even Eclipse's XML Buddy helps me construct such queries) and it's straightforward to read/write, straightforward to convert to/from SQL and has some interim capability to include XPaths as well as columns. I am very conscious that we have people using and demonstrating services now, who require a usable query language. Perhaps we can use this in the meantime while we look at XQuery? Cheers, Martin Quoting Tony Linde : > Hi Jim, > > I don't think anyone wants to create a 'new' language. Whatever form ADQL > takes, it will always be based on SQL. The reason for having an xml-based > rahter than text-based language is simply to make it easier to construct and > parse and easier to translate into the (usually) SQL variants that the > back-end repositories require. It will also make it easier to specify > vectors, arrays and structures as values in WHERE clauses and as parameters > in functions, all of which are in 'standard' SQL but which require messy > representations in textual form (eg Region ('CIRCLE J2000 19.5 -36.7 > 0.02')). > > Cheers, > Tony. > > > -----Original Message----- > > From: Jim Gray [mailto:gray@microsoft.com] > > Sent: 02 February 2004 15:28 > > To: Tony Linde; Wil O'Mullane > > Cc: voql@ivoa.net > > Subject: RE: ADQL - Careful what you wish for > > > > > > sage advice: > > As one who has watched language designers struggle for many > > years with languages like Fortran, VisiCalc, SQL, and HTML, I > > have learned that it is not an occupation for dilettantes like us. > > So, to the extent that you can hijack an existing language > > like SQL, do it. > > There are no "minor" changes to these languages; they all > > have any tight interconnections. > > Adding XML data in the middle of some language is non trivial. > > If you really love XML, you might look at xQuery, but it has > > rather poor implementations so far, and it lacks > > update/inset/delete; and some describe the language as "ugly" . > > The Sky Query folks extended the table names with an extra > > level of qualification and added a function (cross match). > > That was safe and easy. > > I recommend you try to use SQL's built in extension > > mechanisms. It you really! want to do language design, do not > > couple that research with the main path of the VO effort. > > It would make a fine side-project for the computer science > > guys -but it should not be on the critical path for the VO > > > > Jim Gray > > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > > tel: 415 778 8222 fax: 425 706 7329 > > Gray@Microsoft.com http://research.Microsoft.com/~gray > > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Tony Linde > > Sent: Sunday, February 01, 2004 2:28 AM > > To: 'Wil O'Mullane' > > Cc: voql@ivoa.net > > Subject: RE: ADQL - it aint so great > > > > > Personally I also do not feel we need an XML form of ADQL. > > > But at IVOA meetings there was a general request to have > > ADQL in XML > > > format. I made a stab at and XML format. Modified it > > > > I still think we need the xml version. Astronomy includes > > values which are not simple scalars; representing structures > > even as simple as a polar coordinate is messy in a textual > > language. As we add more complex features/funcitons to ADQL > > we don't want to have to invent text equivalents of vectors, > > arrays and more complex structured values. > > > > An xml document is also easier to construct from user > > selections in a query screen and much easier to translate > > into the many variants of SQL (and OQL and ...) that are used > > in astronomical repositories since you don't have to > > deconstruct the textual version first. > > > > Personally I'd drop the textual version of ADQL - if anyone > > wants to type the query in textual form, provide a > > pass-through option so they can type the end repository's SQL > > query (or whatever language it requires). (If they want the > > same query to go to multiple databases then they either > > construct ADQL using whatever portal front end they prefer or > > they type all the queries in manually.) > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of Wil > > > O'Mullane > > > Sent: 31 January 2004 19:27 > > > Cc: voql@ivoa.net > > > Subject: Re: ADQL - it aint so great > > > > > > > > > Personally I also do not feel we need an XML form of ADQL. > > > But at IVOA meetings there was a general request to have > > ADQL in XML > > > format. I made a stab at and XML format. Modified it etc > > ... This of > > > course may be discussed again at the meeting. > > > Even internal to SkyServer there is some parsing going on as Clive > > > suggests. People generally felt having a parsed version > > would help in > > > this area. > > > > > > > > > We are aware of some of the problems mentioned especially with > > > java. Vivek is currently working on this and I believe will > > > post some new tutorials etc in the coming days. > > > > > > > > > wil > > > > > > > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > > > > > I tried and I failed. > > > > > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > > > > > I'm really beginning to wonder whether ADQL is the most suitable > > > > > query language for astrogrid datacenters. What are its benefits? > > > > > > > > I agree with your comments, Noel, and I've been asking for > > > some time > > > > why we need ADQL. The only answer I was able to get was > > > that it made > > > > the checking of the query simpler and improves security. I am not > > > > convinced that we need to be all that fussy in checing > > > syntax: if the > > > > user generates the query from our menu-style > > registry-driven portal > > > > then it will be hard to make a syntax mistake; power users who > > > > generate their own SQL by typing it into a text box will > > > find out soon > > > > enough if they make a mistake: any DBMS parses the query > > > and returns > > > > an error message instantly. The experience of JHU with their > > > > skyserver was given at the last ADASS meeting by Wil > > > O'Mullane: indeed > > > > he made a mistake in his live demo and got a message > > back, allowing > > > > him to correct it. This isn't a perfectly user-friendly > > > system, but > > > > it seems adequate to me. As far as security goes, a simple > > > solution > > > > initially is to restrict the first keyword of any query to > > > be SELECT, > > > > and in particular prevent non-authenticated users from > > > issuing DROP or > > > > DELETE statements. Later, maybe, we can allow things like CREATE > > > > TABLE, INSERT, UPDATE, and so on. That shouldn't be all > > that hard > > > > even without ADQL. > > > > > > > > > > > > -- > > > > Clive Page > > > > Dept of Physics & Astronomy, > > > > University of Leicester, Tel +44 116 252 3551 > > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > > > > > > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Tue Feb 3 17:46: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 i13GjYDk019828 for ; Tue, 3 Feb 2004 17:45:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i13GjYhx019827 for voql-outgoing; Tue, 3 Feb 2004 17:45:34 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i13GjVDk019819 for ; Tue, 3 Feb 2004 17:45:31 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i13GjSWR002610 for ; Tue, 3 Feb 2004 17:45:28 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i13GjRm7004842; Tue, 3 Feb 2004 16:45:27 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i13GjPId004841; Tue, 3 Feb 2004 16:45:25 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 3 Feb 2004 16:45:25 +0000 Message-ID: <1075826725.401fd025cb0b7@netmail.pipex.net> Date: Tue, 3 Feb 2004 16:45:25 +0000 From: martin hill To: Jim Gray Cc: voql@ivoa.net Subject: RE: ADQL - example what I'm wishing for References: <25603A6EFF8BA34AB2A49615383CD4490218116C@RED-MSG-31.redmond.corp.microsoft.com> In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490218116C@RED-MSG-31.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Jim I don't expect it to be *as* readable, but readability is just one of the factors. Agreeing exact syntax, using standard tools, building tools (such as query builders) out of standard techniques & components, etc, rather than building 'from-scratch' specific-SQL parsers & builders. We can also make the process of reporting query-language errors much more exactly than I've seen so far with current SQL servers. We can get XML that's not too bad though. I want to have a chance to check for obvious errors with my colleagues here before submitting (this evening or tomorrow) a new schema, but this is an example XML query of SELECT *: or a larger example with silly values, including mixed RDBMS/Heirarchical ValueSets: RA Wobble
RA_OBJ DEC Wobble
DECL_OBJ Elipticity thingy/thingy/thingy/etc Magnitude thangy/thangy/thangy/etc RA DEC Magnitude Elipticity RA 12 13 3 Banana Shaped Elipticity Which is something like SELECT w.RA w.DEC FROM Wobble w SomePath p ORDERBY SIN(p.Magnitude) p.Elipticity GROUP ABS(w.RA) WHERE (CIRCLE(12,13,3) AND (BananaShaped =< p.Elipticity)) It's not as nice as it could be but it is reasonably straightforward to follow. Simpler queries are easier in SQL, but you can see that more complex ones will be easier to debug in XML! We should also be able to use exactly the same language for accessing heirarchical datasets which will help us (at AstroGrid) build datacenters around all kinds of other data types. Cheers, Martin (BTW - I'm assuming your email was only mistakenly just to me!) Quoting Jim Gray : > Martin: > I am skeptical that the XML syntax will be as readable by humans as a > linear syntax. > Can you send me some side-by-side example of SQL and ADQL2 that > demonstrates your point? > Jim > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of martin > hill > Sent: Tuesday, February 03, 2004 3:14 AM > To: voql@ivoa.net > Subject: RE: ADQL - Careful what you wish for > > I can appreciate that starting from scratch to build a completely new > general query language would be a long, hard job. However we don't seem > to have a suitable query language to hand that we can use, so we need to > modify/adapt something. > > We can't use SQL: it's not standard. We can define an SQL-like language > limited to the lowest common denominator but we have to write parsers > etc that will handle them correctly, including our extensions. This is > not trivial, whereas it is much easier to define these in XML. > > XQuery doesn't seem to be well understood by anyone on the list (or?) > and could do with some more research. Even if there are no good > implementations yet, we are going to have to write our own > implementation (and have already written for > AstroGrid) for whatever language we use, so this should not stop us. > XQuery does not however look very easy to use... > > I'm putting the finishing touches to an XML query language (ADQL2?) > based, like ADQL, on SQL. Being SQLish we borrow SQL principles. Being > XML allows us all to look at, understand and (dis)agree its syntax, > gives us tools to validate it, tools to build GUIs around it (in fact > even Eclipse's XML Buddy helps me construct such queries) and it's > straightforward to read/write, straightforward to convert to/from SQL > and has some interim capability to include XPaths as well as columns. > > I am very conscious that we have people using and demonstrating services > now, who require a usable query language. Perhaps we can use this in > the meantime while we look at XQuery? > > Cheers, > > Martin > > Quoting Tony Linde : > > > Hi Jim, > > > > I don't think anyone wants to create a 'new' language. Whatever form > > ADQL takes, it will always be based on SQL. The reason for having an > > xml-based rahter than text-based language is simply to make it easier > > to construct and parse and easier to translate into the (usually) SQL > > variants that the back-end repositories require. It will also make it > > easier to specify vectors, arrays and structures as values in WHERE > > clauses and as parameters in functions, all of which are in 'standard' > > > SQL but which require messy representations in textual form (eg Region > > > ('CIRCLE J2000 19.5 -36.7 0.02')). > > > > Cheers, > > Tony. > > > > > -----Original Message----- > > > From: Jim Gray [mailto:gray@microsoft.com] > > > Sent: 02 February 2004 15:28 > > > To: Tony Linde; Wil O'Mullane > > > Cc: voql@ivoa.net > > > Subject: RE: ADQL - Careful what you wish for > > > > > > > > > sage advice: > > > As one who has watched language designers struggle for many years > > > with languages like Fortran, VisiCalc, SQL, and HTML, I have learned > > > > that it is not an occupation for dilettantes like us. > > > So, to the extent that you can hijack an existing language like SQL, > > > > do it. > > > There are no "minor" changes to these languages; they all have any > > > tight interconnections. > > > Adding XML data in the middle of some language is non trivial. > > > If you really love XML, you might look at xQuery, but it has rather > > > poor implementations so far, and it lacks update/inset/delete; and > > > some describe the language as "ugly" . > > > The Sky Query folks extended the table names with an extra level of > > > qualification and added a function (cross match). > > > That was safe and easy. > > > I recommend you try to use SQL's built in extension mechanisms. It > > > you really! want to do language design, do not couple that research > > > with the main path of the VO effort. > > > It would make a fine side-project for the computer science guys -but > > > > it should not be on the critical path for the VO > > > > > > Jim Gray > > > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > > > tel: 415 778 8222 fax: 425 706 7329 > > > Gray@Microsoft.com http://research.Microsoft.com/~gray > > > > > > -----Original Message----- > > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of > > > Tony Linde > > > Sent: Sunday, February 01, 2004 2:28 AM > > > To: 'Wil O'Mullane' > > > Cc: voql@ivoa.net > > > Subject: RE: ADQL - it aint so great > > > > > > > Personally I also do not feel we need an XML form of ADQL. > > > > But at IVOA meetings there was a general request to have > > > ADQL in XML > > > > format. I made a stab at and XML format. Modified it > > > > > > I still think we need the xml version. Astronomy includes values > > > which are not simple scalars; representing structures even as simple > > > > as a polar coordinate is messy in a textual language. As we add more > > > > complex features/funcitons to ADQL we don't want to have to invent > > > text equivalents of vectors, arrays and more complex structured > > > values. > > > > > > An xml document is also easier to construct from user selections in > > > a query screen and much easier to translate into the many variants > > > of SQL (and OQL and ...) that are used in astronomical repositories > > > since you don't have to deconstruct the textual version first. > > > > > > Personally I'd drop the textual version of ADQL - if anyone wants to > > > > type the query in textual form, provide a pass-through option so > > > they can type the end repository's SQL query (or whatever language > > > it requires). (If they want the same query to go to multiple > > > databases then they either construct ADQL using whatever portal > > > front end they prefer or they type all the queries in manually.) > > > > > > Cheers, > > > Tony. > > > > > > > -----Original Message----- > > > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > > Behalf Of Wil > > > > O'Mullane > > > > Sent: 31 January 2004 19:27 > > > > Cc: voql@ivoa.net > > > > Subject: Re: ADQL - it aint so great > > > > > > > > > > > > Personally I also do not feel we need an XML form of ADQL. > > > > But at IVOA meetings there was a general request to have > > > ADQL in XML > > > > format. I made a stab at and XML format. Modified it etc > > > ... This of > > > > course may be discussed again at the meeting. > > > > Even internal to SkyServer there is some parsing going on as Clive > > > > > suggests. People generally felt having a parsed version > > > would help in > > > > this area. > > > > > > > > > > > > We are aware of some of the problems mentioned especially with > > > > java. Vivek is currently working on this and I believe will post > > > > some new tutorials etc in the coming days. > > > > > > > > > > > > wil > > > > > > > > > > > > On Sat, Jan 31, 2004 at 04:40:11PM +0000, Clive Page wrote: > > > > > On Fri, 30 Jan 2004, Noel Winstanley wrote: > > > > > > > > > > > I tried and I failed. > > > > > > > > > > > > I can;t get any joy with the latest version of ADQL. > > > > > > > > > > > I'm really beginning to wonder whether ADQL is the most > > > > > > suitable query language for astrogrid datacenters. What are > its benefits? > > > > > > > > > > I agree with your comments, Noel, and I've been asking for > > > > some time > > > > > why we need ADQL. The only answer I was able to get was > > > > that it made > > > > > the checking of the query simpler and improves security. I am > > > > > not convinced that we need to be all that fussy in checing > > > > syntax: if the > > > > > user generates the query from our menu-style > > > registry-driven portal > > > > > then it will be hard to make a syntax mistake; power users who > > > > > generate their own SQL by typing it into a text box will > > > > find out soon > > > > > enough if they make a mistake: any DBMS parses the query > > > > and returns > > > > > an error message instantly. The experience of JHU with their > > > > > skyserver was given at the last ADASS meeting by Wil > > > > O'Mullane: indeed > > > > > he made a mistake in his live demo and got a message > > > back, allowing > > > > > him to correct it. This isn't a perfectly user-friendly > > > > system, but > > > > > it seems adequate to me. As far as security goes, a simple > > > > solution > > > > > initially is to restrict the first keyword of any query to > > > > be SELECT, > > > > > and in particular prevent non-authenticated users from > > > > issuing DROP or > > > > > DELETE statements. Later, maybe, we can allow things like > > > > > CREATE TABLE, INSERT, UPDATE, and so on. That shouldn't be all > > > that hard > > > > > even without ADQL. > > > > > > > > > > > > > > > -- > > > > > Clive Page > > > > > Dept of Physics & Astronomy, > > > > > University of Leicester, Tel +44 116 252 3551 > > > > > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > > > > > > > > > > > > > > > > > > > > > > -- > Martin Hill > 07901 55 24 66 > www.mchill.net > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Tue Feb 3 19:07:30 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 i13I7FDk007000 for ; Tue, 3 Feb 2004 19:07:15 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i13I7FvG006999 for voql-outgoing; Tue, 3 Feb 2004 19:07:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i13I7BDk006984 for ; Tue, 3 Feb 2004 19:07:12 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i13I79WR007073 for ; Tue, 3 Feb 2004 19:07:10 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i13I79m7009478 for ; Tue, 3 Feb 2004 18:07:09 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i13I788j009471 for voql@ivoa.net; Tue, 3 Feb 2004 18:07:08 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Tue, 3 Feb 2004 18:07:08 +0000 Message-ID: <1075831628.401fe34c38b42@netmail.pipex.net> Date: Tue, 3 Feb 2004 18:07:08 +0000 From: martin hill To: voql@ivoa.net Subject: SADQL schema MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1075831628c785687fa258fd7c08763513435fb7d6" User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This message is in MIME format. ---MOQ1075831628c785687fa258fd7c08763513435fb7d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit No, not a depressed Query Language, but a Simple Astronomy Data Query Language. Attached is both schema and an example document for ADQL v2, that I propose as a human-readable replacement for the existing machine-generated one. It's based on SQL with a few slight differences so it can handle heirarchical databases as well as relational ones. The following is the comment from the schema header: Definition Schema for an Astronomical Data Query Language. This is intended to be a query-only language. It is based on SQL, but probably does not implement (yet) all the required SQL query stuff. Aliases work a little differently - here you define aliases to value sets (ie columns or XPaths) rather than to tables. This could probably be done more sensibly using XPointer and IDs, but I want to think about this first. The idea is that the Return, OrderBy and Where elements should work entirely off the Aliases, so that we can reuse these elements across different datacenters, and the 'From' element is specific only to one database. At some point we should then be able to swap this element out instead. So the base element structure is like this: From (defines aliases) Return (defines results) - Set (list of columns/paths that will be returned in the results) - OrderedBy (list of keys defining order of results) - GroupedBy (list of keys defining how the results will be grouped) Where (defines search criteria - ie expressions based on aliases) Technical Notes: To get polymorphic relationships for the expressions, I use substitutionGroup. I'm not entirely happy with this - I'd much rather get polymorphism through type - but it seems to work OK. I also can't work out whether it's possible (or desirable) to substitute a string value instead of a tag. At the moment, for example, you have to write: 0.123 instead of: 0.123 Because you may want to include more complex expressions in there, such as: RA Also I can't see a way of sensibly Typing the expressions (ie Numerical vs String), because a ValueSet (Column/XPath) might be a string or a number. Probably the way to do this is to have a numericAlias and stringAlias but we can do that later without breaking any (valid) documents... Let me know of any comments, though I confess I am now off for the night and won't pick them up for a good 12 hours! So that gives you plenty of time to think of witty comments... Cheers, Martin -- Martin Hill 07901 55 24 66 www.mchill.net ---MOQ1075831628c785687fa258fd7c08763513435fb7d6 Content-Type: application/octet-stream; name="NewADQL.xsd" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="NewADQL.xsd" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCg0KPCEtLSANCiAgICRJZCQN Cg0KICAgRGVmaW5pdGlvbiBTY2hlbWEgZm9yIGFuIEFzdHJvbm9taWNhbCBEYXRhIFF1ZXJ5IExh bmd1YWdlLg0KICAgDQogICBUaGlzIGlzIGludGVuZGVkIHRvIGJlIGEgcXVlcnktb25seSBsYW5n dWFnZS4NCiAgIA0KICAgSXQgaXMgYmFzZWQgb24gU1FMLCBidXQgcHJvYmFibHkgZG9lcyBub3Qg aW1wbGVtZW50ICh5ZXQpIGFsbCB0aGUgcmVxdWlyZWQgU1FMIHF1ZXJ5IHN0dWZmLiANCiAgIA0K ICAgQWxpYXNlcyB3b3JrIGEgbGl0dGxlIGRpZmZlcmVudGx5IC0gaGVyZSB5b3UgZGVmaW5lIGFs aWFzZXMgdG8gdmFsdWUgc2V0cyAoaWUgY29sdW1ucyBvciBYUGF0aHMpDQogICByYXRoZXIgdGhh biB0byB0YWJsZXMuICBUaGlzIGNvdWxkIHByb2JhYmx5IGJlIGRvbmUgbW9yZSBzZW5zaWJseSB1 c2luZyBYUG9pbnRlciBhbmQgSURzLCBidXQgSSB3YW50DQogICB0byB0aGluayBhYm91dCB0aGlz IGZpcnN0LiAgVGhlIGlkZWEgaXMgdGhhdCB0aGUgUmV0dXJuLCBPcmRlckJ5IGFuZCBXaGVyZSBl bGVtZW50cyBzaG91bGQgd29yayBlbnRpcmVseQ0KICAgb2ZmIHRoZSBBbGlhc2VzLCBzbyB0aGF0 IHdlIGNhbiByZXVzZSB0aGVzZSBlbGVtZW50cywgYW5kIHRoZSAnRnJvbScgZWxlbWVudCBpcyBz cGVjaWZpYyBvbmx5IHRvIG9uZQ0KICAgZGF0YWJhc2UuICBBdCBzb21lIHBvaW50IHdlIHNob3Vs ZCB0aGVuIGJlIGFibGUgdG8gc3dhcCB0aGlzIGVsZW1lbnQgb3V0IGluc3RlYWQuDQoNCiAgIFNv IHRoZSBiYXNlIGVsZW1lbnQgc3RydWN0dXJlIGlzIGxpa2UgdGhpczoNCiAgIA0KICAgRnJvbSAo ZGVmaW5lcyBhbGlhc2VzKQ0KICAgUmV0dXJuIChkZWZpbmVzIHJlc3VsdHMpDQogICAgICAtIFNl dCAobGlzdCBvZiBjb2x1bW5zL3BhdGhzIHRoYXQgd2lsbCBiZSByZXR1cm5lZCBpbiB0aGUgcmVz dWx0cykNCiAgICAgIC0gT3JkZXJlZEJ5IChsaXN0IG9mIGtleXMgZGVmaW5pbmcgb3JkZXIgb2Yg cmVzdWx0cykNCiAgICAgIC0gR3JvdXBlZEJ5IChsaXN0IG9mIGtleXMgZGVmaW5pbmcgaG93IHRo ZSByZXN1bHRzIHdpbGwgYmUgZ3JvdXBlZCkNCiAgIFdoZXJlIChkZWZpbmVzIHNlYXJjaCBjcml0 ZXJpYSAtIGllIGV4cHJlc3Npb25zIGJhc2VkIG9uIGFsaWFzZXMpDQoNCiAgIFRlY2huaWNhbCBO b3RlczoNCiAgIA0KICAgVG8gZ2V0IHBvbHltb3JwaGljIHJlbGF0aW9uc2hpcHMgZm9yIHRoZSBl eHByZXNzaW9ucywgSSB1c2Ugc3Vic3RpdHV0aW9uR3JvdXAuICBJJ20gbm90IGVudGlyZWx5IGhh cHB5IHdpdGggDQogICB0aGlzIC0gSSdkIG11Y2ggcmF0aGVyIGdldCBwb2x5bW9ycGhpc20gdGhy b3VnaCB0eXBlIC0gYnV0IGl0IHNlZW1zIHRvIHdvcmsgT0suDQogICANCiAgIEkgYWxzbyBjYW4n dCB3b3JrIG91dCB3aGV0aGVyIGl0J3MgcG9zc2libGUgKG9yIGRlc2lyYWJsZSkgdG8gc3Vic3Rp dHV0ZSBhIHN0cmluZyB2YWx1ZSBpbnN0ZWFkIG9mIGEgdGFnLiAgDQogICBBdCB0aGUgbW9tZW50 LCBmb3IgZXhhbXBsZSwgeW91IGhhdmUgdG8gd3JpdGU6DQogICANCiAgIDxTSU4+PFJlYWxOdW1i ZXI+MC4xMjM8L1JlYWxOdW1iZXI+PC9TSU4+DQogICANCiAgIEJlY2F1c2UgeW91IG1heSB3YW50 IHRvIGluY2x1ZGUgbW9yZSBjb21wbGV4IGV4cHJlc3Npb25zIGluIHRoZXJlLCBzdWNoIGFzOg0K ICAgDQogICA8U0lOPjxBQlM+PFZhbHVlU2V0PlJBPC9WYWx1ZVNldD48L0FCUz48L1NJTj4NCg0K ICAgTWFydGluIEhpbGwsIG1jaEByb2UuYWMudWsNCi0tPg0KDQo8eHM6c2NoZW1hIGVsZW1lbnRG b3JtRGVmYXVsdD0icXVhbGlmaWVkIiB4bWxuczp4cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9Y TUxTY2hlbWEiPg0KDQogIDwhLS0geHM6aW1wb3J0IG5hbWVzcGFjZT0ndXJuOm52by1yZWdpb24n IHNjaGVtYUxvY2F0aW9uPSJmaWxlOi8vYXN0cm9ncmlkL3JlZ2lvbi54c2QiLz4gIC0tPg0KDQog IDwhLS0gQXN0cm9ub21pY2FsIERhdGEgUXVlcnkgLS0+DQogIDx4czplbGVtZW50IG5hbWU9IkFE USI+DQogICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgPHhzOnNlcXVlbmNlPg0KDQogICAgICA8 IS0tIEZyb20gLSBkZWZpbmVzIGFsaWFzZXMgdG8gY29sdW1ucy94cGF0aHMvb3RoZXIgc2V0cyBv ZiB2YWx1ZXMgLS0+DQogICAgICA8IS0tIHBlcmhhcHMgd2Ugc2hvdWxkIHVzZSBJRCBpbnN0ZWFk PyAtLT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9J0Zyb20nIG1pbk9jY3Vycz0iMSIgbWF4T2Nj dXJzPSIxIj4NCiAgICAgICAgIDx4czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAgIDx4czpzZXF1 ZW5jZSBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0ndW5ib3VuZGVkJz4NCiAgICAgICAgICAgICAg IDx4czplbGVtZW50IG1pbk9jY3Vycz0nMCcgbWF4T2NjdXJzPSd1bmJvdW5kZWQnIG5hbWU9J0Nv bHVtbic+DQogICAgICAgICAgICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICAg ICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgICAgICAgICA8eHM6ZWxlbWVu dCBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSIgbmFtZT0iQWxpYXMiIHR5cGU9InhzOnN0cmlu ZyIgLz4NCiAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0iMSIg bWF4T2NjdXJzPSIxIiBuYW1lPSJUYWJsZSIgdHlwZT0ieHM6c3RyaW5nIiAvPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiIG5h bWU9IkNvbHVtbiIgdHlwZT0ieHM6c3RyaW5nIiAvPg0KICAgICAgICAgICAgICAgICAgICAgPC94 czpzZXF1ZW5jZT4NCiAgICAgICAgICAgICAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICAgICAg ICAgICAgICA8L3hzOmVsZW1lbnQ+DQogICAgICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1 cnM9JzAnIG1heE9jY3Vycz0ndW5ib3VuZGVkJyBuYW1lPSdQYXRoJz4NCiAgICAgICAgICAgICAg ICAgIDx4czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4N CiAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0iMSIgbWF4T2Nj dXJzPSIxIiBuYW1lPSJBbGlhcyIgdHlwZT0ieHM6c3RyaW5nIiAvPg0KICAgICAgICAgICAgICAg ICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiIG5hbWU9IlhQ YXRoIiB0eXBlPSJ4czpzdHJpbmciIC8+DQogICAgICAgICAgICAgICAgICAgICA8L3hzOnNlcXVl bmNlPg0KICAgICAgICAgICAgICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAgICAg IDwveHM6ZWxlbWVudD4NCiAgICAgICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAgICA8L3hz OmNvbXBsZXhUeXBlPg0KICAgICAgPC94czplbGVtZW50Pg0KICANCiAgICAgIDwhLS0gU2VsZWN0 IC0gbGlzdCB0aGUgc2V0cyB0byBiZSBnaXZlbiBpbiB0aGUgcmVzdWx0cyAtLT4NCiAgICAgIDwh LS0gaW4gZnV0dXJlIHRoaXMgbWlnaHQgYmUgZXh0ZW5kZWQgdG8gc2F5IG1vcmUgYWJvdXQgaG93 IHRoZSByZXN1bHRzIGFyZSByZXR1cm5lZCAtLT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IlJl dHVybiIgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnPg0KICAgICAgICAgPHhzOmNvbXBsZXhU eXBlPg0KICAgICAgICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgICAgICAgPCEtLSB3aGF0 IHdpbGwgYmUgaW4gdGhlIHNldCBvZiByZXN1bHRzIC0tPg0KICAgICAgICAgICAgICAgPHhzOmVs ZW1lbnQgbmFtZT0nU2V0Jz4NCiAgICAgICAgICAgICAgICAgIDx4czpjb21wbGV4VHlwZT4NCiAg ICAgICAgICAgICAgICAgICAgIDx4czpjaG9pY2U+DQogICAgICAgICAgICAgICAgICAgICAgICA8 eHM6ZWxlbWVudCBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSIgbmFtZT0iQWxsIiBuaWxsYWJs ZT0ndHJ1ZScvPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJz PSIxIiBtYXhPY2N1cnM9J3VuYm91bmRlZCcgcmVmPSdFeHByZXNzaW9uJy8+DQogICAgICAgICAg ICAgICAgICAgICA8L3hzOmNob2ljZT4NCiAgICAgICAgICAgICAgICAgIDwveHM6Y29tcGxleFR5 cGU+DQogICAgICAgICAgICAgICA8L3hzOmVsZW1lbnQ+DQoNCiAgICAgICAgICAgICAgIDwhLS0g T3JkZXIgLSBzb3J0ZWQgb3JkZXIgb2YgcmVzdWx0cy4gIGEgbGlzdCBvZiBrZXlzIChlYWNoIG9u ZSBhbiBleHByZXNzaW9uKSAtLT4NCiAgICAgICAgICAgICAgIDwhLS0gcmF0aGVyIG5hdWdodGls eSBhc3N1bWVzIG9yZGVyIG9mIGNvbHVtbnMgZ2l2ZW4gaW4gdGFnID0gb3JkZXIgcG9zaXRpb24v a2V5IHByaW9yaXR5IC0tPg0KICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0nT3JkZXJl ZEJ5JyBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0nMSc+DQogICAgICAgICAgICAgICAgICA8eHM6 Y29tcGxleFR5cGU+DQogICAgICAgICAgICAgICAgICAgICA8eHM6Y2hvaWNlPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9J3VuYm91 bmRlZCcgbmFtZT0nS2V5Jz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpjb21wbGV4 VHlwZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4 T2NjdXJzPScxJyByZWY9J0V4cHJlc3Npb24nLz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8IS0tIGF0 dHJpYnV0ZSBzcGVjaWZ5aW5nIHdoZXRoZXIgdG8gc29ydCB0aGlzIGtleSBpbiBhc2NlbmRpbmcg b3IgZGVzY2VuZGluZyBvcmRlciAtLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4 czphdHRyaWJ1dGUgbmFtZT0nZGlyZWN0aW9uJz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9J3hzOnN0cmluZyc+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9J2Rlc2NlbmRpbmcnLz4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbnVtZXJhdGlvbiB2 YWx1ZT0nYXNjZW5kaW5nJy8+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC94czpz aW1wbGVUeXBlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC94czphdHRyaWJ1dGU+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgICAgICAg ICAgICAgICAgICAgICAgPC94czplbGVtZW50Pg0KICAgICAgICAgICAgICAgICAgICAgPC94czpj aG9pY2U+DQogICAgICAgICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgICAgICAgICAg ICAgPC94czplbGVtZW50Pg0KICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICA8IS0tIEdy b3VwZWQgQnkgIC0tPg0KICAgICAgICAgICAgICAgPCEtLSByYXRoZXIgbmF1Z2h0aWx5IGFzc3Vt ZXMgb3JkZXIgb2YgY29sdW1ucyBnaXZlbiBpbiB0YWcgPSBvcmRlciBncm91cGluZyAtLT4NCiAg ICAgICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9J0dyb3VwZWRCeScgbWluT2NjdXJzPSIwIiBt YXhPY2N1cnM9JzEnPg0KICAgICAgICAgICAgICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAg ICAgICAgICAgICAgICAgPHhzOmNob2ljZT4NCiAgICAgICAgICAgICAgICAgICAgICAgIDx4czpl bGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPSd1bmJvdW5kZWQnIG5hbWU9J0tleSc+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVmPSdFeHBy ZXNzaW9uJy8+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3hzOnNlcXVlbmNlPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDwveHM6ZWxlbWVudD4NCiAgICAgICAgICAgICAgICAgICAgIDwveHM6Y2hv aWNlPg0KICAgICAgICAgICAgICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAgICAg IDwveHM6ZWxlbWVudD4NCg0KICAgICAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgICAgIDwv eHM6Y29tcGxleFR5cGU+DQogICAgICA8L3hzOmVsZW1lbnQ+DQoNCiAgICAgIDwhLS0gV2hlcmUg LSBzZWxlY3Rpb24vbWF0Y2hpbmcgY3JpdGVyaWEgLS0+DQogICAgICA8eHM6ZWxlbWVudCBuYW1l PSdXaGVyZScgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnPg0KICAgICAgICAgPHhzOmNvbXBs ZXhUeXBlPg0KICAgICAgICAgICAgPHhzOmNob2ljZT4NCiAgICAgICAgICAgICAgIDx4czplbGVt ZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9IkJvb2xlYW5FeHByZXNzaW9uIi8+ DQogICAgICAgICAgICA8L3hzOmNob2ljZT4NCiAgICAgICAgIDwveHM6Y29tcGxleFR5cGU+DQog ICAgICA8L3hzOmVsZW1lbnQ+ICAgICAgIA0KDQogICAgICA8IS0tIGVuZCBBRFEgLS0+DQogICAg ICA8L3hzOnNlcXVlbmNlPg0KICAgIDwveHM6Y29tcGxleFR5cGU+DQogIDwveHM6ZWxlbWVudD4N CiAgDQogICAgDQogIDwhLS0gVGhlIGJhc2ljIGJvb2xlYW4gdW5pdCBvZiBzZWFyY2ggY3JpdGVy aWEgLS0+DQogIDwhLS0gZGVmaW5lcyBhbiBleHByZXNzaW9uIHRoYXQgd2lsbCByZXN1bHQgaW4g YSBib29sZWFuIHllcy9ubyBtYXRjaCAtLT4NCg0KICAgPCEtLSBXZSB1c2Ugc3Vic3RpdHV0aW9u ZyBncm91cHMgdG8gZGVjbGFyZSB3aGF0IGNhbiBiZSB1c2VkIGluIHRoZXNlIHNpdHVhdGlvbnMg LS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdCb29sZWFuRXhwcmVzc2lvbicgYWJzdHJhY3Q9J3Ry dWUnLz4NCg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iTk9UIiBzdWJzdGl0dXRpb25Hcm91cD0iQm9v bGVhbkV4cHJlc3Npb24iPg0KICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICAgICAgPHhz OnNlcXVlbmNlPg0KICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhP Y2N1cnM9JzEnIHJlZj0nQm9vbGVhbkV4cHJlc3Npb24nLz4NCiAgICAgICAgICAgIDwveHM6c2Vx dWVuY2U+DQogICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KDQogICA8 eHM6ZWxlbWVudCBuYW1lPSJBTkQiIHN1YnN0aXR1dGlvbkdyb3VwPSdCb29sZWFuRXhwcmVzc2lv bic+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICA8eHM6c2VxdWVuY2U+DQog ICAgICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzInIG1heE9jY3Vycz0nMicgcmVm PSdCb29sZWFuRXhwcmVzc2lvbicvPg0KICAgICAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAg IDwveHM6Y29tcGxleFR5cGU+DQogICA8L3hzOmVsZW1lbnQ+DQoNCiAgIDx4czplbGVtZW50IG5h bWU9Ik9SIiBzdWJzdGl0dXRpb25Hcm91cD0nQm9vbGVhbkV4cHJlc3Npb24nPg0KICAgICAgPHhz OmNvbXBsZXhUeXBlPg0KICAgICAgICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgICAgICAg PHhzOmVsZW1lbnQgbWluT2NjdXJzPScyJyBtYXhPY2N1cnM9JzInIHJlZj0nQm9vbGVhbkV4cHJl c3Npb24nLz4NCiAgICAgICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICA8L3hzOmNvbXBsZXhU eXBlPg0KICAgPC94czplbGVtZW50Pg0KDQogICA8IS0tIERlZmluZXMgYSBjb21wYXJpc29uIC0t Pg0KICAgPCEtLSBjb21wYXJlcyB0d28gZXhwcmVzc2lvbnMgdGhhdCB3aWxsIHJldHVybiBhIGJv b2xlYW4sIHRoZXNlIGFyZToNCiAgICAgICAgIGVxdWFscw0KICAgICAgICAgZ3JlYXRlciB0aGFu DQogICAgICAgICBncmVhdGVyIHRoYW4gb3IgZXF1YWxzDQogICAgICAgICBsZXNzIHRoYW4gDQog ICAgICAgICBsZXNzIHRoYW4gb3IgZXF1YWxzDQogICAgICAgICBsaWtlDQogICAgLS0+IA0KICAg PHhzOmVsZW1lbnQgbmFtZT0iQ29tcGFyZU51bWJlcnMiIHN1YnN0aXR1dGlvbkdyb3VwPSdCb29s ZWFuRXhwcmVzc2lvbic+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICA8eHM6c2VxdWVu Y2U+DQogICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVm PSdOdW1lcmljYWxFeHByZXNzaW9uJy8+DQogICAgICAgICA8eHM6ZWxlbWVudCByZWY9J0NvbXBh cmVPcGVyYXRvcicvPg0KICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1 cnM9JzEnIHJlZj0nTnVtZXJpY2FsRXhwcmVzc2lvbicvPg0KICAgICAgPC94czpzZXF1ZW5jZT4N CiAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICA8L3hzOmVsZW1lbnQ+DQoNCiAgIDx4czplbGVt ZW50IG5hbWU9IkNvbXBhcmVTdHJpbmdzIiBzdWJzdGl0dXRpb25Hcm91cD0nQm9vbGVhbkV4cHJl c3Npb24nPg0KICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgPHhzOnNlcXVlbmNlPg0KICAg ICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIHJlZj0nU3RyaW5n RXhwcmVzc2lvbicvPg0KICAgICAgICAgPHhzOmVsZW1lbnQgcmVmPSdDb21wYXJlT3BlcmF0b3In Lz4NCiAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9 J1N0cmluZ0V4cHJlc3Npb24nLz4NCiAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICA8L3hzOmNv bXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KDQogICA8IS0tIENvbXBhcmUgT3BlcmF0aW9u IC0gaWUgbGVzcyB0aGFuLCBlcXVhbHMsIGV0YyAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9J0Nv bXBhcmVPcGVyYXRvcicgYWJzdHJhY3Q9J3RydWUnIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6 ZWxlbWVudCBuYW1lPSdFUVVBTFMnIHN1YnN0aXR1dGlvbkdyb3VwPSdDb21wYXJlT3BlcmF0b3In IG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdHUkVBVEVSVEhBTicgc3Vi c3RpdHV0aW9uR3JvdXA9J0NvbXBhcmVPcGVyYXRvcicgbmlsbGFibGU9J3RydWUnLz4NCiAgIDx4 czplbGVtZW50IG5hbWU9J0xFU1NUSEFOJyBzdWJzdGl0dXRpb25Hcm91cD0nQ29tcGFyZU9wZXJh dG9yJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nR1JFQVRFUlRIQU5P UkVRVUFMUycgc3Vic3RpdHV0aW9uR3JvdXA9J0NvbXBhcmVPcGVyYXRvcicgbmlsbGFibGU9J3Ry dWUnLz4NCiAgIDx4czplbGVtZW50IG5hbWU9J0xFU1NUSEFOT1JFUVVBTFMnIHN1YnN0aXR1dGlv bkdyb3VwPSdDb21wYXJlT3BlcmF0b3InIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVu dCBuYW1lPSdMSUtFJyBzdWJzdGl0dXRpb25Hcm91cD0nQ29tcGFyZU9wZXJhdG9yJyBuaWxsYWJs ZT0ndHJ1ZScvPg0KDQoNCiAgIDwhLS0gRGVmaW5lcyBzcGVjaWFsIGFyZWEgc2VhcmNoIHR5cGVz IC0tPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iQ2lyY2xlTWF0Y2giIHN1YnN0aXR1dGlvbkdyb3Vw PSdCb29sZWFuRXhwcmVzc2lvbic+DQogICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHM6 c2VxdWVuY2U+DQogICAgICAgICAgPCEtLSA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0iMSIgbmFtZT0iQ2lyY2xlIiB0eXBlPSJ1cm46bnZvLXJlZ2lvbjpyZWdpb25UeXBlIiAv PiAtLT4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScg bmFtZT0nUkEnIHR5cGU9J3hzOmZsb2F0Jy8+DQogICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2Nj dXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J0RFQycgdHlwZT0neHM6ZmxvYXQnLz4NCiAgICAg ICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nUmFuZ2Un IHR5cGU9J3hzOmZsb2F0Jy8+DQogICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICA8L3hzOmNv bXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KDQogICA8IS0tIERlZmluZSBjcm9zcyBtYXRj aCBzZWFyY2ggLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJYTWF0Y2giIHN1YnN0aXR1dGlvbkdy b3VwPSdCb29sZWFuRXhwcmVzc2lvbic+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAg IDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9j Y3Vycz0nMScgbmFtZT0nU29tZXRoaW5nJyB0eXBlPSd4czpmbG9hdCcvPg0KICAgICAgICA8L3hz OnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgIDwveHM6ZWxlbWVudD4NCg0K ICA8IS0tIEEgR2VuZXJhbCBFeHByZXNzaW9uIC0tPg0KICA8IS0tIGhlYWQgb2YgdGhlIE51bWVy aWNhbC9TdHJpbmdFeHByZXNzaW9uIHRyZWUgcG9seW1vcnBoaXNtIHRyZWUsIHZlcnkgYWJzdHJh Y3QgLS0+DQogIDx4czplbGVtZW50IG5hbWU9J0V4cHJlc3Npb24nIGFic3RyYWN0PSd0cnVlJy8+ DQoNCiAgIA0KICA8IS0tIEFuIE51bWVyaWNhbEV4cHJlc3Npb24gcmV0dXJucyBhIChzY2FsYXIs IGllIG5vdCBhIHZlY3RvcikgdmFsdWUgLS0+DQogIDwhLS0gSSBjYW4ndCBzZWUgYW55d2F5IGFy b3VuZCBoYXZpbmcgdG8gYWRkIGEgJ3ZhbHVlJy8nbGl0ZXJhbCcgdGFnIC0tPg0KICA8eHM6ZWxl bWVudCBuYW1lPSdOdW1lcmljYWxFeHByZXNzaW9uJyBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVz c2lvbicgYWJzdHJhY3Q9J3RydWUnLz4NCg0KICA8IS0tIHdlICpjYW4qIGp1c3QgZ2l2ZSBhIHN0 cmluZyBhcyBhIHZhbHVlLCBidXQgd2UgbWlnaHQgd2FudCB0byBiZSBtb3JlIHNwZWNpZmljIC0t Pg0KICA8eHM6ZWxlbWVudCBuYW1lPSdJbnRlZ2VyJyBzdWJzdGl0dXRpb25Hcm91cD0nTnVtZXJp Y2FsRXhwcmVzc2lvbicgdHlwZT0neHM6aW50Jy8+DQogIDx4czplbGVtZW50IG5hbWU9J1JlYWxO dW1iZXInIHN1YnN0aXR1dGlvbkdyb3VwPSdOdW1lcmljYWxFeHByZXNzaW9uJyB0eXBlPSd4czpk b3VibGUnLz4NCiAgDQogICA8IS0tIFVzZWZ1bCB0eXBlIGZvciBhIGxvdCBvZiBmdW5jdGlvbnMg dGhhdCB3cmFwIGEgc2luZ2xlIE51bWVyaWNhbEV4cHJlc3Npb24gLS0+DQogICA8eHM6Y29tcGxl eFR5cGUgbmFtZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iID4NCiAgICAgPHhzOnNl cXVlbmNlPg0KICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScg cmVmPSJOdW1lcmljYWxFeHByZXNzaW9uIi8+DQogICAgIDwveHM6c2VxdWVuY2U+DQogICA8L3hz OmNvbXBsZXhUeXBlPg0KICANCg0KICAgPCEtLSAnVW5hcnknIC0gbmVnYXRpdmUvcG9zaXRpdmUg dmFsdWVzIC0tPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nTmVnYXRpdmVPZicgIHN1YnN0aXR1dGlv bkdyb3VwPSdOdW1lcmljYWxFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0 aW9uT2ZOdW1lcmljYWxFeHByZXNzaW9uIi8+DQogICAgDQogICA8IS0tIERlZmluZXMgbWF0aGVt YXRpY2FsIGZ1bmN0aW9ucyAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9IlNJTiIgc3Vic3RpdHV0 aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVu Y3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5hbWU9IkNPUyIg c3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScg dHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5h bWU9IlRBTiIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxl PSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czpl bGVtZW50IG5hbWU9IkNPVCIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24n IG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4N CiAgIDx4czplbGVtZW50IG5hbWU9IkFTSU4iIHN1YnN0aXR1dGlvbkdyb3VwPSdOdW1lcmljYWxF eHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0aW9uT2ZOdW1lcmljYWxFeHBy ZXNzaW9uIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJBQ09TIiBzdWJzdGl0dXRpb25Hcm91cD0n TnVtZXJpY2FsRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mTnVt ZXJpY2FsRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iQVRBTiIgc3Vic3RpdHV0 aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVu Y3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5hbWU9IkFCUyIg c3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScg dHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5h bWU9IkVYUCIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxl PSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4czpl bGVtZW50IG5hbWU9IlNRUlQiIHN1YnN0aXR1dGlvbkdyb3VwPSdOdW1lcmljYWxFeHByZXNzaW9u JyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0aW9uT2ZOdW1lcmljYWxFeHByZXNzaW9uIi8+ DQogICA8eHM6ZWxlbWVudCBuYW1lPSJDRUlMSU5HIiBzdWJzdGl0dXRpb25Hcm91cD0nTnVtZXJp Y2FsRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mTnVtZXJpY2Fs RXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iRkxPT1IiIHN1YnN0aXR1dGlvbkdy b3VwPSdOdW1lcmljYWxFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0aW9u T2ZOdW1lcmljYWxFeHByZXNzaW9uIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJERUdSRUVTIiBz dWJzdGl0dXRpb25Hcm91cD0nTnVtZXJpY2FsRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0 eXBlPSJGdW5jdGlvbk9mTnVtZXJpY2FsRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFt ZT0iUkFESUFOUyIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxh YmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgIDx4 czplbGVtZW50IG5hbWU9IlNRVUFSRSIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJl c3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Np b24iLz4NCg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nUEknIHN1YnN0aXR1dGlvbkdyb3VwPSdOdW1l cmljYWxFeHByZXNzaW9uJyBuaWxsYWJsZT0ndHJ1ZScvPg0KDQogICA8eHM6ZWxlbWVudCBuYW1l PSJQT1dFUiIgc3Vic3RpdHV0aW9uR3JvdXA9J051bWVyaWNhbEV4cHJlc3Npb24nIG5pbGxhYmxl PSdmYWxzZScgPg0KICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHM6c2VxdWVuY2U+ DQogICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyBuYW1l PSdNYW50aXNzYScgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4NCiAgICAg ICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J0V4cG9u ZW50JyB0eXBlPSJGdW5jdGlvbk9mTnVtZXJpY2FsRXhwcmVzc2lvbiIvPg0KICAgICAgICA8L3hz OnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgIDwveHM6ZWxlbWVudD4NCg0K ICAgPHhzOmVsZW1lbnQgbmFtZT0iTE9HIiBzdWJzdGl0dXRpb25Hcm91cD0nTnVtZXJpY2FsRXhw cmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyA+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAg ICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBt YXhPY2N1cnM9JzEnIG5hbWU9J0Jhc2UnIHR5cGU9IkZ1bmN0aW9uT2ZOdW1lcmljYWxFeHByZXNz aW9uIi8+DQogICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScx JyBuYW1lPSdBcmd1bWVudCcgdHlwZT0iRnVuY3Rpb25PZk51bWVyaWNhbEV4cHJlc3Npb24iLz4N CiAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICA8L3hz OmVsZW1lbnQ+DQoNCg0KICAgPCEtLSBDb21wbGV4IE51bWVyaWNhbEV4cHJlc3Npb24gLSBpZSBh ZGRpbmcgdGhpbmdzIHVwIGV0YyAtLT4gIA0KICAgPHhzOmVsZW1lbnQgbmFtZT0nTWF0aE9wZXJh dGlvbicgc3Vic3RpdHV0aW9uR3JvdXA9Ik51bWVyaWNhbEV4cHJlc3Npb24iPg0KICAgICAgPHhz OmNvbXBsZXhUeXBlPg0KICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgPHhzOmVsZW1lbnQg bWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIHJlZj0nTnVtZXJpY2FsRXhwcmVzc2lvbicvPg0K ICAgICAgICAgPHhzOmVsZW1lbnQgcmVmPSdNYXRoT3BlcmF0b3InLz4NCiAgICAgICAgIDx4czpl bGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9J051bWVyaWNhbEV4cHJlc3Np b24nLz4NCiAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAg PC94czplbGVtZW50PiAgIA0KDQogICA8IS0tIE9wZXJhdG9yIC0gaWUgYWRkLCBzdWJ0cmFjdCwg ZXRjIC0tPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nTWF0aE9wZXJhdG9yJyBhYnN0cmFjdD0ndHJ1 ZScgbmlsbGFibGU9J3RydWUnLz4NCiAgIDx4czplbGVtZW50IG5hbWU9J0FERFRPJyBzdWJzdGl0 dXRpb25Hcm91cD0nTWF0aE9wZXJhdG9yJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhzOmVsZW1l bnQgbmFtZT0nU1VCVFJBQ1RGUk9NJyBzdWJzdGl0dXRpb25Hcm91cD0nTWF0aE9wZXJhdG9yJyBu aWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nTVVMVElQTFlCWScgc3Vic3Rp dHV0aW9uR3JvdXA9J01hdGhPcGVyYXRvcicgbmlsbGFibGU9J3RydWUnLz4NCiAgIDx4czplbGVt ZW50IG5hbWU9J0RJVklERUJZJyBzdWJzdGl0dXRpb25Hcm91cD0nTWF0aE9wZXJhdG9yJyBuaWxs YWJsZT0ndHJ1ZScvPg0KDQogDQogICA8IS0tIERlZmluZXMgY29sdW1uIHJhbmdlIGZ1bmN0aW9u cyAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9J1NVTScgc3Vic3RpdHV0aW9uR3JvdXA9Ik51bWVy aWNhbEV4cHJlc3Npb24iIHR5cGU9IlZhbHVlU2V0cyIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0n QVZHJyBzdWJzdGl0dXRpb25Hcm91cD0iTnVtZXJpY2FsRXhwcmVzc2lvbiIgdHlwZT0iVmFsdWVT ZXRzIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdNSU4nIHN1YnN0aXR1dGlvbkdyb3VwPSJOdW1l cmljYWxFeHByZXNzaW9uIiB0eXBlPSJWYWx1ZVNldHMiLz4NCiAgIDx4czplbGVtZW50IG5hbWU9 J01BWCcgc3Vic3RpdHV0aW9uR3JvdXA9Ik51bWVyaWNhbEV4cHJlc3Npb24iIHR5cGU9IlZhbHVl U2V0cyIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nQ09VTlQnIHN1YnN0aXR1dGlvbkdyb3VwPSJO dW1lcmljYWxFeHByZXNzaW9uIiB0eXBlPSJWYWx1ZVNldHMiLz4NCg0KDQogICA8IS0tIERlZmlu ZXMgYSByYW5nZSBvciBlbnVtZXJhdGlvbiBvZiBjb2x1bW5zIC0tPg0KICAgPHhzOmNvbXBsZXhU eXBlIG5hbWU9J1ZhbHVlU2V0cyc+DQogICAgICA8eHM6Y2hvaWNlIG1pbk9jY3Vycz0nMScgbWF4 T2NjdXJzPSIxIj4NCiAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJz PScxJyBuYW1lPSdSYW5nZScgdHlwZT0neHM6c3RyaW5nJy8+DQogICAgICAgICA8eHM6ZWxlbWVu dCBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0ndW5ib3VuZGVkJyByZWY9J1ZhbHVlU2V0Jy8+DQog ICAgICA8L3hzOmNob2ljZT4NCiAgIDwveHM6Y29tcGxleFR5cGU+DQoNCg0KICA8IS0tIEEgU3Ry aW5nRXhwcmVzc2lvbiByZXR1cm5zIGEgc3RyaW5nIC0tPg0KICA8IS0tIGZ1bm55IHRoYXQgLS0+ DQogIDx4czplbGVtZW50IG5hbWU9J1N0cmluZ0V4cHJlc3Npb24nIHN1YnN0aXR1dGlvbkdyb3Vw PSdFeHByZXNzaW9uJyBhYnN0cmFjdD0ndHJ1ZScvPg0KDQogIDx4czplbGVtZW50IG5hbWU9J1N0 cmluZycgc3Vic3RpdHV0aW9uR3JvdXA9J1N0cmluZ0V4cHJlc3Npb24nIHR5cGU9J3hzOnN0cmlu ZycvPg0KDQogICA8IS0tIFVzZWZ1bCB0eXBlIGZvciBmdW5jdGlvbnMgdGhhdCB3cmFwIGEgU3Ry aW5nRXhwcmVzc2lvbiAtLT4NCiAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJGdW5jdGlvbk9mU3Ry aW5nIiA+DQogICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJz PScxJyBtYXhPY2N1cnM9JzEnIHJlZj0iU3RyaW5nRXhwcmVzc2lvbiIvPg0KICAgICA8L3hzOnNl cXVlbmNlPg0KICAgPC94czpjb21wbGV4VHlwZT4NCg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iVHJ1 bmNhdGUiIHN1YnN0aXR1dGlvbkdyb3VwPSdTdHJpbmdFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFs c2UnIHR5cGU9IkZ1bmN0aW9uT2ZTdHJpbmciLz4NCg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iQXBw ZW5kIiBzdWJzdGl0dXRpb25Hcm91cD0nU3RyaW5nRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNl JyA+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAg ICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J0Jhc2Un IHR5cGU9IkZ1bmN0aW9uT2ZOdW1lcmljYWxFeHByZXNzaW9uIi8+DQogICAgICAgICAgIDx4czpl bGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyBuYW1lPSdBcHBlbmQnIHR5cGU9IkZ1 bmN0aW9uT2ZOdW1lcmljYWxFeHByZXNzaW9uIi8+DQogICAgICAgIDwveHM6c2VxdWVuY2U+DQog ICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KICAgDQoNCiAgIDwhLS0g RGVmaW5lcyBob3cgYSB2YWx1ZXNldCAoZWcgY29sdW1uLCB4cGF0aCkgaXMgcmVmZXJlbmNlZCBp biBnZW5lcmFsIC0tPg0KICAgPCEtLSBlaXRoZXIgZGlyZWN0bHkgYnkgQWxpYXMgb3IgYnkgRGJS ZWYgb3IgeHBhdGggZXRjIC0tPg0KICA8eHM6ZWxlbWVudCBuYW1lPSdWYWx1ZVNldCcgYWJzdHJh Y3Q9InRydWUiIHN1YnN0aXR1dGlvbkdyb3VwPSdFeHByZXNzaW9uJy8+DQoNCiAgPCEtLSBEZWZp bmVzIGFuIGFsaWFzIC0gcmVmZXJzIHRvIEZST00gLS0+DQogIDx4czplbGVtZW50IG5hbWU9J0Fs aWFzJyBzdWJzdGl0dXRpb25Hcm91cD0nVmFsdWVTZXQnIHR5cGU9J3hzOnN0cmluZycvPg0KDQog IDwhLS0gRGVmaW5lcyBob3cgYSBjb2x1bW4gaXMgcmVmZXJlbmNlZCBmcm9tIGFuIFJEQk1TIC0g YnkgdGFibGUgJiB0aGUgbmFtZSBvZiB0aGUgY29sdW1uIHdpdGhpbiB0aGF0IHRhYmxlIC0tPg0K ICA8eHM6ZWxlbWVudCBuYW1lPSdSZGJtc0NvbHVtbicgc3Vic3RpdHV0aW9uR3JvdXA9J1ZhbHVl U2V0Jz4NCiAgICAgIDx4czpjb21wbGV4VHlwZT4NCiAgICAgICAgIDx4czpzZXF1ZW5jZT4NCiAg ICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPScxJyBuYW1lPSdU YWJsZScgdHlwZT0neHM6c3RyaW5nJy8+DQogICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1 cnM9IjEiIG1heE9jY3Vycz0nMScgbmFtZT0nQ29sdW1uTmFtZScgdHlwZT0neHM6c3RyaW5nJy8+ DQogICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgPC94 czplbGVtZW50Pg0KDQogIDwhLS0gRGVmaW5lcyBob3cgYW4geHBhdGggdmFsdWVzZXQgLS0+DQog IDx4czplbGVtZW50IG5hbWU9J1hQYXRoJyBzdWJzdGl0dXRpb25Hcm91cD0nVmFsdWVTZXQnIHR5 cGU9J3hzOnN0cmluZycvPg0KICANCg0KICANCjwveHM6c2NoZW1hPg0KICAgICAgDQo= ---MOQ1075831628c785687fa258fd7c08763513435fb7d6 Content-Type: text/xml; name="SampleNewADQL.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SampleNewADQL.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0gR2VuZXJhdGVkIGZy b20gTmV3QURRTC54c2QgYnkgWE1MQnVkZHktLT4NCjxBRFEgeHNpOm5vTmFtZXNwYWNlU2NoZW1h TG9jYXRpb249ImZpbGU6Ly8vQzovZWNsaXBzZS93b3Jrc3BhY2UvQURRTFNjaGVtYS9OZXdBRFFM LnhzZCINCgl4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rh bmNlIj4NCgk8RnJvbT4NCgkJPFBhdGg+DQoJCQk8QWxpYXM+RWxpcHRpY2l0eTwvQWxpYXM+DQoJ CQk8WFBhdGg+dGhpbmd5L3RoaW5neS90aGluZ3kvZXRjPC9YUGF0aD4NCgkJPC9QYXRoPg0KCQk8 Q29sdW1uPg0KCQkgICA8QWxpYXM+UkE8L0FsaWFzPg0KCQkgICA8VGFibGU+V29iYmxlPC9UYWJs ZT4NCgkJICAgPENvbHVtbj5SQV9PQko8L0NvbHVtbj4NCgkJPC9Db2x1bW4+DQoJCTxQYXRoPg0K CQkJPEFsaWFzPk1hZ25pdHVkZTwvQWxpYXM+DQoJCQk8WFBhdGg+dGhhbmd5L3RoYW5neS90aGFu Z3kvZXRjPC9YUGF0aD4NCgkJPC9QYXRoPg0KCQk8Q29sdW1uPg0KCQkgICA8QWxpYXM+REVDPC9B bGlhcz4NCgkJICAgPFRhYmxlPldvYmJsZTwvVGFibGU+DQoJCSAgIDxDb2x1bW4+REVDTF9PQko8 L0NvbHVtbj4NCgkJPC9Db2x1bW4+DQoJPC9Gcm9tPg0KCTxSZXR1cm4+DQoJCTxTZXQ+DQoJCQk8 QWxsLz4NCgkJPC9TZXQ+DQoJCTxPcmRlcmVkQnk+DQoJCQk8S2V5IGRpcmVjdGlvbj0iZGVzY2Vu ZGluZyI+PEFsaWFzPkRFQzwvQWxpYXM+PC9LZXk+DQoJCQk8S2V5IGRpcmVjdGlvbj0iYXNjZW5k aW5nIj48QWxpYXM+UkE8L0FsaWFzPjwvS2V5Pg0KCQkJPEtleSBkaXJlY3Rpb249ImFzY2VuZGlu ZyI+PEFsaWFzPk1hZ25pdHVkZTwvQWxpYXM+PC9LZXk+DQoJCQk8S2V5IGRpcmVjdGlvbj0iZGVz Y2VuZGluZyI+PEFsaWFzPkVsaXB0aWNpdHk8L0FsaWFzPjwvS2V5Pg0KCQk8L09yZGVyZWRCeT4N CgkJPEdyb3VwZWRCeT4NCgkJCTxLZXk+PFNJTj48QWxpYXM+UkE8L0FsaWFzPjwvU0lOPjwvS2V5 Pg0KCQk8L0dyb3VwZWRCeT4NCgk8L1JldHVybj4NCgk8V2hlcmU+DQoJICAgPEFORD4NCgkgICAg ICA8Q2lyY2xlTWF0Y2g+DQogICAgICAgICAgICA8UkE+MTI8L1JBPgkNCiAgICAgICAgICAgIDxE RUM+MTM8L0RFQz4NCiAgICAgICAgICAgIDxSYWRpdXM+MzwvUmFkaXVzPg0KCSAgICAgIDwvQ2ly Y2xlTWF0Y2g+DQogICAJCTxDb21wYXJlPg0KICAgICAgCSAgIDxDb25jYXRpbmF0ZT48QmFzZT48 U3RyaW5nPkJhbmFuYTwvU3RyaW5nPjwvQmFzZT48QXBwZW5kPjxTdHJpbmc+UmVwdWJsaWM8L1N0 cmluZz48L0FwcGVuZD48L0NvbmNhdGluYXRlPg0KICAgICAgICAgCTxMRVNTVEhBTk9SRVFVQUxT Lz4NCiAgICAgICAgICAgIDxBbGlhcz5FbGlwdGljaXR5PC9BbGlhcz4NCiAgICAgICAgIDwvQ29t cGFyZT4NCgkJPC9BTkQ+DQoJPC9XaGVyZT4NCjwvQURRPg0K ---MOQ1075831628c785687fa258fd7c08763513435fb7d6-- From owner-voql@eso.org Tue Feb 3 19:42: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 i13IgIDk013057 for ; Tue, 3 Feb 2004 19:42:18 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i13IgI1m013056 for voql-outgoing; Tue, 3 Feb 2004 19:42:18 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i13IgEDk013036 for ; Tue, 3 Feb 2004 19:42:14 +0100 (MET) Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i13IgBEY021806 for ; Tue, 3 Feb 2004 19:42:12 +0100 (CET) Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149]) (authenticated bits=0) by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i13IfgtW024143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 3 Feb 2004 10:41:43 -0800 Message-ID: <014101c3ea85$bbf15090$0c0ba8c0@cacr.caltech.edu> From: "Roy Williams" To: "martin hill" Cc: "voql" References: <1075831628.401fe34c38b42@netmail.pipex.net> Subject: Re: SADQL schema Date: Tue, 3 Feb 2004 10:44:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 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-voql@eso.org Precedence: bulk Reply-To: "Roy Williams" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin Please relate your proposal to the original ADQL spec, so I can understand better what you are proposing. (1) Is your SADQL a subset of full ADQL? If so, it would fit in well with the architecture -- we can have different levels of compliance for different levels of complexity. (2) If it is not a subset, please tell us what falls outside of the original ADQL specification. For example, I didn't notice XPath syntax in ADQL..... (3) If you believe that ADQL is too complex, can you say specifically what you think should be removed? Roy -------- Caltech Center for Advanced Computing Research roy@cacr.caltech.edu 626 395 3670 From owner-voql@eso.org Wed Feb 4 04:20:18 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 i143JoU8021523 for ; Wed, 4 Feb 2004 04:19:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i143Jnow021518 for voql-outgoing; Wed, 4 Feb 2004 04:19:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i143JlU8021502 for ; Wed, 4 Feb 2004 04:19:47 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i143JiEY012688 for ; Wed, 4 Feb 2004 04:19:45 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id MAA26652; Wed, 4 Feb 2004 12:19:37 +0900 (JST) Message-Id: <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 04 Feb 2004 12:19:36 +0900 To: martin hill , voql@ivoa.net From: Masatoshi OHISHI Subject: Re: SADQL schema In-Reply-To: <1075831628.401fe34c38b42@netmail.pipex.net> References: <1075831628.401fe34c38b42@netmail.pipex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, I am so surprized to see your proposal. In our agreements during previous interoperability meetings, we decided to develop SQL-based query language, which is now called as the ADQL, and to develop XML-based query language as a long-term project. The reason why I am so surprized is that your proposal seems to me as a kick-off for our long-term work, before standarizing our first-step language. I strongly think that we need to deveop each VO as early as possible, based on our current (+ improved) ADQL, to demonstrate that VOs are REALLY productive in astronomical communities in the world. Even if current ADQL has limited functionality and current VO can't do ALL requests from various astronomers, this is a crucial step for our future. Otherwide we will fail to get budget to develop VOs with much better functionalities. What is your intension to propose ADQL2 ? Do you want to develop more powerful query language before outputting a lot of scientific results ? Cheers, Masatoshi From owner-voql@eso.org Wed Feb 4 09:38:18 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 i148c1U8029273 for ; Wed, 4 Feb 2004 09:38:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i148c1B0029272 for voql-outgoing; Wed, 4 Feb 2004 09:38:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i148bvU8029258 for ; Wed, 4 Feb 2004 09:37:58 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i148buWR007902 for ; Wed, 4 Feb 2004 09:37:56 +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 1AoIXj-0005wo-CY for voql@ivoa.net; Wed, 04 Feb 2004 08:37:55 +0000 Received: (qmail 15633 invoked from network); 4 Feb 2004 08:38:15 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 4 Feb 2004 08:38:15 -0000 From: "Tony Linde" To: "'martin hill'" , Subject: RE: SADQL schema Date: Wed, 4 Feb 2004 08:39:09 -0000 Organization: University of Leicester Message-ID: <005401c3eafa$5b69cd90$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 In-Reply-To: <1075831628.401fe34c38b42@netmail.pipex.net> 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 i148c0U8029269 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Attached is both schema and an example document for ADQL v2, The document is invalid under the schema (according to xml spy anyway). > Aliases, so that we can reuse these elements across different > datacenters, and Sounds like UCDs. Non? > I also can't work out whether it's possible (or desirable) ... I think that straying far from SQL means that we are into defining our own language which, as Jim has pointed out, is fraught with difficulties. And if we are going to do that, I'd rather it was based on XQuery rather than sql. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of martin hill > Sent: 03 February 2004 18:07 > To: voql@ivoa.net > Subject: SADQL schema > ... From owner-voql@eso.org Wed Feb 4 10:08:28 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 i1498DU8005875 for ; Wed, 4 Feb 2004 10:08:13 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i1498DVv005874 for voql-outgoing; Wed, 4 Feb 2004 10:08:13 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14989U8005866 for ; Wed, 4 Feb 2004 10:08:09 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14987EY022431 for ; Wed, 4 Feb 2004 10:08:08 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14986m7029277 for ; Wed, 4 Feb 2004 09:08:06 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14986pC029276 for voql@ivoa.net; Wed, 4 Feb 2004 09:08:06 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 09:08:06 +0000 Message-ID: <1075885686.4020b676632e1@netmail.pipex.net> Date: Wed, 4 Feb 2004 09:08:06 +0000 From: martin hill To: voql Subject: Re: SADQL schema References: <1075831628.401fe34c38b42@netmail.pipex.net> <014101c3ea85$bbf15090$0c0ba8c0@cacr.caltech.edu> In-Reply-To: <014101c3ea85$bbf15090$0c0ba8c0@cacr.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Roy SADQL has very little to do with ADQL except a common purpose. There have been several comments on this list about the difficulties of using ADQL in practice. It was generated automatically for use by tools rather than by humans, but we at Astrogrid, who are building services that use it, are finding in practice that humans do need to use it. In summary: It is very verbose, far too much to expect Astronomers to use it. It is also type/syntax-based rather than information based, which makes it hard to build GUI QueryBuilders out of it. So SADQL is an attempt to produce a human-usable query language. It is based on SQL syntax (From, Where, 'Select'='Return' etc) but I realised when writing it that it would be relatively easy to add XPath capability. I did originally start with the existing ADQL schema to see about cutting bits out to simplify it, but this became a difficult job - again, I was working with a machine-generated schema which is hard. It worked out much easier to start from scratch, and it's not as if there is much code out there that requires change at this stage. Cheers, Martin Quoting Roy Williams : > Martin > > Please relate your proposal to the original ADQL spec, so I can understand > better what you are proposing. > > (1) Is your SADQL a subset of full ADQL? If so, it would fit in well with > the architecture -- we can have different levels of compliance for different > levels of complexity. > > (2) If it is not a subset, please tell us what falls outside of the original > ADQL specification. For example, I didn't notice XPath syntax in ADQL..... > > (3) If you believe that ADQL is too complex, can you say specifically what > you think should be removed? > > Roy > > -------- > Caltech Center for Advanced Computing Research > roy@cacr.caltech.edu > 626 395 3670 > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 10:11:08 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 i149AsU8006447 for ; Wed, 4 Feb 2004 10:10:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i149AsaQ006446 for voql-outgoing; Wed, 4 Feb 2004 10:10:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i149AoU8006433 for ; Wed, 4 Feb 2004 10:10:50 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i149AnWR009409 for ; Wed, 4 Feb 2004 10:10:49 +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 1AoJ3Y-00013R-4m for voql@ivoa.net; Wed, 04 Feb 2004 09:10:48 +0000 Received: (qmail 22713 invoked from network); 4 Feb 2004 09:11:04 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 4 Feb 2004 09:11:04 -0000 From: "Tony Linde" To: "'voql'" Subject: RE: SADQL schema Date: Wed, 4 Feb 2004 09:11:57 -0000 Organization: University of Leicester Message-ID: <005701c3eafe$f0a73ab0$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 In-Reply-To: <014101c3ea85$bbf15090$0c0ba8c0@cacr.caltech.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/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id i149ArU8006441 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > (3) If you believe that ADQL is too complex, can you say > specifically what you think should be removed? My own feeling is that the current version is workable (has worked, is working) but we should see if we can remove one or more of the layers - thosewhich a parser might need to distinguish but we needn't specify. Eg, to take a value in a where clause, it is specified as: 4.56 where I would have thought we could get away with 4.56 or, at the most: 4.56 in order to differentiate string vs number literal. But I must admit that whenever I try to prune the language myself, I rapidly get out of my depth - is there a language developer in the house?? :) Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Roy Williams > Sent: 03 February 2004 18:44 > To: martin hill > Cc: voql > Subject: Re: SADQL schema > ... From owner-voql@eso.org Wed Feb 4 10:17:08 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 i149GsU8007341 for ; Wed, 4 Feb 2004 10:16:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i149Gs81007340 for voql-outgoing; Wed, 4 Feb 2004 10:16:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i149GqU8007329 for ; Wed, 4 Feb 2004 10:16:52 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i149GoEY022754 for ; Wed, 4 Feb 2004 10:16:50 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i149Gnm7029910 for ; Wed, 4 Feb 2004 09:16:49 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i149Gms6029906 for voql@ivoa.net; Wed, 4 Feb 2004 09:16:48 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 09:16:48 +0000 Message-ID: <1075886208.4020b88034b42@netmail.pipex.net> Date: Wed, 4 Feb 2004 09:16:48 +0000 From: martin hill To: voql@ivoa.net Subject: Re: SADQL schema References: <1075831628.401fe34c38b42@netmail.pipex.net> <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> In-Reply-To: <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi (& all) I very obviously haven't explained properly what SADQL was for - probably because I've been so noisy on this list recently so I've a better track of it! It is meant as a replacement to the existing ADQL, which has proved difficult to use in practice. SADQL is not meant as the next query layer in VOQL! It *is* meant as our first-step language. The reason I am proposing a completely new schema rather than trying to modify the existing one is: 1) It's very hard modifying the existing machine-generated schema. 2) The existing schema is based on syntax rather than human-readable elements anyway. 3) There's no real advantage to making extensive modifications to a schema compared to a rewrite 4) It's early days - we *should* be willing to change & rewrite at this stage, before we have invested heavily in code. Note that we at AstroGrid have a fair amount of ADQL processing code - and we *want* to rewrite for a simpler ADQL! Hope that helps... Martin Quoting Masatoshi OHISHI : > Martin, > > I am so surprized to see your proposal. > > In our agreements during previous interoperability meetings, we decided to > develop SQL-based query language, which is now called as the ADQL, and > to develop XML-based query language as a long-term project. > > The reason why I am so surprized is that your proposal seems to me as > a kick-off for our long-term work, before standarizing our first-step > language. > > I strongly think that we need to deveop each VO as early as possible, based > on our current (+ improved) ADQL, to demonstrate that VOs are REALLY > productive in astronomical communities in the world. Even if current ADQL > has > limited functionality and current VO can't do ALL requests from various > astronomers, this is a crucial step for our future. Otherwide we will fail > to > get budget to develop VOs with much better functionalities. > > What is your intension to propose ADQL2 ? Do you want to develop more > powerful > query language before outputting a lot of scientific results ? > > Cheers, > > Masatoshi > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 10:33:48 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 i149XUU8009775 for ; Wed, 4 Feb 2004 10:33:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i149XUWU009774 for voql-outgoing; Wed, 4 Feb 2004 10:33:30 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i149XSU8009758 for ; Wed, 4 Feb 2004 10:33:28 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i149XQEY023419 for ; Wed, 4 Feb 2004 10:33:26 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i149XPm7030947; Wed, 4 Feb 2004 09:33:25 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i149XPw8030946; Wed, 4 Feb 2004 09:33:25 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 09:33:25 +0000 Message-ID: <1075887205.4020bc650926b@netmail.pipex.net> Date: Wed, 4 Feb 2004 09:33:25 +0000 From: martin hill To: ael@star.le.ac.uk Cc: voql@ivoa.net Subject: RE: SADQL schema (valid...) References: <005401c3eafa$5b69cd90$6124d28f@STAR.LE.AC.UK> In-Reply-To: <005401c3eafa$5b69cd90$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1075887204f94650e5beca624c4b87aec6ca705320" User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This message is in MIME format. ---MOQ1075887204f94650e5beca624c4b87aec6ca705320 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Aaargh, I sent out a slightly old version. Still it seems no-one's checked it really, so ho hum. The Aliases are not really UCDs - Aliases describe actual columns in specific tables in specific databases. Whereas UCDs are not (meant to be) that specific. We might use UCDs to link and Alias from one query up with specific columns in a specific database but this is another issue altogether. NB - SADQL really is very similar in structure to SQL - it's just that each element is tokenised by XML elements rather than by spaces and brackets. Ignore the XPath bit which may be a red herring and hasn't been tested anyway. Attached is the schema and XML document that validates under XML Buddy, and has more sensible values... Martin Quoting Tony Linde : > > Attached is both schema and an example document for ADQL v2, > > The document is invalid under the schema (according to xml spy anyway). > > > Aliases, so that we can reuse these elements across different > > datacenters, and > > Sounds like UCDs. Non? > > > I also can't work out whether it's possible (or desirable) ... > > I think that straying far from SQL means that we are into defining our own > language which, as Jim has pointed out, is fraught with difficulties. And if > we are going to do that, I'd rather it was based on XQuery rather than sql. > > Cheers, > Tony. > > > -----Original Message----- > > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > > Behalf Of martin hill > > Sent: 03 February 2004 18:07 > > To: voql@ivoa.net > > Subject: SADQL schema > > ... > > -- Martin Hill 07901 55 24 66 www.mchill.net ---MOQ1075887204f94650e5beca624c4b87aec6ca705320 Content-Type: application/octet-stream; name="NewADQL.xsd" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="NewADQL.xsd" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCg0KPCEtLSANCiAgICRJZCQN Cg0KICAgRGVmaW5pdGlvbiBTY2hlbWEgZm9yIGFuIEFzdHJvbm9taWNhbCBEYXRhIFF1ZXJ5IExh bmd1YWdlLg0KICAgDQogICBUaGlzIGlzIGludGVuZGVkIHRvIGJlIGEgcXVlcnktb25seSBsYW5n dWFnZS4NCiAgIA0KICAgSXQgaXMgYmFzZWQgb24gU1FMLCBidXQgcHJvYmFibHkgZG9lcyBub3Qg aW1wbGVtZW50ICh5ZXQpIGFsbCB0aGUgcmVxdWlyZWQgU1FMIHF1ZXJ5IHN0dWZmLiANCiAgIA0K ICAgQWxpYXNlcyB3b3JrIGEgbGl0dGxlIGRpZmZlcmVudGx5IC0gaGVyZSB5b3UgZGVmaW5lIGFs aWFzZXMgdG8gdmFsdWUgc2V0cyAoaWUgY29sdW1ucyBvciBYUGF0aHMpDQogICByYXRoZXIgdGhh biB0byB0YWJsZXMuICBUaGlzIGNvdWxkIHByb2JhYmx5IGJlIGRvbmUgbW9yZSBzZW5zaWJseSB1 c2luZyBYUG9pbnRlciBhbmQgSURzLCBidXQgSSB3YW50DQogICB0byB0aGluayBhYm91dCB0aGlz IGZpcnN0LiAgVGhlIGlkZWEgaXMgdGhhdCB0aGUgUmV0dXJuLCBPcmRlckJ5IGFuZCBXaGVyZSBl bGVtZW50cyBzaG91bGQgd29yayBlbnRpcmVseQ0KICAgb2ZmIHRoZSBBbGlhc2VzLCBzbyB0aGF0 IHdlIGNhbiByZXVzZSB0aGVzZSBlbGVtZW50cywgYW5kIHRoZSAnRnJvbScgZWxlbWVudCBpcyBz cGVjaWZpYyBvbmx5IHRvIG9uZQ0KICAgZGF0YWJhc2UuICBBdCBzb21lIHBvaW50IHdlIHNob3Vs ZCB0aGVuIGJlIGFibGUgdG8gc3dhcCB0aGlzIGVsZW1lbnQgb3V0IGluc3RlYWQuDQoNCiAgIFNv IHRoZSBiYXNlIGVsZW1lbnQgc3RydWN0dXJlIGlzIGxpa2UgdGhpczoNCiAgIA0KICAgRnJvbSAo ZGVmaW5lcyBhbGlhc2VzKQ0KICAgUmV0dXJuIChkZWZpbmVzIHJlc3VsdHMpDQogICAgICAtIEZv cm0gKHNjaGVtYSB0aGF0IGRlZmluZXMgdGhlIHJlc3VsdCBmb3JtIC0gZWcgVk9UYWJsZSkNCiAg ICAgIC0gU2V0IChsaXN0IG9mIGNvbHVtbnMvcGF0aHMgdGhhdCB3aWxsIGJlIHJldHVybmVkIGlu IHRoZSByZXN1bHRzKQ0KICAgICAgLSBPcmRlcmVkQnkgKGxpc3Qgb2Yga2V5cyBkZWZpbmluZyBv cmRlciBvZiByZXN1bHRzKQ0KICAgICAgLSBHcm91cGVkQnkgKGxpc3Qgb2Yga2V5cyBkZWZpbmlu ZyBob3cgdGhlIHJlc3VsdHMgd2lsbCBiZSBncm91cGVkKQ0KICAgV2hlcmUgKGRlZmluZXMgc2Vh cmNoIGNyaXRlcmlhIC0gaWUgZXhwcmVzc2lvbnMgYmFzZWQgb24gYWxpYXNlcykNCg0KICAgVGVj aG5pY2FsIE5vdGVzOg0KICAgDQogICBUbyBnZXQgcG9seW1vcnBoaWMgcmVsYXRpb25zaGlwcyBm b3IgdGhlIGV4cHJlc3Npb25zLCBJIHVzZSBzdWJzdGl0dXRpb25Hcm91cC4gIEknbSBub3QgZW50 aXJlbHkgaGFwcHkgd2l0aCANCiAgIHRoaXMgLSBJJ2QgbXVjaCByYXRoZXIgZ2V0IHBvbHltb3Jw aGlzbSB0aHJvdWdoIHR5cGUgLSBidXQgaXQgc2VlbXMgdG8gd29yayBPSy4NCiAgIA0KICAgSSBh bHNvIGNhbid0IHdvcmsgb3V0IHdoZXRoZXIgaXQncyBwb3NzaWJsZSAob3IgZGVzaXJhYmxlKSB0 byBzdWJzdGl0dXRlIGEgc3RyaW5nIHZhbHVlIGluc3RlYWQgb2YgYSB0YWcuICANCiAgIEF0IHRo ZSBtb21lbnQsIGZvciBleGFtcGxlLCB5b3UgaGF2ZSB0byB3cml0ZToNCiAgIA0KICAgPFNJTj48 UmVhbE51bWJlcj4wLjEyMzwvUmVhbE51bWJlcj48L1NJTj4NCiAgIA0KICAgaW5zdGVhZCBvZjoN CiAgIA0KICAgPFNJTj4wLjEyMzwvU0lOPg0KICAgDQogICBCZWNhdXNlIHlvdSBtYXkgd2FudCB0 byBpbmNsdWRlIG1vcmUgY29tcGxleCBleHByZXNzaW9ucyBpbiB0aGVyZSwgc3VjaCBhczoNCiAg IA0KICAgPFNJTj48QUJTPjxBbGlhcz5SQTwvQWxpYXM+PC9BQlM+PC9TSU4+DQogICANCiAgIEFs c28gSSBjYW4ndCBzZWUgYSB3YXkgb2Ygc2Vuc2libHkgVHlwaW5nIHRoZSBleHByZXNzaW9ucyAo aWUgTnVtZXJpY2FsIHZzIFN0cmluZyksIGJlY2F1c2UgYSBWYWx1ZVNldCAoQ29sdW1uL1hQYXRo KSBtaWdodCBiZSBhIA0KICAgc3RyaW5nIG9yIGEgbnVtYmVyLiAgUHJvYmFibHkgdGhlIHdheSB0 byBkbyB0aGlzIGlzIHRvIGhhdmUgYSBudW1lcmljQWxpYXMgYW5kIHN0cmluZ0FsaWFzLi4uDQog DQoNCiAgIE1hcnRpbiBIaWxsLCBtY2hAcm9lLmFjLnVrDQotLT4NCg0KPHhzOnNjaGVtYSBlbGVt ZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIw MDEvWE1MU2NoZW1hIj4NCg0KICA8IS0tIHhzOmltcG9ydCBuYW1lc3BhY2U9J3Vybjpudm8tcmVn aW9uJyBzY2hlbWFMb2NhdGlvbj0iZmlsZTovL2FzdHJvZ3JpZC9yZWdpb24ueHNkIi8+ICAtLT4N Cg0KICA8IS0tIEFzdHJvbm9taWNhbCBEYXRhIFF1ZXJ5IC0tPg0KICA8eHM6ZWxlbWVudCBuYW1l PSJBRFEiPg0KICAgIDx4czpjb21wbGV4VHlwZT4NCiAgICAgIDx4czpzZXF1ZW5jZT4NCg0KICAg ICAgPCEtLSBGcm9tIC0gZGVmaW5lcyBhbGlhc2VzIHRvIGNvbHVtbnMveHBhdGhzL290aGVyIHNl dHMgb2YgdmFsdWVzIC0tPg0KICAgICAgPCEtLSBwZXJoYXBzIHdlIHNob3VsZCB1c2UgSUQgaW5z dGVhZD8gLS0+DQogICAgICA8eHM6ZWxlbWVudCBuYW1lPSdGcm9tJyBtaW5PY2N1cnM9IjAiIG1h eE9jY3Vycz0iMSI+DQogICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICA8IS0t IEJ5IG1ha2luZyB0aGUgY2hvaWNlIG1heCB1bmJvdW5kZWQgd2UgY2FuIHB1dCBDb2x1bW4vVGFi bGUgaW4gYW55IG9yZGVyIGFueSBudW1iZXIgb2YgdGltZXMgLS0+DQogICAgICAgICAgICA8eHM6 Y2hvaWNlIG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPSd1bmJvdW5kZWQnPg0KICAgICAgICAgICAg ICAgPHhzOmVsZW1lbnQgbmFtZT0nQ29sdW1uJz4NCiAgICAgICAgICAgICAgICAgIDx4czpjb21w bGV4VHlwZT4NCiAgICAgICAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICAg ICAgICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSIxIiBuYW1l PSJBbGlhcyIgdHlwZT0ieHM6c3RyaW5nIiAvPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHhz OmVsZW1lbnQgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiIG5hbWU9IlRhYmxlIiB0eXBlPSJ4 czpzdHJpbmciIC8+DQogICAgICAgICAgICAgICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1 cnM9IjEiIG1heE9jY3Vycz0iMSIgbmFtZT0iQ29sdW1uIiB0eXBlPSJ4czpzdHJpbmciIC8+DQog ICAgICAgICAgICAgICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgICAgICAgICAgICAgPC94 czpjb21wbGV4VHlwZT4NCiAgICAgICAgICAgICAgIDwveHM6ZWxlbWVudD4NCiAgICAgICAgICAg ICAgIDx4czplbGVtZW50IG5hbWU9J1BhdGgnPg0KICAgICAgICAgICAgICAgICAgPHhzOmNvbXBs ZXhUeXBlPg0KICAgICAgICAgICAgICAgICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgICAg ICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9IjEiIG5hbWU9 IkFsaWFzIiB0eXBlPSJ4czpzdHJpbmciIC8+DQogICAgICAgICAgICAgICAgICAgICAgICA8eHM6 ZWxlbWVudCBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSIgbmFtZT0iWFBhdGgiIHR5cGU9Inhz OnN0cmluZyIgLz4NCiAgICAgICAgICAgICAgICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAg ICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgICAgICAgICAgICAgPC94czplbGVtZW50 Pg0KICAgICAgICAgICAgPC94czpjaG9pY2U+DQogICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0K ICAgICAgPC94czplbGVtZW50Pg0KICANCiAgICAgIDwhLS0gU2VsZWN0IC0gbGlzdCB0aGUgc2V0 cyB0byBiZSBnaXZlbiBpbiB0aGUgcmVzdWx0cyAtLT4NCiAgICAgIDwhLS0gaW4gZnV0dXJlIHRo aXMgbWlnaHQgYmUgZXh0ZW5kZWQgdG8gc2F5IG1vcmUgYWJvdXQgaG93IHRoZSByZXN1bHRzIGFy ZSByZXR1cm5lZCAtLT4NCiAgICAgIDx4czplbGVtZW50IG5hbWU9IlJldHVybiIgbWluT2NjdXJz PScxJyBtYXhPY2N1cnM9JzEnPg0KICAgICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICAg ICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgICAgICAgPCEtLSBUaGUgc2NoZW1hIHdlIHdhbnQg dGhlIHJlc3VsdHMgZG9jdW1lbnQgdG8gbWF0Y2ggLS0+DQogICAgICAgICAgICAgICA8eHM6ZWxl bWVudCBuYW1lPSJGb3JtIiBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgdHlwZT0ieHM6c3Ry aW5nIi8+ICA8IS0tIHRoaXMgc2hvdWxkIGJlIGEgdXJsIGJ1dCBYTUwgQnVkZHkgZG9lc24ndCBz ZWVtIHRvIGxpa2UgdGhhdCAtLT4NCiAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgPCEt LSB3aGF0IHdpbGwgYmUgaW4gdGhlIHNldCBvZiByZXN1bHRzIC0tPg0KICAgICAgICAgICAgICAg PHhzOmVsZW1lbnQgbmFtZT0nU2V0Jz4NCiAgICAgICAgICAgICAgICAgIDx4czpjb21wbGV4VHlw ZT4NCiAgICAgICAgICAgICAgICAgICAgIDx4czpjaG9pY2U+DQogICAgICAgICAgICAgICAgICAg ICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0iMSIgbmFtZT0iQWxsIiBu aWxsYWJsZT0ndHJ1ZScvPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWlu T2NjdXJzPSIxIiBtYXhPY2N1cnM9J3VuYm91bmRlZCcgcmVmPSdFeHByZXNzaW9uJy8+DQogICAg ICAgICAgICAgICAgICAgICA8L3hzOmNob2ljZT4NCiAgICAgICAgICAgICAgICAgIDwveHM6Y29t cGxleFR5cGU+DQogICAgICAgICAgICAgICA8L3hzOmVsZW1lbnQ+DQoNCiAgICAgICAgICAgICAg IDwhLS0gT3JkZXIgLSBzb3J0ZWQgb3JkZXIgb2YgcmVzdWx0cy4gIGEgbGlzdCBvZiBrZXlzIChl YWNoIG9uZSBhbiBleHByZXNzaW9uKSAtLT4NCiAgICAgICAgICAgICAgIDwhLS0gcmF0aGVyIG5h dWdodGlseSBhc3N1bWVzIG9yZGVyIG9mIGNvbHVtbnMgZ2l2ZW4gaW4gdGFnID0gb3JkZXIgcG9z aXRpb24va2V5IHByaW9yaXR5IC0tPg0KICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0n T3JkZXJlZEJ5JyBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0nMSc+DQogICAgICAgICAgICAgICAg ICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAgICAgICAgICAgICAgICA8eHM6Y2hvaWNlPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9 J3VuYm91bmRlZCcgbmFtZT0nS2V5Jz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpj b21wbGV4VHlwZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0n MScgbWF4T2NjdXJzPScxJyByZWY9J0V4cHJlc3Npb24nLz4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 IS0tIGF0dHJpYnV0ZSBzcGVjaWZ5aW5nIHdoZXRoZXIgdG8gc29ydCB0aGlzIGtleSBpbiBhc2Nl bmRpbmcgb3IgZGVzY2VuZGluZyBvcmRlciAtLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDx4czphdHRyaWJ1dGUgbmFtZT0nZGlyZWN0aW9uJz4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDx4czpzaW1wbGVUeXBlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHhzOnJlc3RyaWN0aW9uIGJhc2U9J3hzOnN0cmluZyc+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8eHM6ZW51bWVyYXRpb24gdmFsdWU9J2Rlc2NlbmRp bmcnLz4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx4czplbnVtZXJh dGlvbiB2YWx1ZT0nYXNjZW5kaW5nJy8+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3hzOnJlc3RyaWN0aW9uPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PC94czpzaW1wbGVUeXBlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC94czphdHRy aWJ1dGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPC94czplbGVtZW50Pg0KICAgICAgICAgICAgICAgICAgICAg PC94czpjaG9pY2U+DQogICAgICAgICAgICAgICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgICAg ICAgICAgICAgPC94czplbGVtZW50Pg0KICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICA8 IS0tIEdyb3VwZWQgQnkgIC0tPg0KICAgICAgICAgICAgICAgPCEtLSByYXRoZXIgbmF1Z2h0aWx5 IGFzc3VtZXMgb3JkZXIgb2YgY29sdW1ucyBnaXZlbiBpbiB0YWcgPSBvcmRlciBncm91cGluZyAt LT4NCiAgICAgICAgICAgICAgIDx4czplbGVtZW50IG5hbWU9J0dyb3VwZWRCeScgbWluT2NjdXJz PSIwIiBtYXhPY2N1cnM9JzEnPg0KICAgICAgICAgICAgICAgICAgPHhzOmNvbXBsZXhUeXBlPg0K ICAgICAgICAgICAgICAgICAgICAgPHhzOmNob2ljZT4NCiAgICAgICAgICAgICAgICAgICAgICAg IDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPSd1bmJvdW5kZWQnIG5hbWU9J0tl eSc+DQogICAgICAgICAgICAgICAgICAgICAgICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVm PSdFeHByZXNzaW9uJy8+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3hzOnNlcXVl bmNlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDwveHM6ZWxlbWVudD4NCiAgICAgICAgICAgICAgICAgICAgIDwv eHM6Y2hvaWNlPg0KICAgICAgICAgICAgICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgICAgICAg ICAgICAgIDwveHM6ZWxlbWVudD4NCg0KICAgICAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAg ICAgIDwveHM6Y29tcGxleFR5cGU+DQogICAgICA8L3hzOmVsZW1lbnQ+DQoNCiAgICAgIDwhLS0g V2hlcmUgLSBzZWxlY3Rpb24vbWF0Y2hpbmcgY3JpdGVyaWEgLS0+DQogICAgICA8eHM6ZWxlbWVu dCBuYW1lPSdXaGVyZScgbWluT2NjdXJzPScwJyBtYXhPY2N1cnM9JzEnPg0KICAgICAgICAgPHhz OmNvbXBsZXhUeXBlPg0KICAgICAgICAgICAgPHhzOmNob2ljZT4NCiAgICAgICAgICAgICAgIDx4 czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9IkJvb2xlYW5FeHByZXNz aW9uIi8+DQogICAgICAgICAgICA8L3hzOmNob2ljZT4NCiAgICAgICAgIDwveHM6Y29tcGxleFR5 cGU+DQogICAgICA8L3hzOmVsZW1lbnQ+ICAgICAgIA0KDQogICAgICA8IS0tIGVuZCBBRFEgLS0+ DQogICAgICA8L3hzOnNlcXVlbmNlPg0KICAgIDwveHM6Y29tcGxleFR5cGU+DQogIDwveHM6ZWxl bWVudD4NCiAgDQogICAgDQogIDwhLS0gVGhlIGJhc2ljIGJvb2xlYW4gdW5pdCBvZiBzZWFyY2gg Y3JpdGVyaWEgLS0+DQogIDwhLS0gZGVmaW5lcyBhbiBleHByZXNzaW9uIHRoYXQgd2lsbCByZXN1 bHQgaW4gYSBib29sZWFuIHllcy9ubyBtYXRjaCAtLT4NCiAgPHhzOmVsZW1lbnQgbmFtZT0nQm9v bGVhbkV4cHJlc3Npb24nIGFic3RyYWN0PSd0cnVlJy8+DQoNCiAgPCEtLSBCb29sZWFuIE5PVCBv biB0aGUgZW5jbG9zZWQgZXhwcmVzc2lvbiAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9Ik5PVCIg c3Vic3RpdHV0aW9uR3JvdXA9IkJvb2xlYW5FeHByZXNzaW9uIj4NCiAgICAgIDx4czpjb21wbGV4 VHlwZT4NCiAgICAgICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICAgICAgIDx4czplbGVt ZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9J0Jvb2xlYW5FeHByZXNzaW9uJy8+ DQogICAgICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAg IDwveHM6ZWxlbWVudD4NCg0KICAgPCEtLSBEZWZpbmVzIGEgTG9naWNhbCBPcGVyYXRpb24gb24g dHdvIGJvb2xlYW4gZXhwcmVzc2lvbnMgLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJMb2dpY2Fs IiBzdWJzdGl0dXRpb25Hcm91cD0nQm9vbGVhbkV4cHJlc3Npb24nPg0KICAgICAgPHhzOmNvbXBs ZXhUeXBlPg0KICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2Nj dXJzPScxJyBtYXhPY2N1cnM9JzEnIHJlZj0nQm9vbGVhbkV4cHJlc3Npb24nLz4NCiAgICAgICAg IDx4czplbGVtZW50IHJlZj0nTG9naWNhbE9wZXJhdG9yJy8+DQogICAgICAgICA8eHM6ZWxlbWVu dCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVmPSdCb29sZWFuRXhwcmVzc2lvbicvPg0K ICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgIDwveHM6Y29tcGxleFR5cGU+DQogICA8L3hzOmVs ZW1lbnQ+DQoNCiAgIDwhLS0gRGVmaW5lcyB0aGUgTG9naWNhbCBPcGVyYXRvcnMgLSBpZSBBTkQs IE9SLCBldGMgLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdMb2dpY2FsT3BlcmF0b3InIGFic3Ry YWN0PSd0cnVlJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nQU5EJyBz dWJzdGl0dXRpb25Hcm91cD0nTG9naWNhbE9wZXJhdG9yJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAg PHhzOmVsZW1lbnQgbmFtZT0nT1InIHN1YnN0aXR1dGlvbkdyb3VwPSdMb2dpY2FsT3BlcmF0b3In IG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdYT1InIHN1YnN0aXR1dGlv bkdyb3VwPSdMb2dpY2FsT3BlcmF0b3InIG5pbGxhYmxlPSd0cnVlJy8+DQoNCiAgIDwhLS0gRGVm aW5lcyBhIGNvbXBhcmlzb24gLS0+DQogICA8IS0tIGNvbXBhcmVzIHR3byBzY2FsYXIgZXhwcmVz c2lvbnMsIHJldHVybmluZyBhIGJvb2xlYW4gLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJDb21w YXJlIiBzdWJzdGl0dXRpb25Hcm91cD0nQm9vbGVhbkV4cHJlc3Npb24nPg0KICAgICAgPHhzOmNv bXBsZXhUeXBlPg0KICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgPHhzOmVsZW1lbnQgbWlu T2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIHJlZj0nRXhwcmVzc2lvbicvPg0KICAgICAgICAgPHhz OmVsZW1lbnQgcmVmPSdDb21wYXJlT3BlcmF0b3InLz4NCiAgICAgICAgIDx4czplbGVtZW50IG1p bk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyByZWY9J0V4cHJlc3Npb24nLz4NCiAgICAgIDwveHM6 c2VxdWVuY2U+DQogICAgICA8L3hzOmNvbXBsZXhUeXBlPg0KICAgPC94czplbGVtZW50Pg0KDQog ICA8IS0tIERlZmluZXMgdGhlIENvbXBhcmUgT3BlcmF0b3JzIC0gaWUgbGVzcyB0aGFuLCBlcXVh bHMsIGV0YyAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9J0NvbXBhcmVPcGVyYXRvcicgYWJzdHJh Y3Q9J3RydWUnIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdFUVVBTFMn IHN1YnN0aXR1dGlvbkdyb3VwPSdDb21wYXJlT3BlcmF0b3InIG5pbGxhYmxlPSd0cnVlJy8+DQog ICA8eHM6ZWxlbWVudCBuYW1lPSdHUkVBVEVSVEhBTicgc3Vic3RpdHV0aW9uR3JvdXA9J0NvbXBh cmVPcGVyYXRvcicgbmlsbGFibGU9J3RydWUnLz4NCiAgIDx4czplbGVtZW50IG5hbWU9J0xFU1NU SEFOJyBzdWJzdGl0dXRpb25Hcm91cD0nQ29tcGFyZU9wZXJhdG9yJyBuaWxsYWJsZT0ndHJ1ZScv Pg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nR1JFQVRFUlRIQU5PUkVRVUFMUycgc3Vic3RpdHV0aW9u R3JvdXA9J0NvbXBhcmVPcGVyYXRvcicgbmlsbGFibGU9J3RydWUnLz4NCiAgIDx4czplbGVtZW50 IG5hbWU9J0xFU1NUSEFOT1JFUVVBTFMnIHN1YnN0aXR1dGlvbkdyb3VwPSdDb21wYXJlT3BlcmF0 b3InIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdMSUtFJyBzdWJzdGl0 dXRpb25Hcm91cD0nQ29tcGFyZU9wZXJhdG9yJyBuaWxsYWJsZT0ndHJ1ZScvPg0KDQoNCiAgIDwh LS0gRGVmaW5lcyBzcGVjaWFsIGFyZWEgc2VhcmNoIHR5cGVzIC0tPg0KICAgPHhzOmVsZW1lbnQg bmFtZT0iQ2lyY2xlTWF0Y2giIHN1YnN0aXR1dGlvbkdyb3VwPSdCb29sZWFuRXhwcmVzc2lvbic+ DQogICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAg PCEtLSA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgbmFtZT0iQ2lyY2xl IiB0eXBlPSJ1cm46bnZvLXJlZ2lvbjpyZWdpb25UeXBlIiAvPiAtLT4NCiAgICAgICAgICA8eHM6 ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nUkEnIHR5cGU9J3hzOmZs b2F0Jy8+DQogICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEn IG5hbWU9J0RFQycgdHlwZT0neHM6ZmxvYXQnLz4NCiAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5P Y2N1cnM9JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nUmFkaXVzJyB0eXBlPSd4czpmbG9hdCcvPg0K ICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgIDwveHM6 ZWxlbWVudD4NCg0KICAgPCEtLSBEZWZpbmUgY3Jvc3MgbWF0Y2ggc2VhcmNoIC0tPg0KICAgPHhz OmVsZW1lbnQgbmFtZT0iWE1hdGNoIiBzdWJzdGl0dXRpb25Hcm91cD0nQm9vbGVhbkV4cHJlc3Np b24nPg0KICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAg ICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J1NvbWV0 aGluZycgdHlwZT0neHM6ZmxvYXQnLz4NCiAgICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgIDwv eHM6Y29tcGxleFR5cGU+DQogICA8L3hzOmVsZW1lbnQ+DQoNCiAgPCEtLSBBIEdlbmVyYWwgRXhw cmVzc2lvbiAtLT4NCiAgPHhzOmVsZW1lbnQgbmFtZT0nRXhwcmVzc2lvbicgYWJzdHJhY3Q9J3Ry dWUnLz4NCg0KICAgDQogIDwhLS0gd2UgKmNhbioganVzdCBnaXZlIGEgc3RyaW5nIGFzIGEgdmFs dWUsIGJ1dCB3ZSBtaWdodCB3YW50IHRvIGJlIG1vcmUgc3BlY2lmaWMgLS0+DQogIDx4czplbGVt ZW50IG5hbWU9J0ludGVnZXInIHN1YnN0aXR1dGlvbkdyb3VwPSdFeHByZXNzaW9uJyB0eXBlPSd4 czppbnQnLz4NCiAgPHhzOmVsZW1lbnQgbmFtZT0nUmVhbE51bWJlcicgc3Vic3RpdHV0aW9uR3Jv dXA9J0V4cHJlc3Npb24nIHR5cGU9J3hzOmRvdWJsZScvPg0KICANCiAgIDwhLS0gVXNlZnVsIHR5 cGUgZm9yIGEgbG90IG9mIGZ1bmN0aW9ucyB0aGF0IHdyYXAgYSBzaW5nbGUgRXhwcmVzc2lvbiAt LT4NCiAgIDx4czpjb21wbGV4VHlwZSBuYW1lPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIgPg0KICAg ICA8eHM6c2VxdWVuY2U+DQogICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2Nj dXJzPScxJyByZWY9IkV4cHJlc3Npb24iLz4NCiAgICAgPC94czpzZXF1ZW5jZT4NCiAgIDwveHM6 Y29tcGxleFR5cGU+DQoNCg0KICAgPCEtLSAnVW5hcnknIC0gc3dhcCBuZWdhdGl2ZS9wb3NpdGl2 ZSB2YWx1ZXMgLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdOZWdhdGl2ZU9mJyAgc3Vic3RpdHV0 aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZkV4 cHJlc3Npb24iLz4NCiAgICANCiAgIDwhLS0gRGVmaW5lcyBtYXRoZW1hdGljYWwgZnVuY3Rpb25z IC0tPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iU0lOIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVz c2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAg PHhzOmVsZW1lbnQgbmFtZT0iQ09TIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lvbicgbmls bGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1l bnQgbmFtZT0iVEFOIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lvbicgbmlsbGFibGU9J2Zh bHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0i Q09UIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBl PSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iQVNJTiIgc3Vi c3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rp b25PZkV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5hbWU9IkFDT1MiIHN1YnN0aXR1dGlv bkdyb3VwPSdFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0aW9uT2ZFeHBy ZXNzaW9uIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJBVEFOIiBzdWJzdGl0dXRpb25Hcm91cD0n RXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIv Pg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iQUJTIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lv bicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgPHhz OmVsZW1lbnQgbmFtZT0iRVhQIiBzdWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lvbicgbmlsbGFi bGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQg bmFtZT0iU1FSVCIgc3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxz ZScgdHlwZT0iRnVuY3Rpb25PZkV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5hbWU9IkNF SUxJTkciIHN1YnN0aXR1dGlvbkdyb3VwPSdFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5 cGU9IkZ1bmN0aW9uT2ZFeHByZXNzaW9uIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJGTE9PUiIg c3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxhYmxlPSdmYWxzZScgdHlwZT0iRnVu Y3Rpb25PZkV4cHJlc3Npb24iLz4NCiAgIDx4czplbGVtZW50IG5hbWU9IkRFR1JFRVMiIHN1YnN0 aXR1dGlvbkdyb3VwPSdFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnIHR5cGU9IkZ1bmN0aW9u T2ZFeHByZXNzaW9uIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJSQURJQU5TIiBzdWJzdGl0dXRp b25Hcm91cD0nRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhw cmVzc2lvbiIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0iU1FVQVJFIiBzdWJzdGl0dXRpb25Hcm91 cD0nRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lv biIvPg0KDQogICA8eHM6ZWxlbWVudCBuYW1lPSdQSScgc3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJl c3Npb24nIG5pbGxhYmxlPSd0cnVlJy8+DQoNCiAgIDx4czplbGVtZW50IG5hbWU9IlBPV0VSIiBz dWJzdGl0dXRpb25Hcm91cD0nRXhwcmVzc2lvbicgbmlsbGFibGU9J2ZhbHNlJyA+DQogICAgICA8 eHM6Y29tcGxleFR5cGU+DQogICAgICAgIDx4czpzZXF1ZW5jZT4NCiAgICAgICAgICAgPHhzOmVs ZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J01hbnRpc3NhJyB0eXBlPSJG dW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9 JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nRXhwb25lbnQnIHR5cGU9IkZ1bmN0aW9uT2ZFeHByZXNz aW9uIi8+DQogICAgICAgIDwveHM6c2VxdWVuY2U+DQogICAgICA8L3hzOmNvbXBsZXhUeXBlPg0K ICAgPC94czplbGVtZW50Pg0KDQogICA8eHM6ZWxlbWVudCBuYW1lPSJMT0ciIHN1YnN0aXR1dGlv bkdyb3VwPSdFeHByZXNzaW9uJyBuaWxsYWJsZT0nZmFsc2UnID4NCiAgICAgIDx4czpjb21wbGV4 VHlwZT4NCiAgICAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICAgICA8eHM6ZWxlbWVudCBtaW5P Y2N1cnM9JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nQmFzZScgdHlwZT0iRnVuY3Rpb25PZkV4cHJl c3Npb24iLz4NCiAgICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9 JzEnIG5hbWU9J0FyZ3VtZW50JyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgICAg ICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPC94czpjb21wbGV4VHlwZT4NCiAgIDwveHM6ZWxlbWVu dD4NCg0KDQogICA8IS0tIENvbXBsZXggRXhwcmVzc2lvbiAtIGllIGFkZGluZyB0aGluZ3MgdXAg ZXRjIC0tPiAgDQogICA8eHM6ZWxlbWVudCBuYW1lPSdNYXRoJyBzdWJzdGl0dXRpb25Hcm91cD0i RXhwcmVzc2lvbiI+DQogICAgICA8eHM6Y29tcGxleFR5cGU+DQogICAgICA8eHM6c2VxdWVuY2U+ DQogICAgICAgICA8eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVmPSdF eHByZXNzaW9uJy8+DQogICAgICAgICA8eHM6ZWxlbWVudCByZWY9J01hdGhPcGVyYXRvcicvPg0K ICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2NjdXJzPScxJyBtYXhPY2N1cnM9JzEnIHJlZj0nRXhw cmVzc2lvbicvPg0KICAgICAgPC94czpzZXF1ZW5jZT4NCiAgICAgIDwveHM6Y29tcGxleFR5cGU+ DQogICA8L3hzOmVsZW1lbnQ+ICAgDQoNCiAgIDwhLS0gT3BlcmF0b3IgLSBpZSBhZGQsIHN1YnRy YWN0LCBldGMgLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdNYXRoT3BlcmF0b3InIGFic3RyYWN0 PSd0cnVlJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nQUREVE8nIHN1 YnN0aXR1dGlvbkdyb3VwPSdNYXRoT3BlcmF0b3InIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6 ZWxlbWVudCBuYW1lPSdTVUJUUkFDVEZST00nIHN1YnN0aXR1dGlvbkdyb3VwPSdNYXRoT3BlcmF0 b3InIG5pbGxhYmxlPSd0cnVlJy8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdNVUxUSVBMWUJZJyBz dWJzdGl0dXRpb25Hcm91cD0nTWF0aE9wZXJhdG9yJyBuaWxsYWJsZT0ndHJ1ZScvPg0KICAgPHhz OmVsZW1lbnQgbmFtZT0nRElWSURFQlknIHN1YnN0aXR1dGlvbkdyb3VwPSdNYXRoT3BlcmF0b3In IG5pbGxhYmxlPSd0cnVlJy8+DQoNCiANCiAgIDwhLS0gRGVmaW5lcyBjb2x1bW4gcmFuZ2UgZnVu Y3Rpb25zIC0tPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nU1VNJyBzdWJzdGl0dXRpb25Hcm91cD0i RXhwcmVzc2lvbiIgdHlwZT0iVmFsdWVTZXRzIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdBVkcn IHN1YnN0aXR1dGlvbkdyb3VwPSJFeHByZXNzaW9uIiB0eXBlPSJWYWx1ZVNldHMiLz4NCiAgIDx4 czplbGVtZW50IG5hbWU9J01JTicgc3Vic3RpdHV0aW9uR3JvdXA9IkV4cHJlc3Npb24iIHR5cGU9 IlZhbHVlU2V0cyIvPg0KICAgPHhzOmVsZW1lbnQgbmFtZT0nTUFYJyBzdWJzdGl0dXRpb25Hcm91 cD0iRXhwcmVzc2lvbiIgdHlwZT0iVmFsdWVTZXRzIi8+DQogICA8eHM6ZWxlbWVudCBuYW1lPSdD T1VOVCcgc3Vic3RpdHV0aW9uR3JvdXA9IkV4cHJlc3Npb24iIHR5cGU9IlZhbHVlU2V0cyIvPg0K DQoNCiAgIDwhLS0gRGVmaW5lcyBhIHJhbmdlIG9yIGVudW1lcmF0aW9uIG9mIGNvbHVtbnMgLS0+ DQogICA8eHM6Y29tcGxleFR5cGUgbmFtZT0nVmFsdWVTZXRzJz4NCiAgICAgIDx4czpjaG9pY2Ug bWluT2NjdXJzPScxJyBtYXhPY2N1cnM9IjEiPg0KICAgICAgICAgPHhzOmVsZW1lbnQgbWluT2Nj dXJzPScxJyBtYXhPY2N1cnM9JzEnIG5hbWU9J1JhbmdlJyB0eXBlPSd4czpzdHJpbmcnLz4NCiAg ICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSd1bmJvdW5kZWQnIHJl Zj0nQWxpYXMnLz4NCiAgICAgIDwveHM6Y2hvaWNlPg0KICAgPC94czpjb21wbGV4VHlwZT4NCg0K DQogIDwhLS0gQSBFeHByZXNzaW9uIHJldHVybnMgYSBzdHJpbmcgLS0+DQogIDwhLS0gZnVubnkg dGhhdCAtLT4NCiAgPHhzOmVsZW1lbnQgbmFtZT0nU3RyaW5nJyBzdWJzdGl0dXRpb25Hcm91cD0n RXhwcmVzc2lvbicgdHlwZT0neHM6c3RyaW5nJy8+DQoNCiAgIDwhLS0gVXNlZnVsIHR5cGUgZm9y IGZ1bmN0aW9ucyB0aGF0IHdyYXAgYSBFeHByZXNzaW9uIC0tPg0KICAgPHhzOmNvbXBsZXhUeXBl IG5hbWU9IkZ1bmN0aW9uT2ZTdHJpbmciID4NCiAgICAgPHhzOnNlcXVlbmNlPg0KICAgICAgICA8 eHM6ZWxlbWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgcmVmPSJFeHByZXNzaW9uIi8+ DQogICAgIDwveHM6c2VxdWVuY2U+DQogICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogICA8eHM6ZWxl bWVudCBuYW1lPSJUcnVuY2F0ZSIgc3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxh YmxlPSdmYWxzZScgdHlwZT0iRnVuY3Rpb25PZlN0cmluZyIvPg0KDQogICA8eHM6ZWxlbWVudCBu YW1lPSJDb25jYXRlbmF0ZSIgc3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIG5pbGxhYmxl PSdmYWxzZScgPg0KICAgICAgPHhzOmNvbXBsZXhUeXBlPg0KICAgICAgICA8eHM6c2VxdWVuY2U+ DQogICAgICAgICAgIDx4czplbGVtZW50IG1pbk9jY3Vycz0nMScgbWF4T2NjdXJzPScxJyBuYW1l PSdCYXNlJyB0eXBlPSJGdW5jdGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgICAgICAgICA8eHM6ZWxl bWVudCBtaW5PY2N1cnM9JzEnIG1heE9jY3Vycz0nMScgbmFtZT0nQXBwZW5kJyB0eXBlPSJGdW5j dGlvbk9mRXhwcmVzc2lvbiIvPg0KICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgPC94czpj b21wbGV4VHlwZT4NCiAgIDwveHM6ZWxlbWVudD4NCiAgIA0KICA8IS0tIERlZmluZXMgYW4gYWxp YXMgLSByZWZlcnMgdG8gRlJPTS1kZWZpbmVkIGNvbHVtbi9wYXRoIC0tPg0KICA8eHM6ZWxlbWVu dCBuYW1lPSdBbGlhcycgc3Vic3RpdHV0aW9uR3JvdXA9J0V4cHJlc3Npb24nIHR5cGU9J3hzOnN0 cmluZycvPg0KIA0KDQoNCiAgDQo8L3hzOnNjaGVtYT4NCiAgICAgIA0K ---MOQ1075887204f94650e5beca624c4b87aec6ca705320 Content-Type: text/xml; name="NewADQL.xml" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="NewADQL.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0gR2VuZXJhdGVkIGZy b20gTmV3QURRTC54c2QgYnkgWE1MQnVkZHktLT4NCjxBRFEgeHNpOm5vTmFtZXNwYWNlU2NoZW1h TG9jYXRpb249ImZpbGU6Ly8vQzovZWNsaXBzZS93b3Jrc3BhY2UvQURRTFNjaGVtYS9OZXdBRFFM LnhzZCINCgl4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rh bmNlIj4NCgk8RnJvbT4NCgkJPENvbHVtbj4NCgkJICAgPEFsaWFzPlJBPC9BbGlhcz4NCgkJICAg PFRhYmxlPlNreU9iamVjdDwvVGFibGU+DQoJCSAgIDxDb2x1bW4+UkFfT0JKPC9Db2x1bW4+DQoJ CTwvQ29sdW1uPg0KCQk8Q29sdW1uPg0KCQkgICA8QWxpYXM+REVDPC9BbGlhcz4NCgkJICAgPFRh YmxlPlNreU9iamVjdDwvVGFibGU+DQoJCSAgIDxDb2x1bW4+REVDTF9PQko8L0NvbHVtbj4NCgkJ PC9Db2x1bW4+DQoJCTxDb2x1bW4+DQoJCSAgIDxBbGlhcz5FbGlwdGljaXR5PC9BbGlhcz4NCgkJ ICAgPFRhYmxlPkdhbGF4eTwvVGFibGU+DQoJCSAgIDxDb2x1bW4+RUxJUDwvQ29sdW1uPg0KCQk8 L0NvbHVtbj4NCgkJPENvbHVtbj4NCgkJICAgPEFsaWFzPk1hZ25pdHVkZTwvQWxpYXM+DQoJCSAg IDxUYWJsZT5Ta3lPYmplY3Q8L1RhYmxlPg0KCQkgICA8Q29sdW1uPk1BR19CPC9Db2x1bW4+DQoJ CTwvQ29sdW1uPg0KCQk8Q29sdW1uPg0KCQkgICA8QWxpYXM+U2hhcGU8L0FsaWFzPg0KCQkgICA8 VGFibGU+R2FsYXh5PC9UYWJsZT4NCgkJICAgPENvbHVtbj5TSEFQRTwvQ29sdW1uPg0KCQk8L0Nv bHVtbj4NCgk8L0Zyb20+DQoJPFJldHVybj4NCgkgICA8Rm9ybT5odHRwOi8vYmxhaC5ibGFoL1ZP VGFibGUueHNkPC9Gb3JtPg0KCQk8U2V0Pg0KCQkJPEFsbC8+DQoJCTwvU2V0Pg0KCQk8T3JkZXJl ZEJ5Pg0KCQkJPEtleSBkaXJlY3Rpb249ImFzY2VuZGluZyI+PEFsaWFzPk1hZ25pdHVkZTwvQWxp YXM+PC9LZXk+DQoJCTwvT3JkZXJlZEJ5Pg0KCQk8R3JvdXBlZEJ5Pg0KCQkJPEtleT48QWxpYXM+ U2hhcGU8L0FsaWFzPjwvS2V5Pg0KCQk8L0dyb3VwZWRCeT4NCgk8L1JldHVybj4NCgk8V2hlcmU+ DQoJICAgPExvZ2ljYWw+DQoJICAgICAgPENpcmNsZU1hdGNoPg0KICAgICAgICAgICAgPFJBPjEy PC9SQT4JDQogICAgICAgICAgICA8REVDPjEzPC9ERUM+DQogICAgICAgICAgICA8UmFkaXVzPjM8 L1JhZGl1cz4NCgkgICAgICA8L0NpcmNsZU1hdGNoPg0KCSAgICAgIDxBTkQvPg0KICAgCQk8Q29t cGFyZT4NCiAgICAgIAkgICA8UmVhbE51bWJlcj4wLjc8L1JlYWxOdW1iZXI+DQogICAgICAgICAJ PExFU1NUSEFOT1JFUVVBTFMvPg0KICAgICAgICAgICAgPEFsaWFzPkVsaXB0aWNpdHk8L0FsaWFz Pg0KICAgICAgICAgPC9Db21wYXJlPg0KCQk8L0xvZ2ljYWw+DQoJPC9XaGVyZT4NCjwvQURRPg0K ---MOQ1075887204f94650e5beca624c4b87aec6ca705320-- From owner-voql@eso.org Wed Feb 4 11:07:06 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 i14A6mU8019977 for ; Wed, 4 Feb 2004 11:06:48 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14A6mO7019971 for voql-outgoing; Wed, 4 Feb 2004 11:06:48 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14A6dU8019887 for ; Wed, 4 Feb 2004 11:06:39 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14A6aWR011749 for ; Wed, 4 Feb 2004 11:06:37 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id TAA14941; Wed, 4 Feb 2004 19:06:29 +0900 (JST) Message-Id: <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 04 Feb 2004 19:06:31 +0900 To: martin hill , voql@ivoa.net From: Masatoshi OHISHI Subject: Re: SADQL schema In-Reply-To: <1075886208.4020b88034b42@netmail.pipex.net> References: <1075831628.401fe34c38b42@netmail.pipex.net> <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> <1075886208.4020b88034b42@netmail.pipex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, As I explained before, everybody agreed to adopt a SQL-based query language. This means that the first-step language is an extension of SQL so as to accomodate many of special requests in astronomical queries. The language might be similar to geography data base (I don't remember its correct name (^_^!! ). In our previous meetings, we felt that it would take many years to develop our own language based on XML. In other words, we adopted very practical approach. I don't want to reiterate the same step. This is a wate of time ! I hope that you point out several items to be modified in our current version. Cheers, Masatoshi From owner-voql@eso.org Wed Feb 4 11:46:08 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 i14AjrU8029625 for ; Wed, 4 Feb 2004 11:45:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14AjraL029624 for voql-outgoing; Wed, 4 Feb 2004 11:45:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14AjmU8029603 for ; Wed, 4 Feb 2004 11:45:48 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14AjgWR013479 for ; Wed, 4 Feb 2004 11:45:42 +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 1AoKXN-0003ep-Eg for voql@ivoa.net; Wed, 04 Feb 2004 10:45:41 +0000 Received: (qmail 14704 invoked from network); 4 Feb 2004 10:46:01 -0000 Received: from fluorine.star.le.ac.uk (HELO 192.168.1.209) (143.210.36.13) by mail.star.le.ac.uk with SMTP; 4 Feb 2004 10:46:01 -0000 From: Noel Winstanley Organization: Jodrell Bank Observatory To: martin hill , ael@star.le.ac.uk Subject: Re: SADQL schema (valid...) Date: Wed, 4 Feb 2004 10:39:17 +0000 User-Agent: KMail/1.5.4 Cc: voql@ivoa.net References: <005401c3eafa$5b69cd90$6124d28f@STAR.LE.AC.UK> <1075887205.4020bc650926b@netmail.pipex.net> In-Reply-To: <1075887205.4020bc650926b@netmail.pipex.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_VvMIAAX5TvGhBet" Message-Id: <200402041039.17891.nw@jb.man.ac.uk> 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-voql@eso.org Precedence: bulk Reply-To: Noel Winstanley X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: --Boundary-00=_VvMIAAX5TvGhBet Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline For the purposes of comparison... The example query Martin posted is equivalent to the following SQL select s.Ra_OBJ as RA, s.DECL_OBJ as DEC, g.ELIP as Elipticity, s.MAG_B as Magnitude, g.SHAPE as Shape from SkyObject s, Galaxy g where Region('Circle J2000 12.0, 13.0, 3.0') and 0.7 <= g.ELIP group by s.MAG_B order by g.SHAPE I used the SQL-ADQL translator at http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx to generate the equivalent ADQL, which I've attached. -- Dr Noel Winstanley - nw@jb.man.ac.uk 01477 572689 Senior Java Developer, Astrogrid Project. Jodrell Bank Observatory, University of Manchester. --Boundary-00=_VvMIAAX5TvGhBet Content-Type: text/xml; charset="windows-1252"; name="adql1.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="adql1.xml" --Boundary-00=_VvMIAAX5TvGhBet-- From owner-voql@eso.org Wed Feb 4 12:01:37 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 i14B1LU8002892 for ; Wed, 4 Feb 2004 12:01:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14B1KFj002890 for voql-outgoing; Wed, 4 Feb 2004 12:01:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14B1DU8002865 for ; Wed, 4 Feb 2004 12:01:13 +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 i14B1BEY027337 for ; Wed, 4 Feb 2004 12:01:12 +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 1AoKmM-0005GR-Cm for voql@ivoa.net; Wed, 04 Feb 2004 11:01:10 +0000 Received: (qmail 20430 invoked from network); 4 Feb 2004 11:01:30 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 4 Feb 2004 11:01:30 -0000 From: "Tony Linde" To: "'Masatoshi OHISHI'" , "'martin hill'" , Subject: RE: SADQL schema Date: Wed, 4 Feb 2004 11:02:23 -0000 Organization: University of Leicester Message-ID: <006501c3eb0e$5de69d50$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 In-Reply-To: <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> 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 i14B1JU8002882 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi, We agreed to *base* the language on SQL but to formulate it in XML. Martin's variant meets these conditions. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 04 February 2004 10:07 > To: martin hill; voql@ivoa.net > Subject: Re: SADQL schema > > > Martin, > > As I explained before, everybody agreed to adopt a SQL-based > query language. This means that the first-step language is > an extension of SQL so as to accomodate many of special > requests in astronomical queries. The language might be > similar to geography data base (I don't remember its correct > name (^_^!! ). In our previous meetings, we felt that it > would take many years to develop our own language based on > XML. In other words, we adopted very practical approach. > > I don't want to reiterate the same step. This is a wate of > time ! I hope that you point out several items to be modified > in our current version. > > Cheers, > > Masatoshi > > From owner-voql@eso.org Wed Feb 4 12:09:09 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 i14B8rU8004524 for ; Wed, 4 Feb 2004 12:08:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14B8rGP004523 for voql-outgoing; Wed, 4 Feb 2004 12:08:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14B8oU8004502 for ; Wed, 4 Feb 2004 12:08:50 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14B8lEY027694 for ; Wed, 4 Feb 2004 12:08:48 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id UAA21257; Wed, 4 Feb 2004 20:08:37 +0900 (JST) Message-Id: <6.0.0.20.2.20040204200606.04897ec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 04 Feb 2004 20:08:39 +0900 To: , "'martin hill'" , From: Masatoshi OHISHI Subject: RE: SADQL schema In-Reply-To: <006501c3eb0e$5de69d50$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> <006501c3eb0e$5de69d50$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, Then we don't need to discard current version. Martin has proposed to discard our current ADQL but to consider COMPLETELY NEW language. Do you see any difficulties to modify / improve current ADQL ? Cheers, Masatoshi From owner-voql@eso.org Wed Feb 4 12:17:54 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 i14BHcU8006649 for ; Wed, 4 Feb 2004 12:17:38 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14BHcAD006648 for voql-outgoing; Wed, 4 Feb 2004 12:17:38 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14BHZU8006626 for ; Wed, 4 Feb 2004 12:17:35 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14BHVEY028110 for ; Wed, 4 Feb 2004 12:17:32 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14BHVm7005382; Wed, 4 Feb 2004 11:17:31 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14BHSOm005380; Wed, 4 Feb 2004 11:17:28 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 11:17:28 +0000 Message-ID: <1075893448.4020d4c8e1451@netmail.pipex.net> Date: Wed, 4 Feb 2004 11:17:28 +0000 From: martin hill To: Masatoshi OHISHI Cc: voql@ivoa.net Subject: Re: SADQL schema References: <1075831628.401fe34c38b42@netmail.pipex.net> <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> <1075886208.4020b88034b42@netmail.pipex.net> <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> In-Reply-To: <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Quoting Masatoshi OHISHI : > Martin, > > As I explained before, everybody agreed to adopt a SQL-based query > language. Yes. I agreed and agree too. > This means that the first-step language is an extension of SQL > so as to accomodate many of special requests in astronomical queries. Yes. As is both ADQL and SADQL. > The language might be similar to geography data base (I don't remember > its correct name (^_^!! ). In our previous meetings, we felt that it would > take many years to develop our own language based on XML. In other > words, we adopted very practical approach. Quite right. > I don't want to reiterate the same step. This is a wate of time ! > I hope that you point out several items to be modified in our current > version. Is anyone (other than us at Astrogrid) actually using ADQL? Because we are wasting not only our time but our *astronomers* using the current ADQL. Not only that but we are putting astronomers (and even software-engineers!) off when they look at it or work with it - have a look at the example Noel posted. Now this is not a problem if they never see it (which is how ADQL was going to be used) - but this has turned out not to be the case. As for reiteration - are we going to assume that any prototype assembled must be a final product? The NVO team quite rightly produced a suitable ADQL schema for the task we had in mind for it. In practice we are finding the task is different and the schema is not suitable. Reiteration is part of what we have to do at this stage in development. Modifying the existing schema rather than writing a new one is most certainly a waste of time: it will take more effort and produce something *less* useful. SADQL is *meant* to be an XML representation of SQL SELECT statements, tokenized by XML elements rather than spaces and brackets. If you find things missing then we need to add them in. If you can think of an alternative representation then present it. If you think parts of it are unsuitable, then let me know. If you want to spend the next month deconstructing the generated ADQL-schema to simplify it, carry on - I tried but it's not pleasant! Cheers, Martin -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 12:30:39 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 i14BUGU8009032 for ; Wed, 4 Feb 2004 12:30:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14BUGMu009031 for voql-outgoing; Wed, 4 Feb 2004 12:30:16 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14BUDU8009022 for ; Wed, 4 Feb 2004 12:30:14 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14BU9EY028669 for ; Wed, 4 Feb 2004 12:30:11 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id UAA23474; Wed, 4 Feb 2004 20:30:03 +0900 (JST) Message-Id: <6.0.0.20.2.20040204202903.03072d88@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 04 Feb 2004 20:30:05 +0900 To: martin hill From: Masatoshi OHISHI Subject: Re: SADQL schema Cc: voql@ivoa.net In-Reply-To: <1075893448.4020d4c8e1451@netmail.pipex.net> References: <1075831628.401fe34c38b42@netmail.pipex.net> <6.0.0.20.2.20040204121052.03077c48@mail.mtk.nao.ac.jp> <1075886208.4020b88034b42@netmail.pipex.net> <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> <1075893448.4020d4c8e1451@netmail.pipex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, It seems to me that you have proposed to MODIFY our current ADQL. Right ? Cheers, Masatoshi From owner-voql@eso.org Wed Feb 4 12:49:38 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 i14BnLU8012153 for ; Wed, 4 Feb 2004 12:49:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14BnLLe012152 for voql-outgoing; Wed, 4 Feb 2004 12:49:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14BnIU8012141 for ; Wed, 4 Feb 2004 12:49:18 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14BnGEY029451 for ; Wed, 4 Feb 2004 12:49:17 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14BnFm7007505; Wed, 4 Feb 2004 11:49:15 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14BnFb9007503; Wed, 4 Feb 2004 11:49:15 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 11:49:15 +0000 Message-ID: <1075895355.4020dc3b62bcf@netmail.pipex.net> Date: Wed, 4 Feb 2004 11:49:15 +0000 From: martin hill To: Masatoshi OHISHI Cc: ael@star.le.ac.uk, voql@ivoa.net Subject: RE: SADQL schema References: <6.0.0.20.2.20040204185945.0487e388@mail.mtk.nao.ac.jp> <006501c3eb0e$5de69d50$6124d28f@STAR.LE.AC.UK> <6.0.0.20.2.20040204200606.04897ec0@mail.mtk.nao.ac.jp> In-Reply-To: <6.0.0.20.2.20040204200606.04897ec0@mail.mtk.nao.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I may have answered this in my other email, but SADQL is only 'completely new' as a schema compared to the ADQL schema, not compared to SQL. You should still be able to write SQL-like statements that convert into SADQL. SADQL is meant to be very similar to ADQL but easier to read/write. The difficulties in modifying/improving the current ADQL are in the generated schema. Have a look at it and see how easy you think it would be: http://skyservice.pha.jhu.edu/develop/vo/adql/doc/ADQLSchema.xsd although I'm not sure what version this is. I started with trying to do exactly that - trying to simplify that schema. It was very slow and very unpleasant (I expect because it's been machine-generated), and I didn't seem to be getting a useful document out of it. This is why I ended up starting from scratch to build something similar. Perhaps we could get some idea of who would have to change any code to implement a different schema. Who has code that works with ADQL? There are a few NVO folks, and AstroGrid datacenters. The AstroGrid datacenters have translation layers that can handle different Query Languages so it won't/shouldn't be too hard... Cheers, Martin Quoting Masatoshi OHISHI : > Tony, > > Then we don't need to discard current version. Martin has proposed to > discard our current ADQL but to consider COMPLETELY NEW language. > > Do you see any difficulties to modify / improve current ADQL ? > > Cheers, > > Masatoshi > > > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 13:33: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 i14CWiU8021188 for ; Wed, 4 Feb 2004 13:32:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14CWiEK021187 for voql-outgoing; Wed, 4 Feb 2004 13:32:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14CWaU8021144 for ; Wed, 4 Feb 2004 13:32:36 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14CWYWR018116 for ; Wed, 4 Feb 2004 13:32:34 +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 1AoMCn-0000hG-OQ for voql@ivoa.net; Wed, 04 Feb 2004 12:32:33 +0000 Received: (qmail 16558 invoked from network); 4 Feb 2004 12:32:47 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 4 Feb 2004 12:32:47 -0000 From: "Tony Linde" To: Subject: RE: SADQL schema Date: Wed, 4 Feb 2004 12:33:40 -0000 Organization: University of Leicester Message-ID: <006a01c3eb1b$20aba4f0$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: <6.0.0.20.2.20040204202903.03072d88@mail.mtk.nao.ac.jp> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi I think Martin's proposal is to modify it by completely replacing it :) His point, I think, is that ADQL is flawed and it is better to try and create something different (I'm paraphrasing, not necessarily agreeing). But SADQL is still based on the same principle of sql-based/xml-format that ADQL is based upon. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Masatoshi OHISHI > Sent: 04 February 2004 11:30 > To: martin hill > Cc: voql@ivoa.net > Subject: Re: SADQL schema > > > Martin, > > It seems to me that you have proposed to MODIFY our current > ADQL. Right ? > > Cheers, > > Masatoshi > > From owner-voql@eso.org Wed Feb 4 16:09: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 i14F8i3x003927 for ; Wed, 4 Feb 2004 16:08:44 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14F8ihF003926 for voql-outgoing; Wed, 4 Feb 2004 16:08:44 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14F8f3x003908 for ; Wed, 4 Feb 2004 16:08:41 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14F8dWR026198 for ; Wed, 4 Feb 2004 16:08:40 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i14F8cf14273 for voql@ivoa.net; Wed, 4 Feb 2004 10:08:38 -0500 Date: Wed, 4 Feb 2004 10:08:38 -0500 From: "Wil O'Mullane" To: voql@ivoa.net Subject: SADQL Message-ID: <20040204100838.Q26554@skysrv.pha.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: In defense of Martin he has put up a possible valid alternative to ADQL which bears looking at. I am defensive myself (much effort gone in ADQL), but I feel the specification still stands with SADQL it is only the schema which is called in question. In effect Martin has offered us an alternative for specific reasons. As a group we need to consider SADQL properly. We went through similar iterations with VOResource (and I am not sure we still have the correct answer). We have spent some time developing a SkyQuery-Portal which rewrites ADQL queries for SkyNodes involved in a Distributed join. If SADQL were adopted that would need to be re-written - not saying that it might not be easier. It is difficult to simplify ADQL, as it stands. It was not meant to be seen be people and it is automatically generated from a BNF. This, as Masatoshi pointed out, was pragmatic at the time. I have not attempted to make it simpler as we never intended for people to read it. Trying to simplify it is possibly pointless as it defeats the automation. Better perhaps, as Martin says (has done), to start over. But for a complete comparison I feel I have to challenge Martin to produce a converter for SQL<->SADQL and run the few queries we have through it. Although I know Tony has suggested we do not need a string representation I think we do. We will need to be able to express queries in the normal human way and I do not think even SADQL is sufficiently concise for that - we need SQL like syntax. One last point - even in your tools why are you building documents and not using the underlying classes generated by JAXB (btw new one supports Substitution groups !) or AXIS to create the ADQL queries. Even in a JSP page you could do this. There is no need for an item on a GUI to relate to a shard of XML directly - it may construct a 'Select' object etc. and then use the sterilizer to produce the actual XML in the end ? (OK I know Noel had some problems in this area but the in principal..) So to the group I ask which way you intend to use ADQL ? For us we would never generate these documents manually so I do not need SADQL. On the other hand Martin is so commited to crafting ADQL he has written a simplified schema to facilitate that. This I suppose is the core question which needs to be answered first. wil From owner-voql@eso.org Wed Feb 4 17:47:59 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 i14GlV3x029838 for ; Wed, 4 Feb 2004 17:47:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14GlVQT029834 for voql-outgoing; Wed, 4 Feb 2004 17:47:31 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14GlS3x029814 for ; Wed, 4 Feb 2004 17:47:28 +0100 (MET) Received: from rain.ipac.caltech.edu (rain.ipac.caltech.edu [134.4.10.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14GlPWR001601 for ; Wed, 4 Feb 2004 17:47:26 +0100 (CET) Received: from rain.ipac.caltech.edu (localhost [127.0.0.1]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id i14GlOj09849 for ; Wed, 4 Feb 2004 08:47:24 -0800 (PST) Received: from ipac.caltech.edu (cisco-srv4.ipac.caltech.edu [134.4.40.113]) by rain.ipac.caltech.edu (8.11.7-092403/8.11.6) with ESMTP id i14GlIV09833; Wed, 4 Feb 2004 08:47:19 -0800 (PST) Message-ID: <36B9CEFC.D42A4B09@ipac.caltech.edu> Date: Thu, 04 Feb 1999 08:46:52 -0800 From: John Good X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: ja,zh-TW,zh,zh-CN MIME-Version: 1.0 To: Noel Winstanley CC: martin hill , ael@star.le.ac.uk, voql@ivoa.net Subject: Re: SADQL schema (valid...) References: <005401c3eafa$5b69cd90$6124d28f@STAR.LE.AC.UK> <1075887205.4020bc650926b@netmail.pipex.net> <200402041039.17891.nw@jb.man.ac.uk> Content-Type: text/plain; charset=us-ascii 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-voql@eso.org Precedence: bulk Reply-To: John Good X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Am I missing something here? I don't see any join criterion between tables "s" and "g" in the SQL (or original XML) quoted. Also, which table does the 'Region' function operate on (assuming both have positional information) or is it meant to operate as a post-filter on the extracted tuple? That aside, I do agree strongly that the XML syntax needs to be easily human interpretable. - John Noel Winstanley wrote: > For the purposes of comparison... > > The example query Martin posted is equivalent to the following SQL > > select s.Ra_OBJ as RA, s.DECL_OBJ as DEC, g.ELIP as Elipticity, > s.MAG_B as Magnitude, g.SHAPE as Shape from SkyObject s, Galaxy g > where Region('Circle J2000 12.0, 13.0, 3.0') > and 0.7 <= g.ELIP > group by s.MAG_B > order by g.SHAPE > > I used the SQL-ADQL translator at > http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx > to generate the equivalent ADQL, which I've attached. From owner-voql@eso.org Wed Feb 4 18:03:46 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 i14H3U3x003594 for ; Wed, 4 Feb 2004 18:03:30 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14H3UDh003593 for voql-outgoing; Wed, 4 Feb 2004 18:03:30 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14H3Q3x003573 for ; Wed, 4 Feb 2004 18:03:26 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14H3NEY016214 for ; Wed, 4 Feb 2004 18:03:24 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14H3Mm7029475; Wed, 4 Feb 2004 17:03:22 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14H3MVA029474; Wed, 4 Feb 2004 17:03:22 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 17:03:21 +0000 Message-ID: <1075914201.402125d9ea143@netmail.pipex.net> Date: Wed, 4 Feb 2004 17:03:21 +0000 From: martin hill To: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: SADQL References: <20040204100838.Q26554@skysrv.pha.jhu.edu> In-Reply-To: <20040204100838.Q26554@skysrv.pha.jhu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, Thanks for that objective look - I know you guys have put work into it and have only had complaints recently. Yes we need an ADQL/string as well as ADQL/XML, and I'll look at doing a translator... We are using ADQL/XML rather than ADQL/String partly because the existing translators are broken, so we're finding people are having to work with the for-machine-ADQL. Maybe this is only temporary, but given our intention (at Astrogrid) is to use ADQL/XML as the medium for storing queries (as they can be properly validated), then it's likely that users will be looking at ADQL directly when it's on disk, and modifying from there. Also, us poor downtrodden developers are certainly going to be dealing with it directly! For larger queries (where the SQL reaches over a dozen or so conditionals) astronomers will prefer working with ADQL as it is better structured, readable and validation errors will get reported more accurately. Finally, I get the impression that astronomers are quite sceptical about new software, and I expect they will want to check the ADQL/XML produced from their submitted ADQL/Strings to see if they are submitting what they expect. Cheers, Martin Quoting Wil O'Mullane : > > In defense of Martin he has put up a possible valid alternative to ADQL > which bears looking at. I am defensive myself (much effort gone in ADQL), > but I feel the specification still stands with SADQL it is only the > schema which is called in question. In effect Martin has offered us an > alternative for specific reasons. As a group we > need to consider SADQL properly. We went through similar iterations with > VOResource (and I am not sure we still have the correct answer). > > We have spent some time developing a SkyQuery-Portal which rewrites ADQL > queries for SkyNodes involved in a Distributed join. If SADQL were adopted > that > would need to be re-written - not saying that it might not be easier. > > It is difficult to simplify ADQL, as it stands. It was not meant to be seen > be people and it is automatically generated from a BNF. This, as Masatoshi > pointed out, was pragmatic at the time. I have not attempted to make > it simpler as we never intended for people to read it. > Trying to simplify it is possibly pointless as it defeats the automation. > Better perhaps, as Martin says (has done), to start over. > > But for a complete comparison I feel I have to challenge Martin to produce a > converter for SQL<->SADQL and run the few queries we have through it. > Although I know Tony has suggested we do not need a string representation > I think we do. We will need to be able to express queries in the normal > human way and I do not think even SADQL is sufficiently concise for that - > we need SQL like syntax. > > One last point - even in your tools why are you building documents and not > using the underlying classes generated by JAXB (btw new one supports > Substitution groups !) or AXIS to create the ADQL queries. Even in a JSP page > you could do this. There is no need for an item on a GUI to relate to a shard > of XML directly - it may construct a 'Select' object etc. and then use the > sterilizer to produce the actual XML in the end ? > (OK I know Noel had some problems in this area but the in principal..) > > So to the group I ask which way you intend to use ADQL ? > > For us we would never generate these documents manually so I do not need > SADQL. On the other hand Martin is so commited to crafting ADQL he > has written a simplified schema to facilitate that. > > This I suppose is the core question which needs to be answered first. > > wil > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 18:03:50 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 i14H3Y3x003609 for ; Wed, 4 Feb 2004 18:03:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14H3Y8d003608 for voql-outgoing; Wed, 4 Feb 2004 18:03:34 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14H3P3x003568 for ; Wed, 4 Feb 2004 18:03:25 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14H3NWR002668 for ; Wed, 4 Feb 2004 18:03:24 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14H3Km7029461; Wed, 4 Feb 2004 17:03:21 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14H39fS029446; Wed, 4 Feb 2004 17:03:09 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 17:03:09 +0000 Message-ID: <1075914189.402125cd88ea1@netmail.pipex.net> Date: Wed, 4 Feb 2004 17:03:09 +0000 From: martin hill To: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: SADQL References: <20040204100838.Q26554@skysrv.pha.jhu.edu> In-Reply-To: <20040204100838.Q26554@skysrv.pha.jhu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, Thanks for that objective look - I know you guys have put work into it and have only had complaints recently. Yes we need an ADQL/string as well as ADQL/XML, and I'll look at doing a translator... We are using ADQL/XML rather than ADQL/String partly because the existing translators are broken, so we're finding people are having to work with the for-machine-ADQL. Maybe this is only temporary, but given our intention (at Astrogrid) is to use ADQL/XML as the medium for storing queries (as they can be properly validated), then it's likely that users will be looking at ADQL directly when it's on disk, and modifying from there. Also, us poor downtrodden developers are certainly going to be dealing with it directly! For larger queries (where the SQL reaches over a dozen or so conditionals) astronomers will prefer working with ADQL as it is better structured, readable and validation errors will get reported more accurately. Finally, I get the impression that astronomers are quite sceptical about new software, and I expect they will want to check the ADQL/XML produced from their submitted ADQL/Strings to see if they are submitting what they expect. Cheers, Martin Quoting Wil O'Mullane : > > In defense of Martin he has put up a possible valid alternative to ADQL > which bears looking at. I am defensive myself (much effort gone in ADQL), > but I feel the specification still stands with SADQL it is only the > schema which is called in question. In effect Martin has offered us an > alternative for specific reasons. As a group we > need to consider SADQL properly. We went through similar iterations with > VOResource (and I am not sure we still have the correct answer). > > We have spent some time developing a SkyQuery-Portal which rewrites ADQL > queries for SkyNodes involved in a Distributed join. If SADQL were adopted > that > would need to be re-written - not saying that it might not be easier. > > It is difficult to simplify ADQL, as it stands. It was not meant to be seen > be people and it is automatically generated from a BNF. This, as Masatoshi > pointed out, was pragmatic at the time. I have not attempted to make > it simpler as we never intended for people to read it. > Trying to simplify it is possibly pointless as it defeats the automation. > Better perhaps, as Martin says (has done), to start over. > > But for a complete comparison I feel I have to challenge Martin to produce a > converter for SQL<->SADQL and run the few queries we have through it. > Although I know Tony has suggested we do not need a string representation > I think we do. We will need to be able to express queries in the normal > human way and I do not think even SADQL is sufficiently concise for that - > we need SQL like syntax. > > One last point - even in your tools why are you building documents and not > using the underlying classes generated by JAXB (btw new one supports > Substitution groups !) or AXIS to create the ADQL queries. Even in a JSP page > you could do this. There is no need for an item on a GUI to relate to a shard > of XML directly - it may construct a 'Select' object etc. and then use the > sterilizer to produce the actual XML in the end ? > (OK I know Noel had some problems in this area but the in principal..) > > So to the group I ask which way you intend to use ADQL ? > > For us we would never generate these documents manually so I do not need > SADQL. On the other hand Martin is so commited to crafting ADQL he > has written a simplified schema to facilitate that. > > This I suppose is the core question which needs to be answered first. > > wil > -- Martin Hill 07901 55 24 66 www.mchill.net From owner-voql@eso.org Wed Feb 4 18:05:54 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 i14H5X3x004254 for ; Wed, 4 Feb 2004 18:05:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14H5Wxv004247 for voql-outgoing; Wed, 4 Feb 2004 18:05:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14H5C3x004157 for ; Wed, 4 Feb 2004 18:05:13 +0100 (MET) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14H5BWR002789 for ; Wed, 4 Feb 2004 18:05:11 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040204170507.BNBI26543.mta07-svc.ntlworld.com@gnowee> for ; Wed, 4 Feb 2004 17:05:07 +0000 From: "Tony Linde" To: Subject: RE: SADQL Date: Wed, 4 Feb 2004 17:06:11 -0000 Organization: University of Leicester Message-ID: <008d01c3eb41$36cb2370$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: <20040204100838.Q26554@skysrv.pha.jhu.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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I generally agree with Wil. > It is difficult to simplify ADQL, as it stands. It was not especially here :) > Martin to produce a converter for SQL<->SADQL and run the I think we only need a SADQL->SQL converter. (S)ADQL is meant to be generated by portals/query-builders/... This is then translated to SQL at the database. While it might be nice to have a SQL->(S)ADQL converter, the lack of it should not be seen as a limitation of the proposal. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 04 February 2004 15:09 > To: voql@ivoa.net > Subject: SADQL > > > > In defense of Martin he has put up a possible valid > alternative to ADQL > which bears looking at. I am defensive myself (much effort > gone in ADQL), > but I feel the specification still stands with SADQL it is only the > schema which is called in question. In effect Martin has > offered us an > alternative for specific reasons. As a group we > need to consider SADQL properly. We went through similar > iterations with VOResource (and I am not sure we still have > the correct answer). > > We have spent some time developing a SkyQuery-Portal which > rewrites ADQL queries for SkyNodes involved in a Distributed > join. If SADQL were adopted that would need to be re-written > - not saying that it might not be easier. > > It is difficult to simplify ADQL, as it stands. It was not > meant to be seen > be people and it is automatically generated from a BNF. This, > as Masatoshi pointed out, was pragmatic at the time. I have > not attempted to make it simpler as we never intended for > people to read it. Trying to simplify it is possibly > pointless as it defeats the automation. > Better perhaps, as Martin says (has done), to start over. > > But for a complete comparison I feel I have to challenge > Martin to produce a converter for SQL<->SADQL and run the > few queries we have through it. Although I know Tony has > suggested we do not need a string representation I think we > do. We will need to be able to express queries in the normal > human way and I do not think even SADQL is sufficiently > concise for that - we need SQL like syntax. > > One last point - even in your tools why are you building > documents and not using the underlying classes generated by > JAXB (btw new one supports Substitution groups !) or AXIS to > create the ADQL queries. Even in a JSP page you could do > this. There is no need for an item on a GUI to relate to a > shard of XML directly - it may construct a 'Select' object > etc. and then use the sterilizer to produce the actual XML in > the end ? (OK I know Noel had some problems in this area but > the in principal..) > > So to the group I ask which way you intend to use ADQL ? > > For us we would never generate these documents manually so I > do not need > SADQL. On the other hand Martin is so commited to crafting ADQL he > has written a simplified schema to facilitate that. > > This I suppose is the core question which needs to be answered first. > > wil > From owner-voql@eso.org Wed Feb 4 18:16:41 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 i14HGG3x009234 for ; Wed, 4 Feb 2004 18:16:16 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14HGFiL009231 for voql-outgoing; Wed, 4 Feb 2004 18:16:15 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14HG83x009189 for ; Wed, 4 Feb 2004 18:16:08 +0100 (MET) Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14HG6EY016918 for ; Wed, 4 Feb 2004 18:16:07 +0100 (CET) Received: from nmail1.systems.pipex.net (localhost [127.0.0.1]) by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i14HG6m7030209; Wed, 4 Feb 2004 17:16:06 GMT Received: (from nobody@localhost) by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i14HG63B030208; Wed, 4 Feb 2004 17:16:06 GMT Received: from 143.210.36.13 ( [143.210.36.13]) as user abm36@dial.pipex.com by netmail.pipex.net with HTTP; Wed, 4 Feb 2004 17:16:05 +0000 Message-ID: <1075914965.402128d5efd9d@netmail.pipex.net> Date: Wed, 4 Feb 2004 17:16:05 +0000 From: martin hill To: Tony Linde Cc: voql@ivoa.net Subject: RE: SADQL References: <008d01c3eb41$36cb2370$6124d28f@STAR.LE.AC.UK> In-Reply-To: <008d01c3eb41$36cb2370$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit User-Agent: PIPEX NetMail (IMP3.1) X-Originating-IP: 143.210.36.13 X-PIPEX-Username: abm36%dial.pipex.com X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use 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-voql@eso.org Precedence: bulk Reply-To: martin hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: There's certainly no reason why we can't handle both SADQL and ADQL as input languages into our datacenters. But having two standards is probably not in the spirit of things... We do need to have an SQL->SADQL converter as well, especially as astronomers will (at least initially, and possibly for all minor queries) want to type things in SQL-like strings. I must admit I would much prefer the NVO folks to write one, as you guys have proven skills in that, but I'm happy to give it a go (you can then all point and laugh). I will probably start with the SADQL->SQL one first though, as that will solve our immediate problem. Cheers, Martin Quoting Tony Linde : > I generally agree with Wil. > > > It is difficult to simplify ADQL, as it stands. It was not > > especially here :) > > > Martin to produce a converter for SQL<->SADQL and run the > > I think we only need a SADQL->SQL converter. (S)ADQL is meant to be > generated by portals/query-builders/... This is then translated to SQL at > the database. While it might be nice to have a SQL->(S)ADQL converter, the > lack of it should not be seen as a limitation of the proposal. > > Cheers, > Tony. From owner-voql@eso.org Wed Feb 4 18:39: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 i14Hda3x016037 for ; Wed, 4 Feb 2004 18:39:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14HdaAg016036 for voql-outgoing; Wed, 4 Feb 2004 18:39:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14HdX3x016024 for ; Wed, 4 Feb 2004 18:39:33 +0100 (MET) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14HdVWR004573 for ; Wed, 4 Feb 2004 18:39:32 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040204173930.MIGS28184.mta06-svc.ntlworld.com@gnowee> for ; Wed, 4 Feb 2004 17:39:30 +0000 From: "Tony Linde" To: Subject: RE: SADQL Date: Wed, 4 Feb 2004 17:40:38 -0000 Organization: University of Leicester Message-ID: <009101c3eb46$0388c940$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: <1075914189.402125cd88ea1@netmail.pipex.net> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > ADQL/XML as the medium for storing queries (as they can be > properly validated), > then it's likely that users will be looking at ADQL directly > when it's on disk, > and modifying from there. I wouldn't have thought so - it is more likely the user will reload the query into some sort of GUI query builder and modify from there. If they really want to load the xml into a text editor then good luck to them. Or, they can translate the ADQL into the text equivalent, modify that and retranslate it back for submission (low on my priority list). Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of martin hill > Sent: 04 February 2004 17:03 > To: Wil O'Mullane > Cc: voql@ivoa.net > Subject: Re: SADQL > > > Hi Wil, Thanks for that objective look - I know you guys have > put work into it > and have only had complaints recently. > > Yes we need an ADQL/string as well as ADQL/XML, and I'll look > at doing a > translator... > > We are using ADQL/XML rather than ADQL/String partly because > the existing > translators are broken, so we're finding people are having to > work with the > for-machine-ADQL. > > Maybe this is only temporary, but given our intention (at > Astrogrid) is to use > ADQL/XML as the medium for storing queries (as they can be > properly validated), > then it's likely that users will be looking at ADQL directly > when it's on disk, > and modifying from there. > > Also, us poor downtrodden developers are certainly going to > be dealing with it > directly! > > For larger queries (where the SQL reaches over a dozen or so > conditionals) > astronomers will prefer working with ADQL as it is better > structured, readable > and validation errors will get reported more accurately. > > Finally, I get the impression that astronomers are quite > sceptical about new > software, and I expect they will want to check the ADQL/XML > produced from their > submitted ADQL/Strings to see if they are submitting what they expect. > > Cheers, > > Martin > > > Quoting Wil O'Mullane : > > > > > In defense of Martin he has put up a possible valid alternative to > > ADQL > > which bears looking at. I am defensive myself (much effort > gone in ADQL), > > but I feel the specification still stands with SADQL it is only the > > schema which is called in question. In effect Martin has > offered us an > > alternative for specific reasons. As a group we > > need to consider SADQL properly. We went through similar > iterations with > > VOResource (and I am not sure we still have the correct answer). > > > > We have spent some time developing a SkyQuery-Portal which rewrites > > ADQL queries for SkyNodes involved in a Distributed join. If SADQL > > were adopted that would need to be re-written - not saying that it > > might not be easier. > > > > It is difficult to simplify ADQL, as it stands. It was not > meant to be > > seen > > be people and it is automatically generated from a BNF. > This, as Masatoshi > > pointed out, was pragmatic at the time. I have not attempted to make > > it simpler as we never intended for people to read it. > > Trying to simplify it is possibly pointless as it defeats > the automation. > > Better perhaps, as Martin says (has done), to start over. > > > > But for a complete comparison I feel I have to challenge Martin to > > produce a converter for SQL<->SADQL and run the few > queries we have > > through it. Although I know Tony has suggested we do not > need a string > > representation I think we do. We will need to be able to express > > queries in the normal human way and I do not think even SADQL is > > sufficiently concise for that - we need SQL like syntax. > > > > One last point - even in your tools why are you building > documents and > > not using the underlying classes generated by JAXB (btw new one > > supports Substitution groups !) or AXIS to create the ADQL queries. > > Even in a JSP page you could do this. There is no need for > an item on > > a GUI to relate to a shard of XML directly - it may construct a > > 'Select' object etc. and then use the sterilizer to produce > the actual > > XML in the end ? (OK I know Noel had some problems in this area but > > the in principal..) > > > > So to the group I ask which way you intend to use ADQL ? > > > > For us we would never generate these documents manually so I do not > > need > > SADQL. On the other hand Martin is so commited to crafting ADQL he > > has written a simplified schema to facilitate that. > > > > This I suppose is the core question which needs to be > answered first. > > > > wil > > > > > -- > Martin Hill > 07901 55 24 66 > www.mchill.net > From owner-voql@eso.org Wed Feb 4 18:48: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 i14HmS3x018025 for ; Wed, 4 Feb 2004 18:48:28 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14HmSHV018024 for voql-outgoing; Wed, 4 Feb 2004 18:48:28 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14HmK3x017999 for ; Wed, 4 Feb 2004 18:48:20 +0100 (MET) Received: from mta04-svc.ntlworld.com (mta04-svc.ntlworld.com [62.253.162.44]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14HmIWR005033 for ; Wed, 4 Feb 2004 18:48:18 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta04-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040204174810.YDBY22174.mta04-svc.ntlworld.com@gnowee> for ; Wed, 4 Feb 2004 17:48:10 +0000 From: "Tony Linde" To: Subject: RE: SADQL Date: Wed, 4 Feb 2004 17:49:14 -0000 Organization: University of Leicester Message-ID: <009201c3eb47$3d8aae50$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 In-Reply-To: <1075914965.402128d5efd9d@netmail.pipex.net> 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 i14HmQ3x018011 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > the NVO folks to > write one, as you guys have proven skills in that, but I'm > happy to give it a go Let's see if we need it first. How about someone providing a range of sample SQL queries and let's see the translations into ADQL/SADQL. Cheers, Tony. > -----Original Message----- > From: martin hill [mailto:mchill@dial.pipex.com] > Sent: 04 February 2004 17:16 > To: Tony Linde > Cc: voql@ivoa.net > Subject: RE: SADQL > > > There's certainly no reason why we can't handle both SADQL > and ADQL as input > languages into our datacenters. But having two standards is > probably not in the > spirit of things... > > We do need to have an SQL->SADQL converter as well, > especially as astronomers > will (at least initially, and possibly for all minor queries) > want to type > things in SQL-like strings. I must admit I would much prefer > the NVO folks to > write one, as you guys have proven skills in that, but I'm > happy to give it a go > (you can then all point and laugh). I will probably start > with the SADQL->SQL > one first though, as that will solve our immediate problem. > > Cheers, > > Martin > > Quoting Tony Linde : > > > I generally agree with Wil. > > > > > It is difficult to simplify ADQL, as it stands. It was not > > > > especially here :) > > > > > Martin to produce a converter for SQL<->SADQL and run the > > > > I think we only need a SADQL->SQL converter. (S)ADQL is meant to be > > generated by portals/query-builders/... This is then > translated to SQL > > at the database. While it might be nice to have a SQL->(S)ADQL > > converter, the lack of it should not be seen as a limitation of the > > proposal. > > > > Cheers, > > Tony. > From owner-voql@eso.org Wed Feb 4 19:19:52 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 i14IJZ3x023189 for ; Wed, 4 Feb 2004 19:19:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i14IJZCi023188 for voql-outgoing; Wed, 4 Feb 2004 19:19:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i14IJW3x023180 for ; Wed, 4 Feb 2004 19:19:32 +0100 (MET) Received: from po0.wam.umd.edu (po0.wam.umd.edu [128.8.10.162]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i14IJUEY020049 for ; Wed, 4 Feb 2004 19:19:30 +0100 (CET) Received: from gsfc.nasa.gov (atlas.astro.umd.edu [129.2.14.14]) by po0.wam.umd.edu (8.12.10/8.12.10) with ESMTP id i14IJO6w002265; Wed, 4 Feb 2004 13:19:27 -0500 (EST) Message-ID: <402134E6.8050605@gsfc.nasa.gov> Date: Wed, 04 Feb 2004 13:07:34 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" CC: voql@ivoa.net Subject: Re: SADQL References: <20040204100838.Q26554@skysrv.pha.jhu.edu> In-Reply-To: <20040204100838.Q26554@skysrv.pha.jhu.edu> Content-Type: text/plain; charset=ISO-8859-1; 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil, I think it is nice to have the BNF of the language around. But, I also think that ADQL is a bit unnecessarily cumbersome. What was the source of the BNF? Is it some official or standard representation of SQL that is accepted by the entire database community? Or is it something that we can simplify and then re-auto-generate the schema without the SQL-officianados calling foul? Ed Wil O'Mullane wrote: >In defense of Martin he has put up a possible valid alternative to ADQL >which bears looking at. I am defensive myself (much effort gone in ADQL), >but I feel the specification still stands with SADQL it is only the >schema which is called in question. In effect Martin has offered us an >alternative for specific reasons. As a group we >need to consider SADQL properly. We went through similar iterations with >VOResource (and I am not sure we still have the correct answer). > >We have spent some time developing a SkyQuery-Portal which rewrites ADQL queries for SkyNodes involved in a Distributed join. If SADQL were adopted that >would need to be re-written - not saying that it might not be easier. > >It is difficult to simplify ADQL, as it stands. It was not meant to be seen >be people and it is automatically generated from a BNF. This, as Masatoshi >pointed out, was pragmatic at the time. I have not attempted to make >it simpler as we never intended for people to read it. >Trying to simplify it is possibly pointless as it defeats the automation. >Better perhaps, as Martin says (has done), to start over. > >But for a complete comparison I feel I have to challenge Martin to produce a converter for SQL<->SADQL and run the few queries we have through it. >Although I know Tony has suggested we do not need a string representation >I think we do. We will need to be able to express queries in the normal >human way and I do not think even SADQL is sufficiently concise for that - >we need SQL like syntax. > >One last point - even in your tools why are you building documents and not using the underlying classes generated by JAXB (btw new one supports Substitution groups !) or AXIS to create the ADQL queries. Even in a JSP page you could do this. There is no need for an item on a GUI to relate to a shard of XML directly - it may construct a 'Select' object etc. and then use the sterilizer to produce the actual XML in the end ? >(OK I know Noel had some problems in this area but the in principal..) > >So to the group I ask which way you intend to use ADQL ? > >For us we would never generate these documents manually so I do not need >SADQL. On the other hand Martin is so commited to crafting ADQL he >has written a simplified schema to facilitate that. > >This I suppose is the core question which needs to be answered first. > >wil > > > From owner-voql@eso.org Thu Feb 5 07:39:51 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 i156d7Ic026961 for ; Thu, 5 Feb 2004 07:39:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i156d7F7026960 for voql-outgoing; Thu, 5 Feb 2004 07:39:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i156d4Ic026951 for ; Thu, 5 Feb 2004 07:39:05 +0100 (MET) 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 SMTP id i156d0WR001927 for ; Thu, 5 Feb 2004 07:39:00 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i156d0u11994 for ; Thu, 5 Feb 2004 00:39:00 -0600 Date: Thu, 5 Feb 2004 00:39:00 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: The case for XML ADQL In-Reply-To: <004701c3e8ae$217a1bb0$0b01a8c0@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: As one of the loud voices insisting on having an XML version of ADQL, I feel I should put in my 2c. As Wil, Tony, and others have mentioned, XML is easier to parse than SQL. This begs the question, why would you want to parse the query. Similarly, by not having an XML version suggests that there is no reason to parse the query. In my mind, the need to parse the query is clear. The first reason is obvious: there is no universally supported standard SQL--all vendors differ in small annoying ways. However, I think there is a more important issue independant of the SQL standard: I believe it will be quite common for the tables that are exposed to the outside will differ substantially from what is actually on disk. The differences may be as simple as the names used for the columns to hiding the complexity of highly normalized tables to integration with alternate database technologies. While some differences might be handle via database VIEWs; but some will not be so simple. This is less likely to apply to your basic object catalog that are typically flat and simple; however, observation archives usually manage more a more complex data model that is easily by todays browser-based interfaces. Only by allowing pre-database parsing affords the flexibility to adapt to the variety of data models that I suspect exists out there. BTW, I believe that handling something as complex as ADQL by deserializing it into Java objects as is done autmatically with WS toolkits and packages like JAXB/Castor is a recipe for heartbreak. (People have complained about the chain of function calls necessary to navigate VOResource--it's the same problem.) Learn XSL and use it to convert it to the SQL (or whatever else). cheers, Ray From owner-voql@eso.org Thu Feb 5 08:15: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 i157EqIc000727 for ; Thu, 5 Feb 2004 08:14:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i157Eqrj000725 for voql-outgoing; Thu, 5 Feb 2004 08:14:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i157EnIc000714 for ; Thu, 5 Feb 2004 08:14:49 +0100 (MET) 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 SMTP id i157ElEY015881 for ; Thu, 5 Feb 2004 08:14:48 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i157Emf12429 for ; Thu, 5 Feb 2004 01:14:48 -0600 Date: Thu, 5 Feb 2004 01:14:48 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: Query Language specifications 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: One comment I've been meaning to make about the ADQL spec (which others have alluded to) but would also apply to any alternative with ambitions for standardization. I'm uncomfortable with the idea of a standard being represented by a schema with no documentation. The semantic meaning of all those tags are just as important as the syntax. As ADQL is now, it is assumed that we all know the semantic mappings; however, assumptions are not what specifications are made of. IMHO, any schema that goes through our standardization process should somewhere include a semantic definition for each elements in the schema. XML Schema has a standard way of supporting inline documentation; we should use it. It should greatly help our discussions. cheers, Ray From owner-voql@eso.org Thu Feb 5 09:50: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 i158oKIc017044 for ; Thu, 5 Feb 2004 09:50:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i158oKpI017043 for voql-outgoing; Thu, 5 Feb 2004 09:50:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i158oGIc017020 for ; Thu, 5 Feb 2004 09:50:16 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i158oDEY018910 for ; Thu, 5 Feb 2004 09:50:14 +0100 (CET) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 00:50:18 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 00:50:11 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 00:50:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 00:50:10 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490222B48C@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The case for XML ADQL Thread-Index: AcPrttU8wocXefZ/Rh+mTj+ow/PnpAADgEeQ From: "Jim Gray" To: "Ray Plante" , X-OriginalArrivalTime: 05 Feb 2004 08:50:11.0590 (UTC) FILETIME=[1096AA60:01C3EBC5] 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 i158oKIc017040 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Computers are good at parsing People are good at other things. Making ADQL convenient for computers seems the wrong optimization. Jim Gray Microsoft Research, Suite 1690, 455 Market, SF CA 94105, tel: 415 778 8222 fax: 425 706 7329 Gray@Microsoft.com http://research.Microsoft.com/~gray -----Original Message----- From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Ray Plante Sent: Wednesday, February 04, 2004 10:39 PM To: voql@ivoa.net Subject: The case for XML ADQL As one of the loud voices insisting on having an XML version of ADQL, I feel I should put in my 2c. As Wil, Tony, and others have mentioned, XML is easier to parse than SQL. This begs the question, why would you want to parse the query. Similarly, by not having an XML version suggests that there is no reason to parse the query. In my mind, the need to parse the query is clear. The first reason is obvious: there is no universally supported standard SQL--all vendors differ in small annoying ways. However, I think there is a more important issue independant of the SQL standard: I believe it will be quite common for the tables that are exposed to the outside will differ substantially from what is actually on disk. The differences may be as simple as the names used for the columns to hiding the complexity of highly normalized tables to integration with alternate database technologies. While some differences might be handle via database VIEWs; but some will not be so simple. This is less likely to apply to your basic object catalog that are typically flat and simple; however, observation archives usually manage more a more complex data model that is easily by todays browser-based interfaces. Only by allowing pre-database parsing affords the flexibility to adapt to the variety of data models that I suspect exists out there. BTW, I believe that handling something as complex as ADQL by deserializing it into Java objects as is done autmatically with WS toolkits and packages like JAXB/Castor is a recipe for heartbreak. (People have complained about the chain of function calls necessary to navigate VOResource--it's the same problem.) Learn XSL and use it to convert it to the SQL (or whatever else). cheers, Ray From owner-voql@eso.org Thu Feb 5 10:12:04 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 i159BmIc021198 for ; Thu, 5 Feb 2004 10:11:48 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i159BmWT021197 for voql-outgoing; Thu, 5 Feb 2004 10:11:48 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i159BhIc021178 for ; Thu, 5 Feb 2004 10:11:43 +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 i159BfEY019871 for ; Thu, 5 Feb 2004 10:11:42 +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 1AofXx-0005kv-41 for voql@ivoa.net; Thu, 05 Feb 2004 09:11:41 +0000 Received: (qmail 22881 invoked from network); 5 Feb 2004 09:11:56 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 09:11:56 -0000 From: "Tony Linde" To: "'Jim Gray'" , "'Ray Plante'" , Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 09:12:51 -0000 Organization: University of Leicester Message-ID: <001f01c3ebc8$3b160030$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490222B48C@RED-MSG-31.redmond.corp.microsoft.com> 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 i159BlIc021193 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: While I think I've been the strongest proponent of making schemas complex (and so developer's lives difficult) so that the user's lives can be made easy (ask Ray :) ), I also think we need to make sure that it is relatively straight-forward to turn an adql query into a sql query as this is going to be required at every data centre. An xml-form of adql is going to be much easier to translate into the end sql. If the people at all the data centres have to write adql/text parsers in order to translate queries into their own flavour of sql (and, as Ray says, which matches their own particular implementation), then the VO is not going to spread too quickly. But Jim is also right that some users will want to type in a text form of query and have it automatically converted to the xml-form before it is sent out to chosen data centres. So we need both forms of adql: adql/text and adql/xml. But the standard form of query transmission should be adql/xml and for this reason it should be our priority. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Jim Gray > Sent: 05 February 2004 08:50 > To: Ray Plante; voql@ivoa.net > Subject: RE: The case for XML ADQL > > > Computers are good at parsing > People are good at other things. > Making ADQL convenient for computers seems the wrong optimization. > > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Ray Plante > Sent: Wednesday, February 04, 2004 10:39 PM > To: voql@ivoa.net > Subject: The case for XML ADQL > > As one of the loud voices insisting on having an XML version > of ADQL, I feel I should put in my 2c. As Wil, Tony, and > others have mentioned, XML is easier to parse than SQL. This > begs the question, why would you want to parse the query. > Similarly, by not having an XML version suggests that there > is no reason to parse the query. > > In my mind, the need to parse the query is clear. The first reason is > obvious: there is no universally supported standard SQL--all > vendors differ in small annoying ways. However, I think > there is a more important issue independant of the SQL > standard: I believe it will be quite common for the tables > that are exposed to the outside will differ substantially > from what is actually on disk. The differences may be as > simple as the names used for the columns to hiding the > complexity of highly normalized tables to integration with > alternate database technologies. While some differences > might be handle via database VIEWs; but some will not be so > simple. This is less likely to apply to your basic object > catalog that are typically flat and simple; however, > observation archives usually manage more a more complex data > model that is easily by todays browser-based interfaces. > Only by allowing pre-database parsing affords the flexibility > to adapt to the variety of data models that I suspect exists > out there. > > BTW, I believe that handling something as complex as ADQL by > deserializing it into Java objects as is done autmatically > with WS toolkits and packages like JAXB/Castor is a recipe > for heartbreak. (People have complained about the chain of > function calls necessary to navigate VOResource--it's the > same problem.) Learn XSL and use it to convert it to the SQL > (or whatever else). > > cheers, > Ray > > > From owner-voql@eso.org Thu Feb 5 10:24: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 i159O1Ic022787 for ; Thu, 5 Feb 2004 10:24:01 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i159O0Sv022785 for voql-outgoing; Thu, 5 Feb 2004 10:24:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i159NvIc022755 for ; Thu, 5 Feb 2004 10:23:57 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i159NtWR006946 for ; Thu, 5 Feb 2004 10:23:55 +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 1Aofjm-0006pF-PO for voql@ivoa.net; Thu, 05 Feb 2004 09:23:54 +0000 Received: (qmail 26336 invoked from network); 5 Feb 2004 09:24:14 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 09:24:14 -0000 From: "Tony Linde" To: Subject: Other SQL constructs Date: Thu, 5 Feb 2004 09:25:09 -0000 Organization: University of Leicester Message-ID: <002001c3ebc9$f3447690$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 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/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: At an AstroGrid meeting yesterday we discussed the need for the query language to support CREATE TABLE, DROP TABLE, SELECT INTO, UPDATE etc. I've looked at the schema and I think the answer is 'no', but does the current version of ADQL support these constructs? If not, can someone point us at the tools/BNF used to construct the schema so that AstroGrid can extend adql to include these constructs - we'll be using them in the near future and I'd rather do so in the spirit of the way that adql is currently built than hack about with the schema directly. Thanks, 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-voql@eso.org Thu Feb 5 10:26:03 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 i159PoIc023085 for ; Thu, 5 Feb 2004 10:25:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i159PneD023084 for voql-outgoing; Thu, 5 Feb 2004 10:25:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i159PkIc023069 for ; Thu, 5 Feb 2004 10:25:46 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i159PiWR007015 for ; Thu, 5 Feb 2004 10:25:45 +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 1AoflY-00075O-5V for voql@ivoa.net; Thu, 05 Feb 2004 09:25:44 +0000 Received: (qmail 26872 invoked from network); 5 Feb 2004 09:26:04 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 09:26:04 -0000 From: "Tony Linde" To: Subject: FW: SADQL Date: Thu, 5 Feb 2004 09:26:59 -0000 Organization: University of Leicester Message-ID: <002101c3ebca$3466cf60$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 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/) Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This came to me directly... -----Original Message----- From: Wil O'Mullane [mailto:womullan@skysrv.pha.jhu.edu] Sent: 04 February 2004 18:37 To: Tony Linde Subject: Re: SADQL I sugested the few which are on the converter page none are very complex http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx On Wed, Feb 04, 2004 at 05:49:14PM -0000, Tony Linde wrote: > > the NVO folks to > > write one, as you guys have proven skills in that, but I'm > > happy to give it a go > > Let's see if we need it first. How about someone providing a range of > sample SQL queries and let's see the translations into ADQL/SADQL. > > Cheers, > Tony. > From owner-voql@eso.org Thu Feb 5 10:34:34 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 i159YHIc024565 for ; Thu, 5 Feb 2004 10:34:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i159YHIO024564 for voql-outgoing; Thu, 5 Feb 2004 10:34:17 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i159YBIc024525 for ; Thu, 5 Feb 2004 10:34:11 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i159Y7EY020631 for ; Thu, 5 Feb 2004 10:34:08 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id SAA13141; Thu, 5 Feb 2004 18:33:58 +0900 (JST) Message-Id: <6.0.0.20.2.20040205182429.0449dec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Thu, 05 Feb 2004 18:34:01 +0900 To: "Tony Linde" , "'Jim Gray'" , "'Ray Plante'" , From: Masatoshi OHISHI Subject: RE: The case for XML ADQL In-Reply-To: <001f01c3ebc8$3b160030$6124d28f@STAR.LE.AC.UK> References: <25603A6EFF8BA34AB2A49615383CD4490222B48C@RED-MSG-31.redmond.corp.microsoft.com> <001f01c3ebc8$3b160030$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, While I was absent from my office for a while, many many emails have flown (^_^!! At 09:12 04/02/05 +0000, Tony Linde wrote: >So we need both forms of adql: adql/text and adql/xml. But the standard form >of query transmission should be adql/xml and for this reason it should be >our priority. This is my understanding. And ADQL/text is called as SkyQL, as you all know ! I agree with Ray in that we have to specify semantic form of SkyQL more clealy. And the issue is discuss on the tagged-XML form for faster (?) translation between SkyQL, ADQL and native SQL at each data center. BTW, do you know why it was so slow to translate from current ADQL to SQL, and so on ? Cheers, Masatoshi ps. I have too many meetings here in Japan..... From owner-voql@eso.org Thu Feb 5 10:52: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 i159pqIc000201 for ; Thu, 5 Feb 2004 10:51:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i159pqTa000200 for voql-outgoing; Thu, 5 Feb 2004 10:51:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i159poIc000185 for ; Thu, 5 Feb 2004 10:51:50 +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 i159pmEY021350 for ; Thu, 5 Feb 2004 10:51:48 +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 1AogAl-0002iE-Qj for voql@ivoa.net; Thu, 05 Feb 2004 09:51:47 +0000 Received: (qmail 4547 invoked from network); 5 Feb 2004 09:51:29 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 09:51:29 -0000 From: "Tony Linde" To: Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 09:52:23 -0000 Organization: University of Leicester Message-ID: <002401c3ebcd$c125aa40$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <6.0.0.20.2.20040205182429.0449dec0@mail.mtk.nao.ac.jp> 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 i159ppIc000195 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Welcome back Masatoshi, > This is my understanding. And ADQL/text is called as SkyQL, > as you all know ! I remember commenting on one of the previous versions of the spec that we should *not* have two different names or versions of the language (and I believe it was accepted). The only query language is ADQL, its primary format is the xml form and we will specify how the xml form can be translated into a text form for display purposes. Anyone who wants to provide a text input service will have to write a parser that translates from the text form into the standard xml form. Cheers, Tony. > -----Original Message----- > From: Masatoshi OHISHI [mailto:masatoshi.ohishi@nao.ac.jp] > Sent: 05 February 2004 09:34 > To: Tony Linde; 'Jim Gray'; 'Ray Plante'; voql@ivoa.net > Subject: RE: The case for XML ADQL > > > Tony, > > While I was absent from my office for a while, many many > emails have flown (^_^!! > > At 09:12 04/02/05 +0000, Tony Linde wrote: > >So we need both forms of adql: adql/text and adql/xml. But > the standard form >of query transmission should be adql/xml > and for this reason it should be >our priority. > > This is my understanding. And ADQL/text is called as SkyQL, > as you all know ! > > I agree with Ray in that we have to specify semantic form of > SkyQL more clealy. And the issue is discuss on the tagged-XML > form for faster (?) translation between SkyQL, ADQL and > native SQL at each data center. > > BTW, do you know why it was so slow to translate from current > ADQL to SQL, and so on ? > > Cheers, > > Masatoshi > > ps. I have too many meetings here in Japan..... > > From owner-voql@eso.org Thu Feb 5 11:12:55 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 i15ACXIc004708 for ; Thu, 5 Feb 2004 11:12:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15ACX6L004707 for voql-outgoing; Thu, 5 Feb 2004 11:12:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15ACUIc004693 for ; Thu, 5 Feb 2004 11:12:30 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15ACRWR009224 for ; Thu, 5 Feb 2004 11:12:28 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id TAA17523; Thu, 5 Feb 2004 19:12:22 +0900 (JST) Message-Id: <6.0.0.20.2.20040205190454.0447ca20@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Thu, 05 Feb 2004 19:12:24 +0900 To: "Tony Linde" , From: Masatoshi OHISHI Subject: RE: The case for XML ADQL In-Reply-To: <002401c3ebcd$c125aa40$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040205182429.0449dec0@mail.mtk.nao.ac.jp> <002401c3ebcd$c125aa40$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, At 09:52 04/02/05 +0000, Tony Linde wrote: >Welcome back Masatoshi, Long way to come back here (^_^!! I haven't got the reason why you found that your translator was so slow. >should *not* have two different names or versions of the language (and I >believe it was accepted). The only query language is ADQL, its primary >format is the xml form and we will specify how the xml form can be >translated into a text form for display purposes. Yes, we need to aviod any confusion, whatever the name is. So, at this moment, I call ADQL/s (s stands for string) and ADQL/x. In JVO, we can edit ADQL/s on a user's window. This is so useful because users can save her/his previous ADQL/s as files in her/his client machine, can load the files into the client interface, and then edit, if necessay. This method is much faster for users when repeating queries with a little modification. Cheers, Masatoshi From owner-voql@eso.org Thu Feb 5 11:15: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 i15AEsIc005167 for ; Thu, 5 Feb 2004 11:14:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15AEsJJ005165 for voql-outgoing; Thu, 5 Feb 2004 11:14:54 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15AEpIc005146 for ; Thu, 5 Feb 2004 11:14:51 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15AEoWR009307 for ; Thu, 5 Feb 2004 11:14:50 +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 1AogX3-0005fi-Em for voql@ivoa.net; Thu, 05 Feb 2004 10:14:49 +0000 Received: (qmail 10463 invoked from network); 5 Feb 2004 10:15:09 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 10:15:09 -0000 Date: Thu, 5 Feb 2004 10:14:49 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: RE: The case for XML ADQL In-Reply-To: <002401c3ebcd$c125aa40$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 Feb 2004, Tony Linde wrote: > Anyone who wants to provide a text input service will have to write a parser > that translates from the text form into the standard xml form. I think it will be essential to have converters in both directions between ADQL/text (alias SkyQL) and ADQL/XML. We have already found that it is exceedingly difficult to test software which requires fully formed XML as its input, so the testers need to be able to input ADQL/text. I think power users who are already familiar with SQL will want to be able to continue using it (or something very similar) - they will not take kindly to instructions to learn ADQL/XML. Thirdly, the ADQL/text form has very limited extensibility: if some backend can provide additional facilities such as stored procedures/user-defined functions, then these would be unusable from ADQL/XML until the parsers have been modified and tested, but a pass-through of ADQL/text would be able to use these extensions immediately, and they might (if suitable) be incorporated into the standard at some future date. A living language needs a simple route for growth. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Thu Feb 5 11:27:55 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 i15AReIc008136 for ; Thu, 5 Feb 2004 11:27:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15ARe5a008135 for voql-outgoing; Thu, 5 Feb 2004 11:27:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15ARaIc008116 for ; Thu, 5 Feb 2004 11:27:36 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15ARZEY022991 for ; Thu, 5 Feb 2004 11:27:35 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1AogjO-0002Gq-AZ for voql@ivoa.net; Thu, 05 Feb 2004 10:27:34 +0000 Received: (qmail 13476 invoked from network); 5 Feb 2004 10:27:48 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 10:27:48 -0000 Date: Thu, 5 Feb 2004 10:27:27 +0000 (GMT) From: Clive Page To: womullan@skysrv.pha.jhu.edu cc: voql@ivoa.net Subject: Re: FW: SADQL In-Reply-To: <002101c3ebca$3466cf60$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 Feb 2004, Tony Linde wrote: > I sugested the few which are on the converter page > none are very complex > http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx Wil In case others are finding, as I do, that this doesn't work at present, then this could be because you are not using the right browser. I find using Mozilla that whatever I submit comes up with the same results: which, I suspect, is the XML equivalent of "void" or maybe error 404. I just re-tried using IE and it works. Even if it worked with Mozilla it would be hard to use at present as both text boxes are tiny, just a couple of lines x 16 characters wide. On the whole Mozilla seems to conform to most WWW standards, but I'm not enough of an expert to know whether the problem here is a Microsoftism, or whether Mozilla has some defect with pages that are standard-conforming. Maybe some web standards expert will know... Regards -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-voql@eso.org Thu Feb 5 13:15:41 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 i15CFHr1028739 for ; Thu, 5 Feb 2004 13:15:17 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15CFHUE028737 for voql-outgoing; Thu, 5 Feb 2004 13:15:17 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15CFDr1028718 for ; Thu, 5 Feb 2004 13:15:13 +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 SMTP id i15BaHWR012908 for ; Thu, 5 Feb 2004 12:36:17 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Aohns-0006C9-T9 for voql@ivoa.net; Thu, 05 Feb 2004 11:36:16 +0000 Received: (qmail 10297 invoked from network); 5 Feb 2004 11:36:37 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 11:36:37 -0000 Date: Thu, 5 Feb 2004 11:36:16 +0000 (GMT) From: Clive Page To: Noel Winstanley cc: voql@ivoa.net Subject: Re: FW: SADQL In-Reply-To: <200402051121.54675.nw@jb.man.ac.uk> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 Feb 2004, Noel Winstanley wrote: > I don't think this is an issue with the browser. I find this happens when the > translator fails - although it doesn't produce any error message. > > The translator will fail if there's a syntax error in the input sql. > > It also fails when the input SQL is not in the form it expects - all tables > seem to need aliases, and all columns need to be qualified by table names. > > Take a look at the sample SQL queries the page supplies - your own query must > be in a similar format. Noel There shouldn't be any error in the SQL, as I am _just_ using the example queries got by pressing the buttons, and these look fine to me, and presumably were checked by Wil and colleagues. These work fine every time with I use IE, but fail every time when using Mozilla. Seems pretty powerful evidence to me that it's browser related. Anyone got a non-Gecko powered browser to try (I don't think Lynx will cope, somehow). -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Thu Feb 5 13:15:51 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 i15CFLr1028766 for ; Thu, 5 Feb 2004 13:15:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15CFLWY028765 for voql-outgoing; Thu, 5 Feb 2004 13:15:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15CFDr3028718 for ; Thu, 5 Feb 2004 13:15:17 +0100 (MET) Received: from mta5-svc.business.ntl.com (mta5-svc.business.ntl.com [62.253.164.45]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15BRsWR012522 for ; Thu, 5 Feb 2004 12:27:54 +0100 (CET) Received: from client-1913-p1-sms.winn.adsl.virgin.net ([81.107.199.120]) by mta5-svc.business.ntl.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040205112753.RWDL7725.mta5-svc.business.ntl.com@client-1913-p1-sms.winn.adsl.virgin.net>; Thu, 5 Feb 2004 11:27:53 +0000 From: Noel Winstanley Organization: Jodrell Bank Observatory To: Clive Page , womullan@skysrv.pha.jhu.edu Subject: Re: FW: SADQL Date: Thu, 5 Feb 2004 11:21:54 +0000 User-Agent: KMail/1.5.4 Cc: voql@ivoa.net References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402051121.54675.nw@jb.man.ac.uk> 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-voql@eso.org Precedence: bulk Reply-To: Noel Winstanley X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thursday 05 Feb 2004 10:27 am, Clive Page wrote: > In case others are finding, as I do, that this doesn't work at present, > then this could be because you are not using the right browser. I find > using Mozilla that whatever I submit comes up with the same results: > > > I don't think this is an issue with the browser. I find this happens when the translator fails - although it doesn't produce any error message. The translator will fail if there's a syntax error in the input sql. It also fails when the input SQL is not in the form it expects - all tables seem to need aliases, and all columns need to be qualified by table names. Take a look at the sample SQL queries the page supplies - your own query must be in a similar format. -- Dr Noel Winstanley - nw@jb.man.ac.uk 01477 572689 Senior Java Developer, Astrogrid Project. Jodrell Bank Observatory, University of Manchester. From owner-voql@eso.org Thu Feb 5 13:34: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 i15CYIr1003013 for ; Thu, 5 Feb 2004 13:34:18 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15CYIO2003011 for voql-outgoing; Thu, 5 Feb 2004 13:34:18 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15CYAr1002958 for ; Thu, 5 Feb 2004 13:34:10 +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 SMTP id i15CY8WR015324 for ; Thu, 5 Feb 2004 13:34:09 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Aoihr-0002O9-V2 for voql@ivoa.net; Thu, 05 Feb 2004 12:34:07 +0000 Received: (qmail 27691 invoked from network); 5 Feb 2004 12:34:27 -0000 Received: from sparky.star.le.ac.uk (143.210.36.10) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 12:34:27 -0000 Date: Thu, 5 Feb 2004 12:34:28 +0000 (GMT) From: "Patricio F. Ortiz" To: Clive Page cc: Noel Winstanley , Subject: Re: FW: SADQL In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: "Patricio F. Ortiz" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Clive, It is possible that the problem resides in the UTF declaration. UTF-16 means that the document is encoded in unicode, while UTF-8 is 8 bit representation (eg, ASCII). I also use mozilla, so I can't help. One point that worries me for any future QL: > On Thu, 5 Feb 2004, Noel Winstanley wrote: > > The translator will fail if there's a syntax error in the input sql. > > > > It also fails when the input SQL is not in the form it expects - all tables > > seem to need aliases, and all columns need to be qualified by table names. I assume that at some point we would like to generalize queries in such a way that we pass UCDs instead of column names, particularly when we have no idea how these columns are names each table of a large table collection. I would expect a QL to pass that information without choking and once the table the query is passed to transform the UCDs in column names with the aid of a registry if the DBMS does not support UCD notation. Cheers, Patricio --- Patricio F. Ortiz pfo@star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UK From owner-voql@eso.org Thu Feb 5 13:57:59 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 i15Ct7r1008446 for ; Thu, 5 Feb 2004 13:55:08 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15Ct722008445 for voql-outgoing; Thu, 5 Feb 2004 13:55:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15Ct0r1008382 for ; Thu, 5 Feb 2004 13:55:00 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15CswEY029156 for ; Thu, 5 Feb 2004 13:54:59 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Aoj22-0003U4-9N for voql@ivoa.net; Thu, 05 Feb 2004 12:54:58 +0000 Received: (qmail 2724 invoked from network); 5 Feb 2004 12:55:18 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 12:55:18 -0000 From: "Tony Linde" To: "'Clive Page'" , Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 12:56:12 -0000 Organization: University of Leicester Message-ID: <003201c3ebe7$6f37b380$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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 i15Ct6r1008431 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > and tested, but a pass-through of ADQL/text would be able to ^^^^^^^^^^^^^^^^^^^^ This is somewhat a contradiction. Pass-through implies that it is bypassing the adql parser. In this case you would have to write SQL in the variant of the database you are targeting. It would have to be up to a portal to provide a text box for this and we'd have to provide a pass-through facility in the DAL standard. If you mean the ability to type in ADQL/s for parsing into the ADQL/x form for transmission to a data centre and translation into local SQL then, yes, this is something that power users will want and some portals will provide. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Clive Page > Sent: 05 February 2004 10:15 > To: voql@ivoa.net > Subject: RE: The case for XML ADQL > > > On Thu, 5 Feb 2004, Tony Linde wrote: > > > Anyone who wants to provide a text input service will have > to write a > > parser that translates from the text form into the standard > xml form. > > I think it will be essential to have converters in both > directions between ADQL/text (alias SkyQL) and ADQL/XML. We > have already found that it is exceedingly difficult to test > software which requires fully formed XML as its input, so the > testers need to be able to input ADQL/text. I think power > users who are already familiar with SQL will want to be able > to continue using it (or something very similar) - they will > not take kindly to instructions to learn ADQL/XML. Thirdly, > the ADQL/text form has very limited extensibility: if some > backend can provide additional facilities such as stored > procedures/user-defined functions, then these would be > unusable from ADQL/XML until the parsers have been modified > and tested, but a pass-through of ADQL/text would be able to > use these extensions immediately, and they might (if > suitable) be incorporated into the standard at some future > date. A living language needs a simple route for growth. > > > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, Tel +44 116 252 3551 > Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 > From owner-voql@eso.org Thu Feb 5 14:00: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 i15Cwor1009561 for ; Thu, 5 Feb 2004 13:58:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15CwoXn009560 for voql-outgoing; Thu, 5 Feb 2004 13:58:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15Cwmr1009535 for ; Thu, 5 Feb 2004 13:58:48 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15CwjEY029339 for ; Thu, 5 Feb 2004 13:58:45 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Aoj5g-0003fl-UU for voql@ivoa.net; Thu, 05 Feb 2004 12:58:44 +0000 Received: (qmail 3418 invoked from network); 5 Feb 2004 12:59:03 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 12:59:03 -0000 From: "Tony Linde" To: "'Masatoshi OHISHI'" , Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 12:59:58 -0000 Organization: University of Leicester Message-ID: <003301c3ebe7$f5622ad0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <6.0.0.20.2.20040205190454.0447ca20@mail.mtk.nao.ac.jp> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > I haven't got the reason why you found that your translator > was so slow. I've no idea - maybe Martin can answer. > This method is much faster for users when repeating queries > with a little modification. Agreed - but a portal which had a gui interface could do the same by saving the adql/x form and loading it into the gui fields for modification. Cheers, Tony. > -----Original Message----- > From: Masatoshi OHISHI [mailto:masatoshi.ohishi@nao.ac.jp] > Sent: 05 February 2004 10:12 > To: Tony Linde; voql@ivoa.net > Subject: RE: The case for XML ADQL > > > Hi Tony, > > At 09:52 04/02/05 +0000, Tony Linde wrote: > >Welcome back Masatoshi, > > Long way to come back here (^_^!! > > I haven't got the reason why you found that your translator > was so slow. > > >should *not* have two different names or versions of the > language (and I >believe it was accepted). The only query > language is ADQL, its primary >format is the xml form and we > will specify how the xml form can be >translated into a text > form for display purposes. > > Yes, we need to aviod any confusion, whatever the name is. > > So, at this moment, I call ADQL/s (s stands for string) and ADQL/x. > > In JVO, we can edit ADQL/s on a user's window. This is so > useful because users can save her/his previous ADQL/s as > files in her/his client machine, can load the files into the > client interface, and then edit, if necessay. > > This method is much faster for users when repeating queries > with a little modification. > > Cheers, > > Masatoshi > > From owner-voql@eso.org Thu Feb 5 14:08:37 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 i15D87r1012200 for ; Thu, 5 Feb 2004 14:08:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15D87S6012198 for voql-outgoing; Thu, 5 Feb 2004 14:08:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15D84r1012185 for ; Thu, 5 Feb 2004 14:08:04 +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 SMTP id i15D7xWR016926 for ; Thu, 5 Feb 2004 14:07:59 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1AojEc-00048i-Rt for voql@ivoa.net; Thu, 05 Feb 2004 13:07:58 +0000 Received: (qmail 5533 invoked from network); 5 Feb 2004 13:08:19 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 13:08:19 -0000 From: "Tony Linde" To: Subject: RE: FW: SADQL Date: Thu, 5 Feb 2004 13:09:13 -0000 Organization: University of Leicester Message-ID: <003401c3ebe9$406bcda0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Works okay in Mozilla for me. Are you selecting everything in the result box? If you click in the box, then type Control-A, it should select everything and you can then paste into something to read it easier. T. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Clive Page > Sent: 05 February 2004 10:27 > To: womullan@skysrv.pha.jhu.edu > Cc: voql@ivoa.net > Subject: Re: FW: SADQL > > > On Thu, 5 Feb 2004, Tony Linde wrote: > > > I sugested the few which are on the converter page > > none are very complex > > http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx > > Wil > > In case others are finding, as I do, that this doesn't work > at present, then this could be because you are not using the > right browser. I find using Mozilla that whatever I submit > comes up with the same results: > > > > which, I suspect, is the XML equivalent of "void" or maybe error 404. > > I just re-tried using IE and it works. Even if it worked > with Mozilla it would be hard to use at present as both text > boxes are tiny, just a couple of lines x 16 characters wide. > > On the whole Mozilla seems to conform to most WWW standards, > but I'm not enough of an expert to know whether the problem > here is a Microsoftism, or whether Mozilla has some defect > with pages that are standard-conforming. Maybe some web > standards expert will know... > > > Regards > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. > > From owner-voql@eso.org Thu Feb 5 14:16: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 i15DFur1013782 for ; Thu, 5 Feb 2004 14:15:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15DFtvo013780 for voql-outgoing; Thu, 5 Feb 2004 14:15:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15DFqr1013766 for ; Thu, 5 Feb 2004 14:15:52 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15DFoEY000191 for ; Thu, 5 Feb 2004 14:15:51 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1AojMD-0004XU-5q for voql@ivoa.net; Thu, 05 Feb 2004 13:15:49 +0000 Received: (qmail 7262 invoked from network); 5 Feb 2004 13:16:09 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 13:16:09 -0000 Date: Thu, 5 Feb 2004 13:15:48 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: RE: FW: SADQL In-Reply-To: <003401c3ebe9$406bcda0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 Feb 2004, Tony Linde wrote: > Works okay in Mozilla for me. Are you selecting everything in the result > box? If you click in the box, then type Control-A, it should select > everything and you can then paste into something to read it easier. Ah, you're right. I tried scrolling the scroll bar and got nothing other than the top line, but didn't think of trying a "select all". OK, no problem (but it would be nice to have text boxes of more than midget size, in which case I would have seen the extra lines). -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-voql@eso.org Thu Feb 5 15:30: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 i15ETOVS001383 for ; Thu, 5 Feb 2004 15:29:24 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15ETOYf001382 for voql-outgoing; Thu, 5 Feb 2004 15:29:24 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15ETCVS001307 for ; Thu, 5 Feb 2004 15:29:12 +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 SMTP id i15ETAWR021132 for ; Thu, 5 Feb 2004 15:29:11 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1AokVB-0000ks-Hz for voql@ivoa.net; Thu, 05 Feb 2004 14:29:09 +0000 Received: (qmail 23078 invoked from network); 5 Feb 2004 14:29:24 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 5 Feb 2004 14:29:24 -0000 From: "Tony Linde" To: Subject: RE: The case for XML ADQL Date: Thu, 5 Feb 2004 14:30:19 -0000 Organization: University of Leicester Message-ID: <003501c3ebf4$948c5c00$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <6.0.0.20.2.20040205190454.0447ca20@mail.mtk.nao.ac.jp> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi, > In JVO, we can edit ADQL/s on a user's window. This is so > useful because users can save her/his previous ADQL/s as > files in her/his client machine, can load the files into the > client interface, and then edit, if necessay. Do you have a ADQL/s -> ADQL/x parser/translator? (preferably in Java) Cheers, Tony. > -----Original Message----- > From: Masatoshi OHISHI [mailto:masatoshi.ohishi@nao.ac.jp] > Sent: 05 February 2004 10:12 > To: Tony Linde; voql@ivoa.net > Subject: RE: The case for XML ADQL > > > Hi Tony, > > At 09:52 04/02/05 +0000, Tony Linde wrote: > >Welcome back Masatoshi, > > Long way to come back here (^_^!! > > I haven't got the reason why you found that your translator > was so slow. > > >should *not* have two different names or versions of the > language (and I >believe it was accepted). The only query > language is ADQL, its primary >format is the xml form and we > will specify how the xml form can be >translated into a text > form for display purposes. > > Yes, we need to aviod any confusion, whatever the name is. > > So, at this moment, I call ADQL/s (s stands for string) and ADQL/x. > > In JVO, we can edit ADQL/s on a user's window. This is so > useful because users can save her/his previous ADQL/s as > files in her/his client machine, can load the files into the > client interface, and then edit, if necessay. > > This method is much faster for users when repeating queries > with a little modification. > > Cheers, > > Masatoshi > > From owner-voql@eso.org Thu Feb 5 15:31: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 i15EVYVS002057 for ; Thu, 5 Feb 2004 15:31:34 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15EVXsg002056 for voql-outgoing; Thu, 5 Feb 2004 15:31:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15EVPVS002023 for ; Thu, 5 Feb 2004 15:31:25 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15EVLWR021266 for ; Thu, 5 Feb 2004 15:31:21 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i15EVKR00494 for voql@ivoa.net; Thu, 5 Feb 2004 09:31:20 -0500 Date: Thu, 5 Feb 2004 09:31:20 -0500 From: "Wil O'Mullane" To: voql@ivoa.net Subject: Re: FW: SADQL Message-ID: <20040205093120.O26554@skysrv.pha.jhu.edu> References: <002101c3ebca$3466cf60$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Thu, Feb 05, 2004 at 10:27:27AM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is backed be a webService which is really what I though peole would use the ASPX page was really just to see it was working. http://skyservice.pha.jhu.edu/devel/AdqlTranslator/ADQLTrans.asmx On Thu, Feb 05, 2004 at 10:27:27AM +0000, Clive Page wrote: > On Thu, 5 Feb 2004, Tony Linde wrote: > > > I sugested the few which are on the converter page > > none are very complex > > http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx > > Wil > > In case others are finding, as I do, that this doesn't work at present, > then this could be because you are not using the right browser. I find > using Mozilla that whatever I submit comes up with the same results: > > > > which, I suspect, is the XML equivalent of "void" or maybe error 404. > > I just re-tried using IE and it works. Even if it worked with Mozilla it > would be hard to use at present as both text boxes are tiny, just a couple > of lines x 16 characters wide. > > On the whole Mozilla seems to conform to most WWW standards, but I'm not > enough of an expert to know whether the problem here is a Microsoftism, or > whether Mozilla has some defect with pages that are standard-conforming. > Maybe some web standards expert will know... > > > Regards > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. > From owner-voql@eso.org Thu Feb 5 15:33:54 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 i15EXRVS002523 for ; Thu, 5 Feb 2004 15:33:27 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15EXRJi002522 for voql-outgoing; Thu, 5 Feb 2004 15:33:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15EXOVS002510 for ; Thu, 5 Feb 2004 15:33:24 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15EXMEY004262 for ; Thu, 5 Feb 2004 15:33:23 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i15EXGB00541; Thu, 5 Feb 2004 09:33:16 -0500 Date: Thu, 5 Feb 2004 09:33:16 -0500 From: "Wil O'Mullane" To: Noel Winstanley Cc: Clive Page , voql@ivoa.net Subject: Re: FW: SADQL Message-ID: <20040205093316.P26554@skysrv.pha.jhu.edu> References: <200402051121.54675.nw@jb.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200402051121.54675.nw@jb.man.ac.uk>; from nw@jb.man.ac.uk on Thu, Feb 05, 2004 at 11:21:54AM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > > It also fails when the input SQL is not in the form it expects - all tables > seem to need aliases, and all columns need to be qualified by table names. You have corectly deduced what is required in the specification ... From owner-voql@eso.org Thu Feb 5 15:50:00 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 i15EnUVS006442 for ; Thu, 5 Feb 2004 15:49:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15EnUqq006441 for voql-outgoing; Thu, 5 Feb 2004 15:49:30 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15EnQVS006421 for ; Thu, 5 Feb 2004 15:49:26 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i15EnOEY005209 for ; Thu, 5 Feb 2004 15:49:25 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i15EnMo00939; Thu, 5 Feb 2004 09:49:22 -0500 Date: Thu, 5 Feb 2004 09:49:22 -0500 From: "Wil O'Mullane" To: Clive Page Cc: voql@ivoa.net Subject: Re: FW: SADQL Message-ID: <20040205094922.S26554@skysrv.pha.jhu.edu> References: <003401c3ebe9$406bcda0$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cgp@star.le.ac.uk on Thu, Feb 05, 2004 at 01:15:48PM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I think it looks okay in Mozilla now - added some adornments to it.. On Thu, Feb 05, 2004 at 01:15:48PM +0000, Clive Page wrote: > On Thu, 5 Feb 2004, Tony Linde wrote: > > > Works okay in Mozilla for me. Are you selecting everything in the result > > box? If you click in the box, then type Control-A, it should select > > everything and you can then paste into something to read it easier. > > Ah, you're right. I tried scrolling the scroll bar and got nothing other > than the top line, but didn't think of trying a "select all". > > OK, no problem (but it would be nice to have text boxes of more than > midget size, in which case I would have seen the extra lines). > > -- > Clive Page > Dept of Physics & Astronomy, > University of Leicester, > Leicester, LE1 7RH, U.K. From owner-voql@eso.org Thu Feb 5 16:08:55 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 i15F8ZVS012399 for ; Thu, 5 Feb 2004 16:08:35 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i15F8Z40012398 for voql-outgoing; Thu, 5 Feb 2004 16:08:35 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i15F8PVS012349 for ; Thu, 5 Feb 2004 16:08:25 +0100 (MET) 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 SMTP id i15F8NWR023462 for ; Thu, 5 Feb 2004 16:08:23 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i15F8LY19791 for ; Thu, 5 Feb 2004 09:08:22 -0600 Date: Thu, 5 Feb 2004 09:08:21 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: RE: The case for XML ADQL In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490222B48C@RED-MSG-31.redmond.corp.microsoft.com> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Thu, 5 Feb 2004, Jim Gray wrote: > Computers are good at parsing > People are good at other things. > Making ADQL convenient for computers seems the wrong optimization. That's fine if my computer is going to write my parsing program for me. Optimize the user interface for the user; optimize the wire format for the server. The point to appreciate here is that, in practice, there will *not* be a unique mapping from ADQL to the SQL consumed on the server side. A human, therefore, must define the mapping somehow. Even if we had a nice configurable SQL parser/transformer toolkit somewhere, we would need to provide it in all the languages that providers use. XML can be the universal language that we all can integrate with. Note that on the user/client side we don't have this problem. No query transformation is necessary on there: there will be a unique mapping from SQL (SkyQL) to ADQL. Thus, using an "OTS" translater makes sense. More importantly, this is not the providers problem. I expect there to be more provider interfaces than different client applications, so the multi-language issue is much less of a problem. Finally, consider portals. Do we expect any query manipulation necessary there...? cheers, Ray From owner-voql@eso.org Fri Feb 6 11:46:31 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 i16Ak41L015572 for ; Fri, 6 Feb 2004 11:46:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16Ak4mF015567 for voql-outgoing; Fri, 6 Feb 2004 11:46:04 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Ak01L015535 for ; Fri, 6 Feb 2004 11:46:00 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16AjtEY017567 for ; Fri, 6 Feb 2004 11:45:56 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id TAA14279; Fri, 6 Feb 2004 19:45:50 +0900 (JST) Message-Id: <6.0.0.20.2.20040206193818.044c6ec0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Fri, 06 Feb 2004 19:45:47 +0900 To: , From: Masatoshi OHISHI Subject: RE: The case for XML ADQL In-Reply-To: <003301c3ebe7$f5622ad0$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040205190454.0447ca20@mail.mtk.nao.ac.jp> <003301c3ebe7$f5622ad0$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, At 12:59 04/02/05 +0000, Tony Linde wrote: > a portal which had a gui interface could do the same by saving >the adql/x form and loading it into the gui fields for modification. That's true. But people have to use the GUI to modify her/his ADQL. If we allow to keep the queries as ADQL/s, people can use any editors. Another advantage, I believe, is the files are much smaller than ADQL/x. JVO's user interface has GUI which generates ADQL/s (at present we call them JVOQL, still) and can edit loaded ADQL/s text very easily. Anyhow, the design of the user interface could be different from VO to VO. Therefore I propose to have both versions of ADQL: ADQL/s and ADQL/x. I think both have the primary status. Cheers, Masatoshi From owner-voql@eso.org Fri Feb 6 12:08:14 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 i16B7t1L020927 for ; Fri, 6 Feb 2004 12:07:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16B7trQ020926 for voql-outgoing; Fri, 6 Feb 2004 12:07:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16B7q1L020905 for ; Fri, 6 Feb 2004 12:07:53 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16B7mEY018394 for ; Fri, 6 Feb 2004 12:07:50 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id UAA16340; Fri, 6 Feb 2004 20:07:43 +0900 (JST) Message-Id: <6.0.0.20.2.20040206200445.0441d8e0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Fri, 06 Feb 2004 20:07:44 +0900 To: "Tony Linde" , From: Masatoshi OHISHI Subject: RE: The case for XML ADQL In-Reply-To: <003501c3ebf4$948c5c00$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040205190454.0447ca20@mail.mtk.nao.ac.jp> <003501c3ebf4$948c5c00$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, At 14:30 04/02/05 +0000, Tony Linde wrote: >Do you have a ADQL/s -> ADQL/x parser/translator? (preferably in Java) Our current parser is written by using the Java CC, and the output is kept as a Java class. This is because our prototype is a closed one. However it is not difficult to output as an XML format, as you can easily understand. Cheers, Masatoshi From owner-voql@eso.org Fri Feb 6 12:51:28 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 i16Bov1L028752 for ; Fri, 6 Feb 2004 12:50:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16BovJ0028751 for voql-outgoing; Fri, 6 Feb 2004 12:50:57 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Bot1L028741 for ; Fri, 6 Feb 2004 12:50:55 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16BorWR006139 for ; Fri, 6 Feb 2004 12:50:53 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap4VY-0003Ac-Dx for voql@ivoa.net; Fri, 06 Feb 2004 11:50:52 +0000 Received: (qmail 22417 invoked from network); 6 Feb 2004 11:51:12 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 11:51:12 -0000 From: "Tony Linde" To: Subject: RE: The case for XML ADQL Date: Fri, 6 Feb 2004 11:52:07 -0000 Organization: University of Leicester Message-ID: <002a01c3eca7$a59f4d00$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <6.0.0.20.2.20040206200445.0441d8e0@mail.mtk.nao.ac.jp> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Masatoshi, Is the code available for download? Cheers, Tony. > -----Original Message----- > From: Masatoshi OHISHI [mailto:masatoshi.ohishi@nao.ac.jp] > Sent: 06 February 2004 11:08 > To: Tony Linde; voql@ivoa.net > Subject: RE: The case for XML ADQL > > > Hi Tony, > > At 14:30 04/02/05 +0000, Tony Linde wrote: > >Do you have a ADQL/s -> ADQL/x parser/translator? > (preferably in Java) > > Our current parser is written by using the Java CC, and the > output is kept as a Java class. This is because our prototype > is a closed one. > > However it is not difficult to output as an XML format, as > you can easily understand. > > Cheers, > > Masatoshi > > From owner-voql@eso.org Fri Feb 6 14:48:10 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 i16DlR1L022908 for ; Fri, 6 Feb 2004 14:47:28 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16DlRRb022907 for voql-outgoing; Fri, 6 Feb 2004 14:47:27 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Dl41L022761 for ; Fri, 6 Feb 2004 14:47:04 +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 SMTP id i16Dl2WR010842 for ; Fri, 6 Feb 2004 14:47:03 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 9F2391C000EC; Fri, 6 Feb 2004 13:47:01 +0000 (GMT) Message-ID: <40239ADC.2080409@dial.pipex.com> Date: Fri, 06 Feb 2004 13:47:08 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page Cc: voql@ivoa.net Subject: Re: The case for XML ADQL 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: In fact there's no real difference between extending ADQL/string and ADQL/xml. We can't in practice allow ADQL/string to pass through 'blind' in general for security reasons, so ADQL/string parsers will need to be updated to provide for new functions. Anyway there will usually need to be a translation layer to get to the local SQL form, and ADQL/XML gives us the one->many rather than many->many combinations we need. We *do* need to ensure scope for adding new functions, but this has to be treated carefully; ADQL is meant to be a *standard* query language that we can apply across a range of datacenters. If a particular datacenter implements a particular new function, but other datacenters do not, we lose the 'generality' of it. So I suggest that the datacenter-specific functions do not need to be built into the ADQL language itself, but either inserted as an unchecked element, eg: HtmIdenitfier or by creating a datacenter-specific ADQL schema that extends the standard one. Cheers, Martin Clive Page wrote: > On Thu, 5 Feb 2004, Tony Linde wrote: > > >>Anyone who wants to provide a text input service will have to write a parser >>that translates from the text form into the standard xml form. > > > I think it will be essential to have converters in both directions between > ADQL/text (alias SkyQL) and ADQL/XML. We have already found that it is > exceedingly difficult to test software which requires fully formed XML as > its input, so the testers need to be able to input ADQL/text. I think > power users who are already familiar with SQL will want to be able to > continue using it (or something very similar) - they will not take kindly > to instructions to learn ADQL/XML. Thirdly, the ADQL/text form has very > limited extensibility: if some backend can provide additional facilities > such as stored procedures/user-defined functions, then these would be > unusable from ADQL/XML until the parsers have been modified and tested, > but a pass-through of ADQL/text would be able to use these extensions > immediately, and they might (if suitable) be incorporated into the > standard at some future date. A living language needs a simple route for > growth. > > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 14:56:37 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 i16Du41L025495 for ; Fri, 6 Feb 2004 14:56:04 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16Dh1Aw021541 for voql-outgoing; Fri, 6 Feb 2004 14:43:01 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16DgU1L021424 for ; Fri, 6 Feb 2004 14:42:30 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16DgSEY024595 for ; Fri, 6 Feb 2004 14:42:29 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id AF0501C000B8; Fri, 6 Feb 2004 13:42:27 +0000 (GMT) Message-ID: <402399CA.5080603@dial.pipex.com> Date: Fri, 06 Feb 2004 13:42:34 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Linde Cc: voql@ivoa.net Subject: Re: Other SQL constructs References: <002001c3ebc9$f3447690$6124d28f@STAR.LE.AC.UK> In-Reply-To: <002001c3ebc9$f3447690$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: ADQL (and SADQL) are currently query languages only. I think we should consider carefully how we handle database changes compared to queries (esp as we at AstroGrid may have several ways to delete a table), and whether such things ought to be implemented in S/ADQL, or as a completely seperate database manipulation language, or as an extension to S/ADQL with its own schema... We certainly need an INTO which I've just added to the S/ADQL schema, so that the querier can specify where the results should go, and what format they should be returned in. Tony Linde wrote: > At an AstroGrid meeting yesterday we discussed the need for the query > language to support CREATE TABLE, DROP TABLE, SELECT INTO, UPDATE etc. I've > looked at the schema and I think the answer is 'no', but does the current > version of ADQL support these constructs? > > If not, can someone point us at the tools/BNF used to construct the schema > so that AstroGrid can extend adql to include these constructs - we'll be > using them in the near future and I'd rather do so in the spirit of the way > that adql is currently built than hack about with the schema directly. > > Thanks, > 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/ > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 14:56:37 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 i16Du41N025495 for ; Fri, 6 Feb 2004 14:56:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16Di0TJ021772 for voql-outgoing; Fri, 6 Feb 2004 14:44:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16DhT1L021621 for ; Fri, 6 Feb 2004 14:43:29 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16DhREY024646 for ; Fri, 6 Feb 2004 14:43:27 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 209221C001F1; Fri, 6 Feb 2004 13:43:26 +0000 (GMT) Message-ID: <40239A05.6000703@dial.pipex.com> Date: Fri, 06 Feb 2004 13:43:33 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Good Cc: voql@ivoa.net Subject: Re: SADQL schema (valid...) References: <005401c3eafa$5b69cd90$6124d28f@STAR.LE.AC.UK> <1075887205.4020bc650926b@netmail.pipex.net> <200402041039.17891.nw@jb.man.ac.uk> <36B9CEFC.D42A4B09@ipac.caltech.edu> In-Reply-To: <36B9CEFC.D42A4B09@ipac.caltech.edu> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi John Both the cross-match join and region functions are implemented as special functions by the dataset owners. This means that the functions are not as explicit as most SQL functions; the dataset owner will make decisions such as which columns to use for the cross match. The join criteria for the cross match is based on the position, the error in that position, and the confidence level (sigma) you want to apply to the match. The region function should indeed (I believe) take column references as arguments for the position. That is just a typo within this particular example. There is a small inconsistency between the syntax of the two functions in ADQL/String (SkyQL?); the cross match returns a number and so the full expression is written as a formula: XMatch(table1, table2) < sigma whereas the region search returns a boolean, with all the constraints given as parameters: Area(table.RaColumn, table.DecColumn, radius) BTW - your computer date seems to be set to 1999... Cheers, Martin John Good wrote: > Am I missing something here? I don't see any > join criterion between tables "s" and "g" in the > SQL (or original XML) quoted. Also, which table > does the 'Region' function operate on (assuming > both have positional information) or is it meant > to operate as a post-filter on the extracted tuple? > > That aside, I do agree strongly that the XML > syntax needs to be easily human interpretable. > > - John > > > Noel Winstanley wrote: > > >>For the purposes of comparison... >> >>The example query Martin posted is equivalent to the following SQL >> >>select s.Ra_OBJ as RA, s.DECL_OBJ as DEC, g.ELIP as Elipticity, >>s.MAG_B as Magnitude, g.SHAPE as Shape from SkyObject s, Galaxy g >>where Region('Circle J2000 12.0, 13.0, 3.0') >>and 0.7 <= g.ELIP >>group by s.MAG_B >>order by g.SHAPE >> >>I used the SQL-ADQL translator at >>http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx >>to generate the equivalent ADQL, which I've attached. > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 15:46:52 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 i16EkW7l009281 for ; Fri, 6 Feb 2004 15:46:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16EkWDw009280 for voql-outgoing; Fri, 6 Feb 2004 15:46:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16EkS7l009255 for ; Fri, 6 Feb 2004 15:46:28 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16EkQWR013833 for ; Fri, 6 Feb 2004 15:46:27 +0100 (CET) Received: (from womullan@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i16EkQu21742 for voql@ivoa.net; Fri, 6 Feb 2004 09:46:26 -0500 Date: Fri, 6 Feb 2004 09:46:25 -0500 From: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: The case for XML ADQL Message-ID: <20040206094625.D21454@skysrv.pha.jhu.edu> References: <40239ADC.2080409@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40239ADC.2080409@dial.pipex.com>; from mchill@dial.pipex.com on Fri, Feb 06, 2004 at 01:47:08PM +0000 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-voql@eso.org Precedence: bulk Reply-To: "Wil O'Mullane" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: The SKyNode Spec deals with this - why overload ADQL. The DataCenter should publish available functions in standard manner. Similiar to the way it publishes tables,cols,ucds etc.. In you previous mail you have slipped an 'into' into ADQL. Now that is not in the spec which is on the table so far. Now SADQL departs from the prose specification. If we want 'into' in our semantic at this stage then we need to revise the specification also. This is a seperate issue to SADQL vs ADQL xml syntax. wil On Fri, Feb 06, 2004 at 01:47:08PM +0000, Martin Hill wrote: > In fact there's no real difference between extending ADQL/string and ADQL/xml. > We can't in practice allow ADQL/string to pass through 'blind' in general for > security reasons, so ADQL/string parsers will need to be updated to provide for > new functions. Anyway there will usually need to be a translation layer to get > to the local SQL form, and ADQL/XML gives us the one->many rather than > many->many combinations we need. > > We *do* need to ensure scope for adding new functions, but this has to be > treated carefully; ADQL is meant to be a *standard* query language that we can > apply across a range of datacenters. If a particular datacenter implements a > particular new function, but other datacenters do not, we lose the 'generality' > of it. > > So I suggest that the datacenter-specific functions do not need to be built into > the ADQL language itself, but either inserted as an unchecked element, eg: > > > HtmIdenitfier > > > or by creating a datacenter-specific ADQL schema that extends the standard one. > > Cheers, > > Martin > > Clive Page wrote: > > > On Thu, 5 Feb 2004, Tony Linde wrote: > > > > > >>Anyone who wants to provide a text input service will have to write a parser > >>that translates from the text form into the standard xml form. > > > > > > I think it will be essential to have converters in both directions between > > ADQL/text (alias SkyQL) and ADQL/XML. We have already found that it is > > exceedingly difficult to test software which requires fully formed XML as > > its input, so the testers need to be able to input ADQL/text. I think > > power users who are already familiar with SQL will want to be able to > > continue using it (or something very similar) - they will not take kindly > > to instructions to learn ADQL/XML. Thirdly, the ADQL/text form has very > > limited extensibility: if some backend can provide additional facilities > > such as stored procedures/user-defined functions, then these would be > > unusable from ADQL/XML until the parsers have been modified and tested, > > but a pass-through of ADQL/text would be able to use these extensions > > immediately, and they might (if suitable) be incorporated into the > > standard at some future date. A living language needs a simple route for > > growth. > > > > > > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org From owner-voql@eso.org Fri Feb 6 15:46:58 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 i16Ekg7l009324 for ; Fri, 6 Feb 2004 15:46:42 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16Ekgpt009322 for voql-outgoing; Fri, 6 Feb 2004 15:46:42 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Ekd7l009305 for ; Fri, 6 Feb 2004 15:46:39 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16EkbWR013846 for ; Fri, 6 Feb 2004 15:46:38 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap7Fd-0005aA-6k for voql@ivoa.net; Fri, 06 Feb 2004 14:46:37 +0000 Received: (qmail 6375 invoked from network); 6 Feb 2004 14:46:57 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 14:46:57 -0000 Date: Fri, 6 Feb 2004 14:46:36 +0000 (GMT) From: Clive Page To: Tony Linde , Subject: Re: Other SQL constructs In-Reply-To: <402399CA.5080603@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 6 Feb 2004, Martin Hill wrote: > ADQL (and SADQL) are currently query languages only. Well so is SQL called a query language, but it has handy things like UPDATE, DELETE, DROP, and more creatively, CREATE. I think ADQL will need the same. The SQL example isn't necessarily a good one to follow, but I think we are mostly agreed that it's better to follow it than to invent something that might be worse. > (esp as we at AstroGrid may have several ways to delete a table) Really: you mean like - all at once versus a byte at a time? Or do you mean like really delete it versus moving it to the grid-wastebasket (an ikon of a black-hole might be appropriate for that, unless someone has already copyrighted that idea). -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Fri Feb 6 15:52:55 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 i16EqV7l010727 for ; Fri, 6 Feb 2004 15:52:31 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16EqVcE010726 for voql-outgoing; Fri, 6 Feb 2004 15:52:31 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16EqS7l010713 for ; Fri, 6 Feb 2004 15:52:28 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16EqPEY028163 for ; Fri, 6 Feb 2004 15:52:26 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap7LE-0005ua-Tx for voql@ivoa.net; Fri, 06 Feb 2004 14:52:24 +0000 Received: (qmail 7616 invoked from network); 6 Feb 2004 14:52:40 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 14:52:40 -0000 From: "Tony Linde" To: Subject: RE: The case for XML ADQL Date: Fri, 6 Feb 2004 14:53:35 -0000 Organization: University of Leicester Message-ID: <003101c3ecc0$ff3b05c0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <40239ADC.2080409@dial.pipex.com> 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 i16EqU7l010723 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > We can't in practice allow ADQL/string to pass through > 'blind' in general for Allowing passthrough of native SQL (not ADQL) is up to a data centre to allow/disallow: we need some way of indicating it in the registry. Every dataset with a web interface at the moment is providing passthrough SQL so shouldn't be a problem. > We *do* need to ensure scope for adding new functions, but New functions need to be namespaced in some way with a data centre providing something in its resource entry saying which function namespace it supports. T. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Martin Hill > Sent: 06 February 2004 13:47 > To: Clive Page > Cc: voql@ivoa.net > Subject: Re: The case for XML ADQL > > > In fact there's no real difference between extending > ADQL/string and ADQL/xml. > We can't in practice allow ADQL/string to pass through > 'blind' in general for > security reasons, so ADQL/string parsers will need to be > updated to provide for > new functions. Anyway there will usually need to be a > translation layer to get > to the local SQL form, and ADQL/XML gives us the one->many > rather than > many->many combinations we need. > > We *do* need to ensure scope for adding new functions, but > this has to be > treated carefully; ADQL is meant to be a *standard* query > language that we can > apply across a range of datacenters. If a particular > datacenter implements a > particular new function, but other datacenters do not, we > lose the 'generality' > of it. > > So I suggest that the datacenter-specific functions do not > need to be built into > the ADQL language itself, but either inserted as an unchecked > element, eg: > > > HtmIdenitfier > > > or by creating a datacenter-specific ADQL schema that extends > the standard one. > > Cheers, > > Martin > > Clive Page wrote: > > > On Thu, 5 Feb 2004, Tony Linde wrote: > > > > > >>Anyone who wants to provide a text input service will have > to write a > >>parser that translates from the text form into the standard > xml form. > > > > > > I think it will be essential to have converters in both directions > > between ADQL/text (alias SkyQL) and ADQL/XML. We have > already found > > that it is exceedingly difficult to test software which > requires fully > > formed XML as its input, so the testers need to be able to input > > ADQL/text. I think power users who are already familiar > with SQL will > > want to be able to continue using it (or something very similar) - > > they will not take kindly to instructions to learn > ADQL/XML. Thirdly, > > the ADQL/text form has very limited extensibility: if some > backend can > > provide additional facilities such as stored > procedures/user-defined > > functions, then these would be unusable from ADQL/XML until the > > parsers have been modified and tested, but a pass-through > of ADQL/text > > would be able to use these extensions immediately, and they > might (if > > suitable) be incorporated into the standard at some future date. A > > living language needs a simple route for growth. > > > > > > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > From owner-voql@eso.org Fri Feb 6 16:03:37 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 i16F3N7l013513 for ; Fri, 6 Feb 2004 16:03:23 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16F3N4s013512 for voql-outgoing; Fri, 6 Feb 2004 16:03:23 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16F3J7l013494 for ; Fri, 6 Feb 2004 16:03:19 +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 SMTP id i16F3HWR014669 for ; Fri, 6 Feb 2004 16:03:17 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 8E6841C00311; Fri, 6 Feb 2004 15:03:14 +0000 (GMT) Message-ID: <4023ACB9.8080002@dial.pipex.com> Date: Fri, 06 Feb 2004 15:03:21 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wil O'Mullane" Cc: voql@ivoa.net Subject: Re: The case for XML ADQL References: <40239ADC.2080409@dial.pipex.com> <20040206094625.D21454@skysrv.pha.jhu.edu> In-Reply-To: <20040206094625.D21454@skysrv.pha.jhu.edu> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Wil O'Mullane wrote: > The SKyNode Spec deals with this - why overload ADQL. > The DataCenter should publish available functions in standard manner. > Similiar to the way it publishes tables,cols,ucds etc.. I thought we were splitting the Query Language specification out from the general SkyNode Spec? And anyway how does the spec deal with it without the schema dealing with it? I tend to work on the basis that the schema is our way of agreeing the implementations - ie making sure that our web services publish their interface exactly, rather than relying on separate human-only documents. Yes I quite agree that functions should be published in the center's metadata. -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 16:09:00 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 i16F8j7l014858 for ; Fri, 6 Feb 2004 16:08:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16F8jx6014857 for voql-outgoing; Fri, 6 Feb 2004 16:08:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16F8g7l014847 for ; Fri, 6 Feb 2004 16:08:42 +0100 (MET) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16F8bWR014940 for ; Fri, 6 Feb 2004 16:08:39 +0100 (CET) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Feb 2004 07:08:30 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Feb 2004 07:08:32 -0800 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Feb 2004 07:08:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: The case for building ADQL from a SQL core. Date: Fri, 6 Feb 2004 07:08:28 -0800 Message-ID: <25603A6EFF8BA34AB2A49615383CD4490226BBC6@RED-MSG-31.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The case for building ADQL from a SQL core. Thread-Index: AcPsuu/DdSxvlVoERpmGGksbU72GMgABrRDA From: "Jim Gray" To: "Martin Hill" , "Clive Page" Cc: X-OriginalArrivalTime: 06 Feb 2004 15:08:31.0532 (UTC) FILETIME=[1538AEC0:01C3ECC3] 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 i16F8j7l014854 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Jim Gray" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I agree: "there's no real difference between extending ADQL/string and ADQL/xml." In both cases, you start from zero and have to write a man-page for every feature (since you start with the empty set and build ADQL) The point is that there is a huge difference between subsetting SQL and creating a new core language from scratch. In the subsetting approach you hijack the years of language design and skills of the SQL folks. In the creating a new core lanugage you go it alone and have to do that design and write those man pages yourself. That is a BIG difference. The current efforts been defining language syntax (in xml) and leaving the semantics to the reader. The semantics are the hard part. Hijacking someone else's semantics is a lot easier. So, there is a BIG difference between the two approaches. The SQL first approch can just hijack the semantics for this rather complex expression SELECT > INTO > FROM > WHERE > GROUP BY > HAVING > ORDER BY > > One has to modify the naming and explain about MyDB and > define the non-standard functions, but that is easy compared > to explaining the semantics of this beast. > > > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Martin Hill > Sent: Friday, February 06, 2004 5:47 AM > To: Clive Page > Cc: voql@ivoa.net > Subject: Re: The case for XML ADQL > > In fact there's no real difference between extending > ADQL/string and ADQL/xml. > We can't in practice allow ADQL/string to pass through > 'blind' in general for security reasons, so ADQL/string > parsers will need to be updated to provide for new functions. > Anyway there will usually need to be a translation layer to > get to the local SQL form, and ADQL/XML gives us the > one->many rather than > many->many combinations we need. > > We *do* need to ensure scope for adding new functions, but > this has to be treated carefully; ADQL is meant to be a > *standard* query language that we can apply across a range of > datacenters. If a particular datacenter implements a > particular new function, but other datacenters do not, we > lose the 'generality' > of it. > > So I suggest that the datacenter-specific functions do not > need to be built into the ADQL language itself, but either > inserted as an unchecked element, eg: > > > HtmIdenitfier > > > or by creating a datacenter-specific ADQL schema that extends > the standard one. > > Cheers, > > Martin > > Clive Page wrote: > > > On Thu, 5 Feb 2004, Tony Linde wrote: > > > > > >>Anyone who wants to provide a text input service will have > to write a > >>parser that translates from the text form into the standard > xml form. > > > > > > I think it will be essential to have converters in both directions > > between ADQL/text (alias SkyQL) and ADQL/XML. We have > already found > > that it is exceedingly difficult to test software which > requires fully > > > formed XML as its input, so the testers need to be able to input > > ADQL/text. I think power users who are already familiar > with SQL will > > > want to be able to continue using it (or something very similar) - > > they will not take kindly to instructions to learn > ADQL/XML. Thirdly, > > > the ADQL/text form has very limited extensibility: if some > backend can > > > provide additional facilities such as stored procedures/user-defined > > functions, then these would be unusable from ADQL/XML until the > > parsers have been modified and tested, but a pass-through > of ADQL/text > > > would be able to use these extensions immediately, and they > might (if > > suitable) be incorporated into the standard at some future date. A > > living language needs a simple route for growth. > > > > > > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > > From owner-voql@eso.org Fri Feb 6 16:33: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 i16FWq7l025259 for ; Fri, 6 Feb 2004 16:32:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16FWqNp025256 for voql-outgoing; Fri, 6 Feb 2004 16:32:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16FWm7l025240 for ; Fri, 6 Feb 2004 16:32:48 +0100 (MET) Received: from athena.le.ac.uk (mailsend.le.ac.uk [143.210.16.127]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16FWkEY000237 for ; Fri, 6 Feb 2004 16:32:47 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap7yI-0000TQ-41 for voql@ivoa.net; Fri, 06 Feb 2004 15:32:46 +0000 Received: (qmail 17760 invoked from network); 6 Feb 2004 15:33:02 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 15:33:02 -0000 From: "Tony Linde" To: "'Wil O'Mullane'" , Subject: RE: The case for XML ADQL Date: Fri, 6 Feb 2004 15:33:57 -0000 Organization: University of Leicester Message-ID: <003301c3ecc6$a31862f0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040206100852.J21454@skysrv.pha.jhu.edu> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > There is a WSDL and a document for a Data Center. (SkyNode) > The latter should deal with how a data center deals with ADQL > and functions it supports not the former. I agree ... -ish. We need to define in the skynode spec how a data centre can list the functions it supports. In the adql spec we need to define how functions are namespaced generally so that they can be included in a adql document. Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Wil O'Mullane > Sent: 06 February 2004 15:09 > To: voql@ivoa.net > Subject: Re: The case for XML ADQL > > > yes precisly we split them you are merging them in a single schema. > > > There is a schema and a document for a language (ADQL) > There is a WSDL and a document for a Data Center. (SkyNode) > The latter should deal with how a data center deals with ADQL > and functions it supports not the former. > > > > > > I thought we were splitting the Query Language > specification out from > > the > > general SkyNode Spec? And anyway how does the spec deal > with it without the > > schema dealing with it? I tend to work on the basis that > the schema is our way > > of agreeing the implementations - ie making sure that our > web services publish > > their interface exactly, rather than relying on separate > human-only documents. > > > > Yes I quite agree that functions should be published in the > center's > > metadata. > > > > > > -- > > Martin Hill > > Software Engineer > > AstroGrid @ ROE > > Tel: +44 7901 55 24 66 > > www.astrogrid.org > From owner-voql@eso.org Fri Feb 6 16:40: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 i16Fdh7l026897 for ; Fri, 6 Feb 2004 16:39:43 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16FdhJ3026892 for voql-outgoing; Fri, 6 Feb 2004 16:39:43 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Fdd7l026870 for ; Fri, 6 Feb 2004 16:39:39 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16FdbWR016335 for ; Fri, 6 Feb 2004 16:39:37 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap84u-0000rG-Nj for voql@ivoa.net; Fri, 06 Feb 2004 15:39:36 +0000 Received: (qmail 19262 invoked from network); 6 Feb 2004 15:39:56 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 15:39:56 -0000 From: "Tony Linde" To: Subject: Let's get happy (not sad) Date: Fri, 6 Feb 2004 15:40:51 -0000 Organization: University of Leicester Message-ID: <003401c3ecc7$99a8a800$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 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 i16Fdg7l026884 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'd like to propose that we drop work on SADQL, focus on ADQL and look at ways of: A) removing some of the complexities by simplifying the BNF (or the way it is translated to a schema); B) introducing the additional SQL functionality that we will require: INTO, UPDATE, (CREATE, DROP, ALTER - these *might* be provided by separate skynode functions as opposed to aspects of adql). 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-voql@eso.org Fri Feb 6 16:50: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 i16Fob7l029772 for ; Fri, 6 Feb 2004 16:50:37 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16FobNK029771 for voql-outgoing; Fri, 6 Feb 2004 16:50:37 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16FoZ7l029751 for ; Fri, 6 Feb 2004 16:50: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 SMTP id i16FoXWR016817 for ; Fri, 6 Feb 2004 16:50:33 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 6AA551C00222; Fri, 6 Feb 2004 15:50:32 +0000 (GMT) Message-ID: <4023B7CE.4050208@dial.pipex.com> Date: Fri, 06 Feb 2004 15:50:38 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page Cc: voql@ivoa.net Subject: Re: Other SQL constructs 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive Page wrote: > On Fri, 6 Feb 2004, Martin Hill wrote: > >>ADQL (and SADQL) are currently query languages only. > > Well so is SQL called a query language, but it has handy things like > UPDATE, DELETE, DROP, and more creatively, CREATE. I think ADQL will need > the same. The SQL example isn't necessarily a good one to follow, but I > think we are mostly agreed that it's better to follow it than to invent > something that might be worse. Agreed - might as well stick with something we know works. (I just meant that we don't have this capability yet in S/ADQL) >>(esp as we at AstroGrid may have several ways to delete a table) > > Really: you mean like - all at once versus a byte at a time? Or do you > mean like really delete it versus moving it to the grid-wastebasket (an > ikon of a black-hole might be appropriate for that, unless someone has > already copyrighted that idea). :-) No I meant that if we end up with GridFTP and MySpace storage-access mechanisms to tables, as well as ADQL access, it might give the user several routes to managing things such as delete, move and rename. In retrospect that probably doesn't matter... I'm a bit wary about adding manipulation directly to ADQL, as it seems that most datacenters will accept queries only, so it's handy to have a query-only schema to validate against. But we could have an ADML (Astronomy Database Manipulation Language...) that extends ADQL to include the new commands? Cheers, Martin -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 16:56: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 i16Fu57l000815 for ; Fri, 6 Feb 2004 16:56:05 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16Fu5eU000812 for voql-outgoing; Fri, 6 Feb 2004 16:56:05 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Fu17l000791 for ; Fri, 6 Feb 2004 16:56:01 +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 SMTP id i16Fu0WR017072 for ; Fri, 6 Feb 2004 16:56:00 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 32CB21C00160; Fri, 6 Feb 2004 15:55:59 +0000 (GMT) Message-ID: <4023B916.7070503@dial.pipex.com> Date: Fri, 06 Feb 2004 15:56:06 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Linde Cc: voql@ivoa.net Subject: Re: Let's get happy (not sad) References: <003401c3ecc7$99a8a800$6124d28f@STAR.LE.AC.UK> In-Reply-To: <003401c3ecc7$99a8a800$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony Linde wrote: > I'd like to propose that we drop work on SADQL, focus on ADQL and look at > ways of: What work on SADQL? I've heard nothing from anyone about the language itself. > A) removing some of the complexities by simplifying the BNF (or the way it > is translated to a schema); Aha! The original purpose! Yes please please someone produce a simple ADQL. If you don't like me doing it (possibly I'm too bald :-) then I'm quite happy to accept any other simple alternative (especially if it's from someone capable of working their way through the existing schema!). We've got astronomers trying to write queries here. -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 17:03:28 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 i16G3E7l002216 for ; Fri, 6 Feb 2004 17:03:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16G3Efr002215 for voql-outgoing; Fri, 6 Feb 2004 17:03:14 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16G3B7l002204 for ; Fri, 6 Feb 2004 17:03:11 +0100 (MET) Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16G3AWR017428 for ; Fri, 6 Feb 2004 17:03:10 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by athena.le.ac.uk with smtp (Exim 4.30) id 1Ap8Rh-00027D-Da for voql@ivoa.net; Fri, 06 Feb 2004 16:03:09 +0000 Received: (qmail 25273 invoked from network); 6 Feb 2004 16:03:29 -0000 Received: from peneca.star.le.ac.uk (143.210.36.224) by mail.star.le.ac.uk with SMTP; 6 Feb 2004 16:03:29 -0000 Date: Fri, 6 Feb 2004 16:03:08 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: Other SQL constructs In-Reply-To: <4023B7CE.4050208@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Fri, 6 Feb 2004, Martin Hill wrote: > I'm a bit wary about adding manipulation directly to ADQL, as it seems that most > datacenters will accept queries only, so it's handy to have a query-only schema > to validate against. But we could have an ADML (Astronomy Database Manipulation > Language...) that extends ADQL to include the new commands? Well it's true now (as far as I know) that all data centres are essentially read-only (except for the special case of access by trusted insiders). We don't know if this is going to be true for the future; if it is then we might as well abandon our efforts on things like MySpace, as the only place to write or update data is going to be the user's own machine, which makes the whole thing trivial or indeed solved already. If we do expect users to be able to write at a distance, then we need to consider "queries", well operations, which update tables and do all the other things that SQL can do, don't we? -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Fri Feb 6 17:08:05 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 i16G7p7l003155 for ; Fri, 6 Feb 2004 17:07:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16G7pwT003154 for voql-outgoing; Fri, 6 Feb 2004 17:07:51 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16G7m7l003136 for ; Fri, 6 Feb 2004 17:07:48 +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 SMTP id i16FRuWR015805 for ; Fri, 6 Feb 2004 16:27:56 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 16E891C00244; Fri, 6 Feb 2004 15:27:55 +0000 (GMT) Message-ID: <4023B282.2070206@dial.pipex.com> Date: Fri, 06 Feb 2004 15:28:02 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: The case for XML ADQL References: <40239ADC.2080409@dial.pipex.com> <20040206094625.D21454@skysrv.pha.jhu.edu> <4023ACB9.8080002@dial.pipex.com> <20040206100852.J21454@skysrv.pha.jhu.edu> In-Reply-To: <20040206100852.J21454@skysrv.pha.jhu.edu> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Wil, I don't see how these are being merged in a way that wouldn't be required also by the existing ADQL... > There is a schema and a document for a language (ADQL) Yes - what in SADQL is being defined that is not defined in ADQL? Apart from INTO... > There is a WSDL and a document for a Data Center. (SkyNode) > The latter should deal with how a data center deals with ADQL and functions it supports not the former. Yes - and there is also the metadata provided by the Data Center that describes functions and table/column names available. And ADQL (in whatever form) is going to have to be able to accept requests to use these functions, with the correct parameters. Cheers, Martin Wil O'Mullane wrote: > yes precisly we split them you are merging them in a single schema. > > > There is a schema and a document for a language (ADQL) > There is a WSDL and a document for a Data Center. (SkyNode) > The latter should deal with how a data center deals with ADQL and functions it supports not the former. > > > >>I thought we were splitting the Query Language specification out from the >>general SkyNode Spec? And anyway how does the spec deal with it without the >>schema dealing with it? I tend to work on the basis that the schema is our way >>of agreeing the implementations - ie making sure that our web services publish >>their interface exactly, rather than relying on separate human-only documents. >> >>Yes I quite agree that functions should be published in the center's metadata. >> >> >>-- >>Martin Hill >>Software Engineer >>AstroGrid @ ROE >>Tel: +44 7901 55 24 66 >>www.astrogrid.org -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 17:08:08 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 i16G7t7l003172 for ; Fri, 6 Feb 2004 17:07:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16G7tgF003171 for voql-outgoing; Fri, 6 Feb 2004 17:07:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16G7m7p003136 for ; Fri, 6 Feb 2004 17:07:53 +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 SMTP id i16FKKWR015471 for ; Fri, 6 Feb 2004 16:20:20 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 024F71C001FB; Fri, 6 Feb 2004 15:20:19 +0000 (GMT) Message-ID: <4023B0B9.5030303@dial.pipex.com> Date: Fri, 06 Feb 2004 15:20:25 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: The case for building ADQL from a SQL core. References: <25603A6EFF8BA34AB2A49615383CD4490226BBC6@RED-MSG-31.redmond.corp.microsoft.com> In-Reply-To: <25603A6EFF8BA34AB2A49615383CD4490226BBC6@RED-MSG-31.redmond.corp.microsoft.com> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Jim You've mentioned before that you think SADQL is a brand new language. I don't see why you think this - it's got the same structure as SQL and ADQL v0.5, but it's just tokenised differently. In a more readable form. I very intentionally 'hijacked' the SQL semantics for exactly the same reasons as we agreed on using an SQL-like query in the first place - it exists, it's reasonably well understood and it generally works. The only reason I didn't go the other way (ie take ADQL 0.5 and cut it down) was because it was too hard to work with that particular (generated) schema. There's nothing particularly difficult about building a recursive expression mechanism, which is the only bit I've had to do some actual thinking about. The rest is cribbed from SQL and ADQL 0.5. If you (or anyone else!) can point out *anything* that you think is *actually wrong* with SADQL vs ADQL 0.5 I would be very interested. It's why I posted it as a proposed alternative! But I've heard nothing yet... Cheers, Martin Jim Gray wrote: > > I agree: "there's no real difference between extending ADQL/string and > ADQL/xml." > In both cases, you start from zero and have to write a man-page for > every feature (since you start with the empty set and build ADQL) > > The point is that there is a huge difference between > subsetting SQL and > creating a new core language from scratch. > In the subsetting approach you hijack the years of language design and > skills of the SQL folks. > In the creating a new core lanugage you go it alone and have to do that > design and write those man pages yourself. > That is a BIG difference. > > The current efforts been defining language syntax (in xml) and leaving > the semantics to the reader. > The semantics are the hard part. > Hijacking someone else's semantics is a lot easier. > > So, there is a BIG difference between the two approaches. > > The SQL first approch can just hijack the semantics for this rather > complex expression > > SELECT
> FROM > WHERE > GROUP BY > HAVING > ORDER BY > > One has to modify the naming and explain about MyDB and define the > non-standard functions, but that is easy compared to explaining the > semantics of this beast. > > > > Jim Gray > Microsoft Research, Suite 1690, 455 Market, SF CA 94105, > tel: 415 778 8222 fax: 425 706 7329 > Gray@Microsoft.com http://research.Microsoft.com/~gray > > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On Behalf Of Martin > Hill > Sent: Friday, February 06, 2004 5:47 AM > To: Clive Page > Cc: voql@ivoa.net > Subject: Re: The case for XML ADQL > > In fact there's no real difference between extending ADQL/string and > ADQL/xml. > We can't in practice allow ADQL/string to pass through 'blind' in > general for security reasons, so ADQL/string parsers will need to be > updated to provide for new functions. Anyway there will usually need to > be a translation layer to get to the local SQL form, and ADQL/XML gives > us the one->many rather than > many->many combinations we need. > > We *do* need to ensure scope for adding new functions, but this has to > be treated carefully; ADQL is meant to be a *standard* query language > that we can apply across a range of datacenters. If a particular > datacenter implements a particular new function, but other datacenters > do not, we lose the 'generality' > of it. > > So I suggest that the datacenter-specific functions do not need to be > built into the ADQL language itself, but either inserted as an unchecked > element, eg: > > > HtmIdenitfier > > > or by creating a datacenter-specific ADQL schema that extends the > standard one. > > Cheers, > > Martin > > Clive Page wrote: > > >>On Thu, 5 Feb 2004, Tony Linde wrote: >> >> >> >>>Anyone who wants to provide a text input service will have to write a >>>parser that translates from the text form into the standard xml form. >> >> >>I think it will be essential to have converters in both directions >>between ADQL/text (alias SkyQL) and ADQL/XML. We have already found >>that it is exceedingly difficult to test software which requires fully > > >>formed XML as its input, so the testers need to be able to input >>ADQL/text. I think power users who are already familiar with SQL will > > >>want to be able to continue using it (or something very similar) - >>they will not take kindly to instructions to learn ADQL/XML. Thirdly, > > >>the ADQL/text form has very limited extensibility: if some backend can > > >>provide additional facilities such as stored procedures/user-defined >>functions, then these would be unusable from ADQL/XML until the >>parsers have been modified and tested, but a pass-through of ADQL/text > > >>would be able to use these extensions immediately, and they might (if >>suitable) be incorporated into the standard at some future date. A >>living language needs a simple route for growth. >> >> >> > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 17:18: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 i16GIK7l005573 for ; Fri, 6 Feb 2004 17:18:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16GIKAA005572 for voql-outgoing; Fri, 6 Feb 2004 17:18:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16GII7l005563 for ; Fri, 6 Feb 2004 17:18:18 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16GIGEY002394 for ; Fri, 6 Feb 2004 17:18:16 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 0879D1C002E8; Fri, 6 Feb 2004 16:18:14 +0000 (GMT) Message-ID: <4023BE4D.6010302@dial.pipex.com> Date: Fri, 06 Feb 2004 16:18:21 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page Cc: voql@ivoa.net Subject: Re: Other SQL constructs 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yes we need it, but my thinking is that a schema defining a manipulation language (that includes the query language) makes implementing the interface to a read-only vs a manipulatable datacenter trivial. The former defines ADQL as its input document and the latter ADML. Otherwise we will need to specify stuff in the metadata (ie, whether it's OK to use the manipulation commands) and checks in the query parser as to which commands to accept. Which is not difficult stuff, but why do it when the schema mechanism (and associated WSDL interface definitions) is already there? On the other hand, if it seems likely that most datacenters will provide write access too, then maybe it's not so important. But I got the impression that most data owners will initially publish for querying only, whereas institutions might supply warehouses...? Cheers Martin Clive Page wrote: > On Fri, 6 Feb 2004, Martin Hill wrote: > > >>I'm a bit wary about adding manipulation directly to ADQL, as it seems that most >>datacenters will accept queries only, so it's handy to have a query-only schema >>to validate against. But we could have an ADML (Astronomy Database Manipulation >>Language...) that extends ADQL to include the new commands? > > > Well it's true now (as far as I know) that all data centres are > essentially read-only (except for the special case of access by trusted > insiders). > > We don't know if this is going to be true for the future; if it is then we > might as well abandon our efforts on things like MySpace, as the only > place to write or update data is going to be the user's own machine, which > makes the whole thing trivial or indeed solved already. If we do expect > users to be able to write at a distance, then we need to consider > "queries", well operations, which update tables and do all the other > things that SQL can do, don't we? > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Fri Feb 6 20:38:13 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 i16Jbo7l019207 for ; Fri, 6 Feb 2004 20:37:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i16JboCp019205 for voql-outgoing; Fri, 6 Feb 2004 20:37:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i16Jbk7l019195 for ; Fri, 6 Feb 2004 20:37:47 +0100 (MET) Received: from mail630.gsfc.nasa.gov (mail630.gsfc.nasa.gov [128.183.190.39]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i16JbiEY010548 for ; Fri, 6 Feb 2004 20:37:45 +0100 (CET) Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136]) by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id i16JbfAM021959 for ; Fri, 6 Feb 2004 14:37:42 -0500 Message-ID: <4023ED21.2080106@gsfc.nasa.gov> Date: Fri, 06 Feb 2004 14:38:09 -0500 From: Ed Shaya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: voql@ivoa.net Subject: Re: XML-SQL forindustry References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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-voql@eso.org Precedence: bulk Reply-To: Ed Shaya X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On a new issue. Wouldn't it make sense to break up the ADQL into two parts, one with standard SQL and one with astronomy or VO specific parts (like XMATCH and region). One would have an XML-SQL.xsd and a ADQL.xsd where the ADQL.xsd simply includes XML-SQL and then extends a few terms in XML-SQL and adds some new terms. It costs us nothing except about 20 minutes of work. Why bother? Because, then one would have a schema that might be of interest to other groups trying to do distributed database systems and this might help them. Perhaps they would join us in writing software for handling it and we could adopt some of that. If it is not separate, others will think this is just for astronomy and ignore it. Perhaps we should submit XML-SQL to the W3C? After we settle on some compromise between ADQL and SADQL of course. Ed From owner-voql@eso.org Sat Feb 7 10:15: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 i179Ed1T025341 for ; Sat, 7 Feb 2004 10:14:39 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i179Edgf025340 for voql-outgoing; Sat, 7 Feb 2004 10:14:39 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i179Ea1T025330 for ; Sat, 7 Feb 2004 10:14:37 +0100 (MET) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i179EYWR018625 for ; Sat, 7 Feb 2004 10:14:35 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040207091404.MIS7142.mta02-svc.ntlworld.com@gnowee> for ; Sat, 7 Feb 2004 09:14:04 +0000 From: "Tony Linde" To: Subject: Adql.xsd Date: Sat, 7 Feb 2004 09:15:45 -0000 Organization: University of Leicester Message-ID: <007201c3ed5a$f7d002f0$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 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 i179Ec1T025336 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I find it very difficult to look at the adql.xsd using xml-spy. Can someone post a link to the region.xsd and coords.xsd which work with this version of adql.xsd. I cannot find one which contains the correct types, eg astronTimeTypeRelativeTimeUnit. The adql.xsd is unusable at the moment because of errors generated from such mismatches. When Ray and I created the resource.xsd (and associated schemas) it was possible to see the whole of a structure in one diagram by expanding element types. That isn't possible with this schema. If I expand the WHERE construct I end up with 'condition' and it goes nowhere. In adql1.xml example, a condition contains FirstCondition/SecondCondition if it is of type IntersectionSearch; how can I see this from the diagram, or even track it down manually. Why does the Search structure (all the inheritees of Search) not show up? Does anyone have access to an xml expert who could cast their eye over the automatically generated schema to see if it is using 'good practice' in xml terms? Finally, why is REGION implemented as a type of Search? Would it not be better as a type of function? We are going to want to add more such features to the schema in the future, most of which I would have thought were simply additional functions. 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-voql@eso.org Sat Feb 7 18:27: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 i17HRK1T006491 for ; Sat, 7 Feb 2004 18:27:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i17HRKl4006490 for voql-outgoing; Sat, 7 Feb 2004 18:27:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i17HRG1T006475 for ; Sat, 7 Feb 2004 18:27:16 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i17HREEY014944 for ; Sat, 7 Feb 2004 18:27:15 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 6EA121C00190; Sat, 7 Feb 2004 17:27:13 +0000 (GMT) Message-ID: <40251FF8.4030005@dial.pipex.com> Date: Sat, 07 Feb 2004 17:27:20 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Linde Cc: voql@ivoa.net Subject: Re: Adql.xsd References: <007201c3ed5a$f7d002f0$6124d28f@STAR.LE.AC.UK> In-Reply-To: <007201c3ed5a$f7d002f0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony Linde wrote: > Can someone post a link to the region.xsd and coords.xsd which work with > this version of adql.xsd. I cannot find one which contains the correct > types, eg astronTimeTypeRelativeTimeUnit. The adql.xsd is unusable at the > moment because of errors generated from such mismatches. As a 'temporary fix' for examining the schema, delete the imports. > When Ray and I created the resource.xsd (and associated schemas) it was > possible to see the whole of a structure in one diagram by expanding element > types. That isn't possible with this schema. If I expand the WHERE construct > I end up with 'condition' and it goes nowhere. In adql1.xml example, a > condition contains FirstCondition/SecondCondition if it is of type > IntersectionSearch; how can I see this from the diagram, or even track it > down manually. Why does the Search structure (all the inheritees of Search) > not show up? If you're looking in the 'Grid' tab this is indeed the case, as that is (or seems to be) a tree view of the schema itself. As the Search _type_ has no subelements you won't see any there. Switch to the Schema/WSDL view (once you've removed/fixed the region/coords imports) and start from the WhereClause or TableExpression. This gives you a possible-instance tree but I think that's what you want anyway. > Finally, why is REGION implemented as a type of Search? Would it not be > better as a type of function? We are going to want to add more such features > to the schema in the future, most of which I would have thought were simply > additional functions. The Search types return boolean values - they are matches - whereas the functions return values and so would appear in comparison-like expressions. So they're not actually interchangable. There is a small inconsistency between XMatch and Region. Because the Region is a single 'search function' with all its parameters included inside the brackets, it's straightforward for the backend to optimise the SQL. However the XMatch one is a function, of the form: XMatch(table1, table2) < sigma which means that either the backend implements the function to return a number for the standard SQL to handle, which might not be the most optimal, or a bit more parsing is required by the backend to find the sigma. Cheers, Martin -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Sun Feb 8 15:47:51 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 i18El0nX017052 for ; Sun, 8 Feb 2004 15:47:00 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18El0AY017051 for voql-outgoing; Sun, 8 Feb 2004 15:47:00 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18EkwnX017039 for ; Sun, 8 Feb 2004 15:46:58 +0100 (MET) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i18EkpEY013804 for ; Sun, 8 Feb 2004 15:46:51 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040208144648.ONWG1936.mta06-svc.ntlworld.com@gnowee>; Sun, 8 Feb 2004 14:46:48 +0000 From: "Tony Linde" To: "'Martin Hill'" Cc: Subject: RE: Adql.xsd Date: Sun, 8 Feb 2004 14:48:04 -0000 Organization: University of Leicester Message-ID: <009801c3ee52$8f3f86e0$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0099_01C3EE52.8F3F86E0" 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: <40251FF8.4030005@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C3EE52.8F3F86E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > As a 'temporary fix' for examining the schema, delete the imports. That just produces an error on the types defined within the namespaces of those schema. > imports) and start from the WhereClause or TableExpression. > This gives you a > possible-instance tree but I think that's what you want anyway. All I get is as attached (.jpg). Cheers, Tony. > -----Original Message----- > From: Martin Hill [mailto:mchill@dial.pipex.com] > Sent: 07 February 2004 17:27 > To: Tony Linde > Cc: voql@ivoa.net > Subject: Re: Adql.xsd > > > Tony Linde wrote: > > > Can someone post a link to the region.xsd and coords.xsd which work > > with this version of adql.xsd. I cannot find one which contains the > > correct types, eg astronTimeTypeRelativeTimeUnit. The adql.xsd is > > unusable at the moment because of errors generated from such > > mismatches. > > As a 'temporary fix' for examining the schema, delete the imports. > > > When Ray and I created the resource.xsd (and associated schemas) it > > was possible to see the whole of a structure in one diagram by > > expanding element types. That isn't possible with this schema. If I > > expand the WHERE construct I end up with 'condition' and it goes > > nowhere. In adql1.xml example, a condition contains > > FirstCondition/SecondCondition if it is of type IntersectionSearch; > > how can I see this from the diagram, or even track it down > manually. > > Why does the Search structure (all the inheritees of > Search) not show > > up? > > If you're looking in the 'Grid' tab this is indeed the case, > as that is (or > seems to be) a tree view of the schema itself. As the Search > _type_ has no > subelements you won't see any there. > > Switch to the Schema/WSDL view (once you've removed/fixed the > region/coords > imports) and start from the WhereClause or TableExpression. > This gives you a > possible-instance tree but I think that's what you want anyway. > > > Finally, why is REGION implemented as a type of Search? > Would it not > > be better as a type of function? We are going to want to > add more such > > features to the schema in the future, most of which I would have > > thought were simply additional functions. > > The Search types return boolean values - they are matches - > whereas the > functions return values and so would appear in > comparison-like expressions. So > they're not actually interchangable. > > There is a small inconsistency between XMatch and Region. > Because the Region is > a single 'search function' with all its parameters included > inside the brackets, > it's straightforward for the backend to optimise the SQL. > However the XMatch > one is a function, of the form: > > XMatch(table1, table2) < sigma > > which means that either the backend implements the function > to return a number > for the standard SQL to handle, which might not be the most > optimal, or a bit > more parsing is required by the backend to find the sigma. > > Cheers, > > Martin > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > ------=_NextPart_000_0099_01C3EE52.8F3F86E0 Content-Type: image/jpeg; name="TableExp.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TableExp.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCADjAkUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7Looo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOft9f 1aXw7c6o/gjxBBdwyhE0uSaxNzOPl+dGW5MIX5j96RT8jcfdzPc6zqMX9keX4T1q4+37ftPly2g/ s3O3Pn7pxuxuOfJ837jYz8u48CQfZvA+g239u/8ACQeVptun9rb9/wBvxEo+0btzZ3/fzubO7qet Y+s+OpLPxdd+GNL8HeIdfvLO0gu7l7B7NI40maRUGbi4iJJMT9AccetAG9b6ney+IrnS38PanBaQ xB01SSS3NtOfl+RFWUzBvmP3o1HyNz93NK31/VpfDtzqj+CPEEF3DKETS5JrE3M4+X50ZbkwhfmP 3pFPyNx93Oro13cX+mw3d1pd5pc0gJa0u2iaWPnGGMTunvwx61boBamNc6zqMX9keX4T1q4+37ft Ply2g/s3O3Pn7pxuxuOfJ837jYz8u6a31O9l8RXOlv4e1OC0hiDpqkklubac/L8iKspmDfMfvRqP kbn7udOigDn7fX9Wl8O3OqP4I8QQXcMoRNLkmsTczj5fnRluTCF+Y/ekU/I3H3cz3Os6jF/ZHl+E 9auPt+37T5ctoP7Nztz5+6cbsbjnyfN+42M/Luo+JPGdrpWtx6Bp+kap4h1poRcSWGmCHfBCSQJJ HmkjjQEggAvubB2ghWIzY/iIr6jounyeG9W0681DVjptxbaiqxSWx+zyzLICheOZSIsAxuR8xyQV K0LXb+un5g9P68r/AJanTW+p3sviK50t/D2pwWkMQdNUkktzbTn5fkRVlMwb5j96NR8jc/dzSt9f 1aXw7c6o/gjxBBdwyhE0uSaxNzOPl+dGW5MIX5j96RT8jcfdz0FFAGNc6zqMX9keX4T1q4+37ftP ly2g/s3O3Pn7pxuxuOfJ837jYz8u6a31O9l8RXOlv4e1OC0hiDpqkklubac/L8iKspmDfMfvRqPk bn7udOigDn7fX9Wl8O3OqP4I8QQXcMoRNLkmsTczj5fnRluTCF+Y/ekU/I3H3cw+IvFr6FZ6Jd33 hrWjDqdzbWs7RtbH+zpbiaKGNZx52T+8mCkw+aBtY9ME9NXlnir4j6/caFeyeFPAutTiPV/7KXUL q70+C3kaO++yzCPfdpJvJWRYsqNzmPjBoA9Torhvhf4i1K/vtV8P67omtaTqthFb3jJqM1vLvgnM qRlWhmkH3reXIJBHHrXc0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFAHJ+EINc1DTtcutQ1nxBaS3l9e21pDcxWu6wSK4mijlgxbruV0CSL5wlGN nLDJa5caBq0vh220tPG/iCC7hlLvqkcNibmcfN8jq1sYQvzD7san5F5+9m74ah1mDTpU167hurs3 128bxDCi3a4ka3Q/KvzLCYlPHVTy33jp0Ac/8NZtGufh14auPDlpNZ6LLpFq+nW8xzJDbmFTEjEs 2WCbQfmbkdT1rh5PDWneIvj34q+33Osw+RoOlbP7P1m7sc7pb3O77PKm/oMbs45xjJrsvBXieHUb ex0TW9R0WHxrFpsFzrOjWt5G8tnK0cZk/dh2YIGcAEkjDLycgma38b+C7nw7c+I7fxf4fm0W1lEN xqMepQtbQudoCPKG2q3zpwTn5l9RTQdGv63ucX4w8M6Hqfxc8F6Hq1guqadBoGpD7PqDtcrLtksw vm+YW80jrmTd8wDfeANcT4rXwmln41TX109fiat7cjw4HAGpBf8AmH/Yc/P5f3M+V8u7zd3O+vcb nxZ4Vtv7I+0+JdFh/tvb/ZPmX0S/b923b5GW/e53pjbnO9fUVNb+IdAufEVz4ct9c0ybWrWITXGn R3aNcwodpDvEDuVfnTkjHzL6il217/i739ehTl5dvwVrendHmV14b0jxL8fp7bxbpFjq4j8G2bSW 13EJoDJ9qnyxjbKMQc4JBIycYya4yx8NaHY/B2LxPaadFHrmneK/stjqJ+e5tbePWvs6W8UjZaOE RZTy1IXBbj5jn3O38b+C7nw7c+I7fxf4fm0W1lENxqMepQtbQudoCPKG2q3zpwTn5l9RU9z4s8K2 39kfafEuiw/23t/snzL6Jft+7bt8jLfvc70xtznevqKadrW6O/8A5Nzf8Al6vXy/CPL+O5wcGr6Z 4E+Lni698XXdvpGm+IFs7jT9VvHEVqxih8p7ZpWwqyAqXCEjcHJXOGpnifxXoninxL4Eu/Dt3/aV nb+J3iF5CpNvOwsLrIik+7KB0LKSoORnIIHotv4h0C58RXPhy31zTJtatYhNcadHdo1zCh2kO8QO 5V+dOSMfMvqKpW/jfwXc+HbnxHb+L/D82i2sohuNRj1KFraFztAR5Q21W+dOCc/MvqKUdEvId9/N NferHgHgm70ib4i+B9Z0QeCtJv8AUNVuI9T0rRbF/wC0rQPbXDtBf3XmZdt6AlJIkO9MrnYTWlre v6NZeBfEvhO51K2j1/8A4ToTHTS+bkRSavFKkpjHzCMo6kORt+YDOTivdLnxZ4Vtv7I+0+JdFh/t vb/ZPmX0S/b923b5GW/e53pjbnO9fUVNb+IdAufEVz4ct9c0ybWrWITXGnR3aNcwodpDvEDuVfnT kjHzL6ihaNW6f5xf6fiNyvt3T+7m/wA/wPAvjT/wjtj471rVLub4f+L7whEl8NeIAYtXjAtx5cWm y/O3zuysqpFy7Ph93R/j22tL/wCI2v8A/Cea34J0S0kit/7DHjHRzcIkBgTzPskzXUSJIJS+8IPM yEJONmPbbfxv4LufDtz4jt/F/h+bRbWUQ3Gox6lC1tC52gI8obarfOnBOfmX1FT3Pizwrbf2R9p8 S6LD/be3+yfMvol+37tu3yMt+9zvTG3Od6+opJe6l/X9ffpoDld3Ivh2CPAehA61JruLCEDUpImj a8GwYlKsSRu68knnqa8E1nVdAufC1xpf/C3bLw/f2nje5kuNHbU9Lh8tY/Ekk7XDC5jMgdYv3iru 2t5afI2SG+hrfxDoFz4iufDlvrmmTa1axCa406O7RrmFDtId4gdyr86ckY+ZfUVyfjjxP4H174c3 OpRajZeJNJXUrK2EmlXiTql4bqDyMsjgDZK8LsM/dHRgcG5S5m2RFWVjL+FOq6RqvxO8Svo/jKHx hFB4f0iGXU47i2mZn+1am2xzbKsYYKyjAUHG0nJOT6nXM/Dn/kCTf9fLf+grXTVIwooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA5/wDDo0GhXKaDd zXVodX1J5HlGGFw19O1wg+VflWYyqOOijlvvHoKxvBs/2jSJ5P7C/sTGpX6fZtm3zNt3Mv2jG1f9 djzs4583OWzuOzQBjeJtC/tr7P8A6V5Hk7v+We7Oce49Kxv+EG/6in/kv/8AZV2VFAHG/wDCDf8A UU/8l/8A7Kj/AIQb/qKf+S//ANlXZUUAcb/wg3/UU/8AJf8A+yo/4Qb/AKin/kv/APZV2VFAHG/8 IN/1FP8AyX/+yo/4Qb/qKf8Akv8A/ZV2VFAHG/8ACDf9RT/yX/8AsqP+EG/6in/kv/8AZV2VFAHG /wDCDf8AUU/8l/8A7Kj/AIQb/qKf+S//ANlXZUUAcb/wg3/UU/8AJf8A+yo/4Qb/AKin/kv/APZV 2VFAGZ4c0r+x7F7b7R5+6Uybtm3GQBjGT6Vp0UUAFFc/BqXimSCOR9A0qFmUExvqzlkJHQ4gIyPY ke9P+3+J/wDoC6P/AODWT/5Hrm+uUP5kPlZu0VU+0XX2Lf8AZ4ftXl58vzj5e/H3d+3O3PGducc4 7Vm/b/E//QF0f/wayf8AyPUrHYd/aHys3aKwvt/if/oC6P8A+DWT/wCR60vtF19i3/Z4ftXl58vz j5e/H3d+3O3PGducc47UPHYdfaDlZborC+3+J/8AoC6P/wCDWT/5Ho+3+J/+gLo//g1k/wDken9d ofzIOVm7RVT7RdfYt/2eH7V5efL84+Xvx93ftztzxnbnHOO1Zv2/xP8A9AXR/wDwayf/ACPSWOw7 +0HKzdorC+3+J/8AoC6P/wCDWT/5HrS+0XX2Lf8AZ4ftXl58vzj5e/H3d+3O3PGducc47UPHYdfa DlZborC+3+J/+gLo/wD4NZP/AJHo+3+J/wDoC6P/AODWT/5Hp/XaH8yDlZu0VU+0XX2Lf9nh+1eX ny/OPl78fd37c7c8Z25xzjtWb9v8T/8AQF0f/wAGsn/yPSWOw7+0HKzdorC+3+J/+gLo/wD4NZP/ AJHrS+0XX2Lf9nh+1eXny/OPl78fd37c7c8Z25xzjtQ8dh19oOVluisL7f4n/wCgLo//AINZP/ke j7f4n/6Auj/+DWT/AOR6f12h/Mg5WbtFVPtF19i3/Z4ftXl58vzj5e/H3d+3O3PGducc47Vm/b/E /wD0BdH/APBrJ/8AI9JY7Dv7QcrN2isL7f4n/wCgLo//AINZP/ketL7RdfYt/wBnh+1eXny/OPl7 8fd37c7c8Z25xzjtQ8dh19oOVluisL7f4n/6Auj/APg1k/8Akej7f4n/AOgLo/8A4NZP/ken9dof zIOVm7RVPQr7+1NDsNT8ryftdtHP5e7ds3qGxnAzjPXFXK6iQooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMzw1DrMGnSpr13DdXZvrt43iGFFu1 xI1uh+VfmWExKeOqnlvvHTrn/AMOjQaFcpoN3NdWh1fUnkeUYYXDX07XCD5V+VZjKo46KOW+8ego AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDI0O+/tPRbHUvK8r7XbRz+Xu3bd6hsZ4z jPWrlY/gf/kS9D/7B1v/AOi1rI1jU7rStU1+LzpHMthHc2Ss5IWTmIquTwN3lnju1fI+z5puMToX mdfRXC2V3qH2LSfD8t/cSX0erNb3ExkIkkiizLknOTuXywfXdTtG1e80q21CdtOSTTxrU0Uk32jE gLz7cqgUggFh1ZT146Zv6u+j9PPt95N9L/11/wAjuKK5bW/GFvY6pdafC+l+baKpm+26itsWJXcF jBVixxjJOByOTzic+JJbl9JTSdPW5Op2r3MZnn8oRquzhsKx/j7A847HIj2M7J23/wCH/Id+h0VF cbqHjyztZbsg6YYbORo5kk1JY7hipw/lxFfmA5xllLYPHQnsI2V41dTlWAI+lTOlKCTktwvrYdRR RUDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAo+BP8AkSNB/wCwbb/+ilrZqDTvsv8A Z9t9h8n7L5S+R5OPL2YG3bjjbjGMcYqevsou6TOcKKKKYBRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBjeDZ/tGkTyf2F/YmNSv0+zbNvmbbuZftGNq/6 7HnZxz5uctncdmszw1DrMGnSpr13DdXZvrt43iGFFu1xI1uh+VfmWExKeOqnlvvHToAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigDC8K2s9l4Y0qyuk8ue3soYpUyDtZUAIyODyO1VvEPh5 NX1TS743TQGxl3ugTPnLuVghOeBuRT36Vf0O+/tPRbHUvK8r7XbRz+Xu3bd6hsZ4zjPWrlfIc8oz 5tmb9LGHB4dji8YTeIftLHzIdi2+zAVyFDPnPJKoo6dqZJ4c36Ld6d9sx9pvzeb/ACvu5mEu3Gee mM/jjtW/RR7Wemu36DsYs2kX0OqXN/pGow2xu9puIrm2MyFlAUMu10KnAAPJBwOB3lj0qY6np2oX N9581payQSHygvms5QluD8v3OnPXrxWrRS9pL+vuAwBouqWb3a6Nq8Frb3MjzFJ7MzNFI5JYoQ6g Ak5wwbnPbit5QQoBJYgck96WilKbluAUUUVIBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAUfAn/ACJGg/8AYNt//RS1s1jeBP8AkSNB/wCwbb/+ilrZr7M5wooooAKKzPEmt2uh2KTzxzXE 88ogs7O3Aae7mIJWKNSQC2FZiSQqqrO7Kisw861zW7Gy1OWHxX8ebPwnrBAefR7S90pIbTcAVRft Vu0zfKVy7kbzlgkasEUCx6xRXnPhzTn8S2T33hz46+INZtY5DE89gdFuI1cAEqWSzIBwQce4qTWd F1HR1tG1H4w+M4BeXcdnB/oWltvmkOEXixOMnuePU0PR2/rXYL6XPQqK8917RdR0OxW91T4w+M7e 3eeG3V/sWltmSWRY41wtgTy7KM9BnJwKv/8ACG+I/wDorHjP/wABdJ/+QaPMDs6K8p1+70jw9qJ0 3X/2jNQ0m9VQ5t7260KCUKeh2vaA4PrW5p3hrVtRsIL/AE/4x+LLy0uIxJDPBDo8kcqEZDKwssEE dxQtVdBsd1RXGf8ACG+I/wDorHjP/wABdJ/+QaP+EN8R/wDRWPGf/gLpP/yDQB2dFcZ/whviP/or HjP/AMBdJ/8AkGj/AIQ3xH/0Vjxn/wCAuk//ACDQB2dFcZ/whviP/orHjP8A8BdJ/wDkGq0vh7U4 tTg0yX4z+KUv7iN5YbZotHEsiIQGZU+xZIG5ckDAyPWgDvKK4z/hDfEf/RWPGf8A4C6T/wDINH/C G+I/+iseM/8AwF0n/wCQaAOzorznxJpz+GrFL7xH8dfEGjWkkohSe/Oi28bOQSEDPZgFsKxx1wD6 VzPhb4seDtE8ca1pes/GjTNf0kabY3FldXl5YfLO8t2s8avbRxqcLHbkhgSNwPRqAPbKKK5nW9Uv 9T1Sbw14an8m5i2jU9TCK66arKGCIGBV7plIZUIKxqwkkBBjjmAOmorjP+EN8R/9FY8Z/wDgLpP/ AMg0f8Ib4j/6Kx4z/wDAXSf/AJBoA7OiuM/4Q3xH/wBFY8Z/+Auk/wDyDR/wnmleHv8AiXfEPWNF 8O6knEdxdXK21pqKf89rcyt/33EWLxMQCWRo5ZADs6K5Ow+Jvw2v763sbH4heErq7uZVhggh1m3e SV2OFRVD5ZiSAAOSTXWUAc/4Bh0aDQrlNBu5rq0Or6k8jyjDC4a+na4QfKvyrMZVHHRRy33j0Fcn 4Q1q9m07XMeAdT0dbC+vfs8I+zouqEXE2ZYQXUhpSvmEyiMEzAhnXL1cuNf1aLw7baongjxBPdzS lH0uOaxFzAPm+d2a5EJX5R92Rj868fewAQ+CvDEOnW9jret6dos3jWXTYLbWdZtbONJbyVY4xJ+8 CKxQsgIBAGFXgYAE1v4I8F23h258OW/hDw/Dot1KJrjTo9NhW2mcbSHeILtZvkTkjPyr6Cj4aw6N bfDrw1b+HLua80WLSLVNOuJhiSa3EKiJ2BVcMU2k/KvJ6DpXm/jy/uPC3jLxvZWUiwz+KNEtp9N4 xm98z7Ex46/62075pNvZbu9vuv8AoNJbvbT8Xb9T0+58J+Fbn+yPtPhrRZv7E2/2T5ljE32Dbt2+ Rlf3WNiY24xsX0FN0nS/Cc2vXvifSdO0STV5i1neanbQxG4cxlVaKSVRuO0xqCpPGwDHArxvQLVI YvCnwiRzKmi+KphKsh3N9hs1+1wZznjM1ouTirHhrXvFvhjQtb121bRZNDj8cXdrPZyW8jXUyz6m YmkWYSKkZUycJ5b5CfeG7C0rOVls9vT3bP583ysLXlv1vb5+9df+S/O56vb+CPBdt4dufDlv4Q8P w6LdSia406PTYVtpnG0h3iC7Wb5E5Iz8q+gqe58J+Fbn+yPtPhrRZv7E2/2T5ljE32Dbt2+Rlf3W NiY24xsX0FeeeL/iTrieMNb0LQI2tU0QxxSSP4U1LVxeTPEsuwPaYWAKroMsXYlidoCjfpT+MPGG q6r4Q0zR7DT9BuNe0W41G7TWLSaaWxeM2/7vy1eIsf3rKQSh6HttYiubb+tG/wAkxtWdn/X9XO3t /D2gW3iK58R2+h6ZDrV1EIbjUY7RFuZkG0BHlA3MvyJwTj5V9BVK38EeC7bw7c+HLfwh4fh0W6lE 1xp0emwrbTONpDvEF2s3yJyRn5V9BXmOp/FnxNJc6xd6Hpk9zbaVezWcemx+EdUu5NSMDlJCl5CP IhLMrBVKybcAs3JVdiz0zTfiB8VPFVp4vsYNU03QEsodP0i+iWS3QzQea9w8TZVpCWKBmB2hGC43 NlLWzX9f12372BqzafT/ADt/X4XO11PQPBIm8Pw6novh4SadIsWgpcWsO62dVDBbYMPkYLECAmCB GD/Dxet/D2gW3iK58R2+h6ZDrV1EIbjUY7RFuZkG0BHlA3MvyJwTj5V9BXnfiXwtofhTxP4DtvD9 mNOsZ/E7y/YomIt4W+wXWfKj+7ED1KoApOTjJJNXQfibq83jnRNMl1PSNc0vWb6ezSbTdAvreCEr HJIrJfSO9vdf6ooQm05JI+6RTSvov62/zCS5dfK/4v8ARHoNv4I8F23h258OW/hDw/Dot1KJrjTo 9NhW2mcbSHeILtZvkTkjPyr6Cp7nwn4Vuf7I+0+GtFm/sTb/AGT5ljE32Dbt2+Rlf3WNiY24xsX0 FcZc/EDWYvAGr+IFtrA3Vl4nbSI0Mb7DCNRW13Ebs79jE5yBu7Y4rN8f/EjWdC8bXWjXOs+H/B9m CkemXPiDSLqW11N/K8xiLxJY4YMHKbG3NlScHcFqYvmtbr/kn+o3Fq/ldfc7Hpdv4e0C28RXPiO3 0PTIdauohDcajHaItzMg2gI8oG5l+ROCcfKvoKpW/gjwXbeHbnw5b+EPD8Oi3UomuNOj02FbaZxt Id4gu1m+ROSM/KvoK4LxZ8StdXxdrOiaAhtk0Xy45JG8Kanq63kzxLLsV7TasCqHQZYuxLE7QFG/ 0rwnqdxrXhjTNXvNMudKuby1jnlsrhSstu7KCY2BAOQeOQDx0FNK6v8A1rsS9HY5/wAe6ZoGlaBp Wpp4D0zXJdCubSLS7cWSFtPR54Y2lhOxvKWJMSHaAAIRyoGR0HhzVf7YsXufs/kbZTHt37s4AOc4 HrXjPhrw54Wns9RvLz4Hw+Mbu58Qa28+pR2GlOxI1a7QI7XU0chYKq9iMFQDwQLvg+SLwn8TtdTw x8IdT0+K98P6XNcaZpaaXbtbOLrUlDygXKxszqAQUZzhQG2kAUAeh+Fru1sPh7pV9fXMNraW+kwy zzzOEjiRYgWZmPCqACSTwAKoKfH2vD+0tFvdG8O6dJxbW+r6LPc3cqdpnC3EPk7u0TKXVQC5VmaK PiPEOsa8vgjwxoepeAPEWliHWvD8Mt7cXGnvAjJqVp1EVy8hBK4GEPJGcDJHp/iTX9W0q+S3sfBH iDXomiDm4sJrFI1OSNhE9zG24YB4UjDDnOQPHwWEp1HKc9dTSUmtDI/sj4o/9Dn4N/8ACUuf/lhR /ZHxR/6HPwb/AOEpc/8Aywrg5/jZ8QY7PxXMv7PnjNn0W5jhs081P9NVpmQtwpJwoDf6OLheeWVc Obtl8YPHc/ifw9pUnwF8Zx22qaal5c3PnQf6LIUdjFliIhgqBiaSGT5uYwdqt3fUqH8qJ5mda9/4 p8LD7d4xv9G1PRm4nvtO06Sz/s70kmR55t8J6NICvlYDMCheSLrqo+GNZ1HV/tH9oeE9a8P+Vt2f 2jLaP52c52/Z55cYwM7tv3hjPOPEvhn4X8ID4Y+EHf8AZ7h8Qyy+H9Pml1OLTdGK3Lvaxs7kzzpI W3EgllBJBPIwTy1srhOV4PlGptHvdYfiKHRpfEHhN9Uu5oLuHVpH0tIxlZ7j7DdKyP8AKcL5LTt1 XlF5/hPDfCJo9H8YeMNA0fwDeaNpUmtQzE2y2UVrp7tpNi7QvHHNu37upiR0LPncRkjrW1m9uPFG l2dz4C1MRx6s8MOo3X2d44R9luj9rj8p5GRTsEWZBEcXIHUla8+jR9lilG97Mtu8TatvCfhW2/tf 7N4a0WH+2939reXYxL9v3bt3n4X97ne+d2c729TUFx4I8F3Ph228OXHhDw/NotrKZrfTpNNha2hc 7iXSIrtVvnfkDPzN6mpfH2qXWh+Bdf1qxiWW6sNNuLqBCMhnSNmUEd+QK4rwf8MPA+s+CtL1PW9I s9c1q/tIbu41+dAb+SZ1VvNS5H7yMg42bGAQABcACvo1rfyt+N/8mZPS3nf8Lf5o7248PaBc+Irb xHcaHpk2tWsRht9RktEa5hQ7gUSUjcq/O/AOPmb1NQ23hPwrbf2v9m8NaLD/AG3u/tby7GJft+7d u8/C/vc73zuzne3qa5e51jxhqXiLWND8IXWi20Ph2OGG4k1a1luZL24eJZQgKSx+UoRkzIRISXPy jb82ePH3iLxFL4Fj8JxaTp6eKNJub+aXUoZLg2nlCAgKkbx+ZzKykFl7Nnjaz32/rf8AyYJO+v8A X9f8MdjceCPBdz4dtvDlx4Q8PzaLayma306TTYWtoXO4l0iK7Vb535Az8zepqUab4S1LxadXGn6H eeI9JQW5u/JikvLNXUsI9+C8YKyMduRkOexrh7P4geI7rwpp1ulrpaeJr7xHc+H1maJ/savA83mX Bj379vlwMwj353ELvxlq5GG61PSNa+Ikuvw6Br96fE+gQybtNaO2PmLaoHWF5ZCroGBU7zhlDe1O K5mkutvxt/mv6uPlaunvr+F1+aaPaLbwn4Vtv7X+zeGtFh/tvd/a3l2MS/b927d5+F/e53vndnO9 vU1BceCPBdz4dtvDlx4Q8PzaLayma306TTYWtoXO4l0iK7Vb535Az8zepry3U9T8W2sPxhv9R1HQ 9Z0TSnmKaTqGmSyo6iwikSPJuNoj+Yb02fMd5G3dgdaNe8X61rGp6X4Pfw9p0GhQW6TjULKWb7TP JCsoiTy5YxCioyDefMyWPyjZ8y2jzPsn96uEotfj+Fv8+p2Vx4e0C58RW3iO40PTJtatYjDb6jJa I1zCh3AokpG5V+d+AcfM3qahtvCfhW2/tf7N4a0WH+2939reXYxL9v3bt3n4X97ne+d2c729TXDj x94i8RS+BY/CcWk6enijSbm/ml1KGS4Np5QgICpG8fmcyspBZezZ42t0/wAL/EOo+I/Dc9xrENtH qFlqN3p1ybZSsUj287xeYqszFQwUHaWbGcZPWnbVr+tHb8xNNJPv/wAH/Jlq48EeC7nw7beHLjwh 4fm0W1lM1vp0mmwtbQudxLpEV2q3zvyBn5m9TV248PaBc+IrbxHcaHpk2tWsRht9RktEa5hQ7gUS Ujcq/O/AOPmb1NadFIR57dWMPg7xxq2r6foui29hrdtAzi0to4LiW8SW4aeWZ1jzJuWaHBZmwVc4 GSW7evOPHsOjL8Rbm4gu5m1p9ItEu7cj93HbrNdGBwdv3mdrgH5jwi8Dq3o9eFm1OMZRklq73/A1 gwooorySwooooAk077L/AGfbfYfJ+y+UvkeTjy9mBt24424xjHGKnrG8Cf8AIkaD/wBg23/9FLWz X2UVZJHOFFFFMDjPiH/yN3w4/wCxkm/9NOo1m/tC/wDIj6d/2Mmj/wDpfBXWeLNC/tq3s5be6+xa nptz9s026MfmLDP5bx5ePIEiNHLIjLkHa52sjhXXjPFXjLwnc2kWh+PtC161vra4huZbW20jULuB ZoZBJHJFcW8JWWPcispyDjAdEYMiuLtOMuzT+5pg/ha7pr71Y0fipqt9Bd6PpGjap4lh1S7M0yWe g2dnJcXEUYUOzSXimCJFLpksQWLALk8Vwd1rPiHxR8MPCc+pXElprEXjWOwa4mgiMqmG7liDukbG LzNqDOwlN2SBt4rc8U+Nvhd4le0l1RPGaz2Zc29xZaHrdnPGHADqJYIkfa2FyucHapIyBjPfXPgw fDEXhqLTfFlrpkN6b+GO00HW7d4rgyNIXSSOJXU7mY4DADPAxUpbX7p/c09O2i+8J2cGlvZr701+ bRn+Pb/XrK+1fwbq2uXXiC2tL/w7qNre3cEEc8fnaiqNC/kRxoRmHcp2g/MwJOBU0/iz4n6/c6/q fhjS/E0jadqlzY6fZ2g0gabN9nlKYuTPKLrLlTuKGPaCu0HG571r4j+D1vpc2nCw8WzxT3cN7PLd aDrc9xNNCytEzzSRNI+0omAzEADGMcVDret/BvV9Qu765tfG1vLfD/TVsNK1+yiuzjGZo4I0SViv ykuCSoAJwAKpOyS9f/bf8mvxKbTVvT9b/e9fwLul2/i+6+N3jd/D2r6JpR+w6UbhNQ0qW9JYxy42 mO4h24567s+3ex8WfGHiX4bJpfiS71G21u1nt2srvSI4Ftg1wEaQXcP35FjXa3mqzuFjy45QhsvV tc+EGpa5ca1IPiBZ31zFHFPJp1j4isRIsYIQMsCIpwCccd60bLxr8K7XVYdVFv4uuL6Cw/s+Ke80 DWrllgyCy/vYW5Yhdzfefau4nAxNtPn/AJ/15brVIhLv/W39ee2zZLdS+Nl8ReCvDR8eMW1bT9Ru 9Sv7SxtmLlDbmMW+5CqKvmkKWD5X725iGGbqXi3xjYeGPE+lxa552paJ4o0/SrbV5rOJmmhuJLVj 5sahYy4WdkOwJwARtJzXOajcfDNtc8LR6Y/jPT/D+iWt/F9ntdN8QW86NO0JRY5I4gwjHlt8m8KB tAXA46q38VfCGDw5H4fj03xMNPju0vdjeG9YZ5LhJRMJXkMO+R/MUMWZiWxzmqha6b2/+2T/ACuv O5XRd/8Ah/8AgCeJ9Y8a2vjaPwNpd94w1RLPS01G51HTY9HW+maWaRFRvtQjhESiM/ciLElcsuDv ZrusfFi38GaLeX+keI7fyTdnVzoMGn3GrMqNi2YRSNJAd6ZaRYt7bsBQBkVY8UeMvhV4kuLa61O3 8XpeWoZYLyy0HWrO5RW+8gmghSTYcAlN20kAkZArPl1v4PvY2VoqeP4BZmYxT21h4hhuW81g8m+d EEkm5gCd7NyB6VOtv67/ANIG1zXX9af56+RLrHibxVP4L0jVPC+reLPEWjwy3q6tf6VpNpHrQeKQ rHEbW5jVPlO9XCxbyUUqoBOSL4iXlkthd6f4gvfEunwaDrt7cfa9OW0uZ57SWIJHJH5aNHIm50IC oCedvSo5tb+Dj2FhZQ23jexSwEohksNK1+0mPmsGkLywxrJKXYBmLsxZvmOTzVzSPFnwh0mWwlsN L8SRSWFvPbwMfDGruSk7K8xctAfMZ2RWZ33MTkk5Jy31t5/k0vxsxwaTV1t/n/X+RoWOoeKtA1Dw Ze6n4rn1+LxNci1u7OS0t4obZ3t5J1e2MaLIEUxlcSPISrDnIyefm8ReN4dA1PxgfF07x6f4wfS4 9LFlbLbSWn9pLbbZG8sylwrnDK6DhchiGLWPDviH4PeH9Si1DTLHxestujx2iT6Hrk8NmjfeW3ik iaOBcADEaqNvy9OKtSeMPhK+jXOjvp/iY2N1qB1KaL/hGtY+a4M4nL58jI/egNgHHbGOKq65+Zbf 8FP56J/fbYmPw8r8r/c7+m60Xa50vxSa6TxB4Aexhhnu18QXBgimlMUbv/ZGo7VZwrFVJwCwViBz g9K5/wCLd74+m+EnjaPW/DPhmysD4b1LzZ7PxBPcyp/okuNsbWcYbLYBy4wCTzjBPFnjr4Y+KLez h1dfGf8AoVz9qtpbPQ9bs5YpfLePcskESOMpLIpGcEMc1wF5p2h+KfFWtWOn6h8QJvCr6RawmDU9 X1q3jmmd7oXCbbmRWkUx+QCOVwfc5kD2X+0vin/0Jvgz/wAKu5/+V9Znwwn19734kz3mmaZDrX/C QKVtItQeS2LjSbDYpnMKsFPy5bysrk4DY59Grk9TtLrwxrN/4l0q2mvdP1GVZtasYYzJOHWNIhdw AZZ2EccavCMllRWjHmKyTgHJfEfXvj/Y6HDL4O+H/gy9vzcqskf9vyXOItrZO2SK1A+YLz5hPP3T klaV74i/aOXxP4ht7b4deDG0mDTXk0mX+2nbzbrYhVN5CtJ8xcbWigXjHmgAM3T/APC4fBHr4m/8 JTVP/kej/hcPgj18Tf8AhKap/wDI9AFLwTrXxxuvDFpceJvAfgy11Zt/2iL/AISOaDbh2C/IltOo +XaeJXznPyk7Rc8ZyarD8W/DsmiWVle348N6v5UF5dtbRP8A6XpWd0ixyFcLkjCHJAHGchf+Fw+C PXxN/wCEpqn/AMj1xeuQ3/jXXYdb1ZtV0yaJHt9MstO1Ka1mtYZGQusktu6mSSQxxllDNGpRFTcV aWQA2vife+PpPCKf2p4Z8M2u3W9Ea1+zeIJ5/NnGrWexH3WabEPOXG8jAwjZ47m4u/Gi+Hbae30D w/JrTSkXFpJrcyW0afNhknFqWduE+UxKPmbn5RuxtO+GXh7ydOm1CbxNd3FtLb3XlXninUbiLz4n WRGaN7hkbbIisAQRkCu5oA5/wDc6zd6Fcy68sy3a6vqUUYlh8pvs6X06W5AwMr5KxYb+IYbJzk9B WZ4ah1mDTpU167hurs3128bxDCi3a4ka3Q/KvzLCYlPHVTy33jp0AY3gSf7T4H0G5/sL/hH/ADdN t3/snZs+wZiU/Z9u1cbPuY2rjb0HSqPjHwNovirX/Dutam12tz4fuzdWohlCpITtO2QYO5dyI+Bj 5kX0xWbr2n+KtM8OnS7DxV4g1C7uZWf+1JLSza5tgNmERUtxDtOG+/Gx+ZsHgYzLmbx1L/ZHl6lr Vv8AYNv2ny7CA/2ljbnz90J252nPk+V99sY+XadU+wdGu50lp4F0S2+Jd58QEN02rXditkyNIDCi ggl1XGQ7BEBOeQi8esMvw/0aXwzfeH2ub8Wt7rB1eRxIm8TG6F1tB242b1Axgnb3zzWRb3njaLxF c6o8+pz2k0QRNLksYxbQH5fnRljExb5T96Rh87cfdxSt/wDhP4vDtzpb674gnu5pQ6apJp9sLmAf L8iKsAhK/KfvRsfnbn7uBaWt0/zv+eo7v9fuVvyOl1jwPHc+ILrXdF8Sa54av71EW/fTTbul3sG1 GdLiGVAyjjcoViMAkgLi5Z+E7ODWNF1eS/1K7vNI0+awikuJg7TrKYi7ynblnzCpyCByeOmOUuZv HUv9keXqWtW/2Db9p8uwgP8AaWNufP3Qnbnac+T5X32xj5ds9veeNovEVzqjz6nPaTRBE0uSxjFt Afl+dGWMTFvlP3pGHztx93AtNv6/q4rl+8+HqC91GbQvFviXw3b6nK097aabJbmKSZ/vyqZoZHiZ u/lsgz82AxLG54g8EWmpa1Fr2naxq/h/Wlt1tZL/AE54i88AJIjkSeOSNwCxIYpuUk4YAkHl7f8A 4T+Lw7c6W+u+IJ7uaUOmqSafbC5gHy/IirAISvyn70bH525+7ia5m8dS/wBkeXqWtW/2Db9p8uwg P9pY258/dCdudpz5PlffbGPl2q23l/w35aemgN3d3/X9b+ptWnw809LnT73UNc13V7+z1E6ibq+u EZppDDJCEKKixpGElbCxqgzycksTU0f4X2GnXmhSHxL4jvLTw/cGbSLCeaDyLVfKkiEfyRK8ihJM AyM7DaMNy26vb3njaLxFc6o8+pz2k0QRNLksYxbQH5fnRljExb5T96Rh87cfdxSt/wDhP4vDtzpb 674gnu5pQ6apJp9sLmAfL8iKsAhK/KfvRsfnbn7uKTtsF9Lf11/zZpal8K9Mvpb6I+I/EVvpd5qa aq+lwzQLbrdLMkxcHyjLhnTJQuVyzEAHBF7xV4DPiKXUYbvxh4lh0jU12XukRPbG2lQoEdAzwtNG rKOQki8kkbSc1i3M3jqX+yPL1LWrf7Bt+0+XYQH+0sbc+fuhO3O058nyvvtjHy7Z7e88bReIrnVH n1Oe0miCJpcljGLaA/L86MsYmLfKfvSMPnbj7uJSSVv67fovuHd3uauo+ArdtZm1fw/4h1vwvd3M UcV4dMNu6XQjULGXS4ilUMqjaGUKxGASQFx02kWX9naVa2H2u6vPs8Sxm4upN80uBjc7cZY9ScCv N7f/AIT+Lw7c6W+u+IJ7uaUOmqSafbC5gHy/IirAISvyn70bH525+7ia5m8dS/2R5epa1b/YNv2n y7CA/wBpY258/dCdudpz5PlffbGPl2u4rDfEPhp/B2i6jqNr8TPFejWE+oyzRW0Vtp80Udze3ZYI u+zeTa09xgbmOA3JAGRofCfRbqG71bxHqniLVdc1K+SCxeW9S2QRwwGV0VVgijH3rmQknJPHpWbf w+KdR1K9l1MX1/ptyiBNJn06JrW3kQoyTRnyvN8xXQOC0jAMcgDC7ev8A29xbaPLHcwSwubhiFkQ qSNq880AUdWsf+Ez8EWTJL9gnnNlqdsxXzVinhliuYg65UunmRoGAKllyAykgiJfiX4U04fY/GWu aL4T1mPiew1LUoos+kkLuV86FuqyADurBHV400fA/wDyJeh/9g63/wDRa1a1rTLfVLXyZhtdeY5A OUP+HqK+dwuL+rzcH8N/uNZRujF/4Wx8LP8Aopfgz/we23/xdH/C2PhZ/wBFL8Gf+D22/wDi6i/4 Qz/qJf8AkD/7Kj/hDP8AqJf+QP8A7KvV/tDD/wA34P8AyI5GVNd+KOg3dmbTwHrOi+JNVl+UPaXS 3NtYr/z1uGjbgf3YwQ0hGAVUSSR818OvDPiS30+10Cy+JXiy10vTLKO2tUjtdMby0jCpGhZrMk/K O5JOOtdh/wAIZ/1Ev/IH/wBlXS6dZW9harbWybUXkk9WPqfeufFZjT5LUndv8Bxg76mT4O8NDw4N Vkk1rU9Zu9VvRe3V1fiASM4gigAAhjjQKEgQcLnOSSc1f1GHWZdU0V9Lu4YLSG9Z9USQZae3+zzK qJ8pw3nNA3VeEbn+E36zdW0a11PUtFv55Jll0e9a9twhAVna3mtyHyDldk7njByF5xkHyaNa1ZVJ s0a0sbjqroyOoZWGCCMgj0rgofhjDZ2J0fR/GfizSPD+cLpFncQCGOPPzRRzNC1xGh54SUbQcIVA AFaSXxpa3mvRJq+sXcV5JItm0llB/wAS9cvtMBWEbsblx5vm/cXOfm3U7hvHkvh220tNf16C7hlL vqken2puZx83yOrQGEL8w+7Gp+RefvZ+mVSm9box1Oi1nwBbXeoTXuk+Ite8OtdWyW16mmyw7buN BtTd50UhVwpK74yj4xljtXF+18G6LZ6p4fvrGOW0XQLGawsbaJh5QikEQIbILEgQrg57nOa5q4v/ ABpL4ittUS51KC0hiKPpcdlGbac/N87s0ZmDfMPuyKPkXj72Yba48cRf2v5mqaxcfb932bzLGAf2 bndjyNsI3Y3DHneb9xc5+bdXtYfzf1r/AJv7xWsbN38ONHm0V9Pg1DVLSca1LrdtfwvF9otLqSVp GMe5Cm353TaysCrEHPWq9v8AC7SVi1X7ZreuahcatqNlqN3c3EsPmPNamMx4CRqqqfKXKhQOuNvG Mi4bx5L4dttLTX9egu4ZS76pHp9qbmcfN8jq0BhC/MPuxqfkXn72blxf+NJfEVtqiXOpQWkMRR9L jsozbTn5vndmjMwb5h92RR8i8feyRqQjs10/C3+S+5Dbbd3/AFf/AId/e+5pa78OdP1W88RSf23r VnZ+I7VoNUsLdoPImYw+T5wLxM6SBAo+Vgp2AlTzmTWfAMF5qE19pniTX9AlurZLa/GmyQAXiINq F/NifY4Uld8exsEZJ2rtw7a48cRf2v5mqaxcfb932bzLGAf2bndjyNsI3Y3DHneb9xc5+bdDcN48 l8O22lpr+vQXcMpd9Uj0+1NzOPm+R1aAwhfmH3Y1PyLz97J7SFrXQO7/AK9P8kdja+DdFs9U8P31 jHLaLoFjNYWNtEw8oRSCIENkFiQIVwc9znNW/C3h+y8OWl5bWMtxIl3qFzfyGZgSJJ5WkcDAHygs cd8dSa4+4v8AxpL4ittUS51KC0hiKPpcdlGbac/N87s0ZmDfMPuyKPkXj72Yba48cRf2v5mqaxcf b932bzLGAf2bndjyNsI3Y3DHneb9xc5+bce1he/N+Pd3/MNbW6f1/mem0V5ZcN48l8O22lpr+vQX cMpd9Uj0+1NzOPm+R1aAwhfmH3Y1PyLz97Ny4v8AxpL4ittUS51KC0hiKPpcdlGbac/N87s0ZmDf MPuyKPkXj72T2kO6CxF8QJ93jiS2/sLyfL023f8AtbZj7VulnH2fdt58rbvxuOPtHRc5b0GvMJbP xVdX11cane6xqMUsrPb281nEkdoCSSkZjiVivQfvGc4Uc5yT6fXj5tKMuSz7/oXAKKKK8c0Ciiig Cj4E/wCRI0H/ALBtv/6KWtmoNO+y/wBn232HyfsvlL5Hk48vZgbduONuMYxxip6+yi7pM5wooopg FUdZ0q01a3EN0rfKco6HDL64Pv8A57VeooA5n/hCtK/5+L3/AL7X/wCJo/4QrSv+fi9/77X/AOJr pqKAOZ/4QrSv+fi9/wC+1/8AiaP+EK0r/n4vf++1/wDia6aigDmf+EK0r/n4vf8Avtf/AImj/hCt K/5+L3/vtf8A4mumooA5n/hCtK/5+L3/AL7X/wCJo/4QrSv+fi9/77X/AOJrpqKAOZ/4QrSv+fi9 /wC+1/8AiaP+EK0r/n4vf++1/wDia6aigDmf+EK0r/n4vf8Avtf/AImj/hCtK/5+L3/vtf8A4mum ooA5n/hCtK/5+L3/AL7X/wCJo/4QrSv+fi9/77X/AOJrpqKAOZ/4QrSv+fi9/wC+1/8AiaP+EK0r /n4vf++1/wDia6aigAooooAw9T8LaZf3j3TmaF35cRMAGPrgg81V/wCEK0r/AJ+L3/vtf/ia6aig Dmf+EK0r/n4vf++1/wDiav6N4d07S7g3EPmyy4wrSkHZ64wB1/z3rXooAKKKKAOf8Aw6NBoVymg3 c11aHV9SeR5RhhcNfTtcIPlX5VmMqjjoo5b7x6CsbwbP9o0ieT+wv7ExqV+n2bZt8zbdzL9oxtX/ AF2POzjnzc5bO47NABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc7oSS6N4P02O/t51 ktbKCKaOKJpnDBVUgKgJbB9M+vSj/hIbH/n11n/wTXf/AMbroqK8z+y6bbcmy+dnO/8ACQ2P/Prr P/gmu/8A43WlezLaWz3Esc7ImMiKB5X5OOFQFj17CtCik8ppdGw52c7/AMJDY/8APrrP/gmu/wD4 3R/wkNj/AM+us/8Agmu//jddFRT/ALKo93+H+Qc7M+9mW0tnuJY52RMZEUDyvyccKgLHr2FZv/CQ 2P8Az66z/wCCa7/+N10VFJZTS6thzs53/hIbH/n11n/wTXf/AMbrSvZltLZ7iWOdkTGRFA8r8nHC oCx69hWhRQ8ppdGw52c7/wAJDY/8+us/+Ca7/wDjdH/CQ2P/AD66z/4Jrv8A+N10VFP+yqPd/h/k HOzPvZltLZ7iWOdkTGRFA8r8nHCoCx69hWb/AMJDY/8APrrP/gmu/wD43XRUUllNLq2HOznf+Ehs f+fXWf8AwTXf/wAbrSvZltLZ7iWOdkTGRFA8r8nHCoCx69hWhRQ8ppdGw52c7/wkNj/z66z/AOCa 7/8AjdH/AAkNj/z66z/4Jrv/AON10VFP+yqPd/h/kHOzPvZltLZ7iWOdkTGRFA8r8nHCoCx69hWb /wAJDY/8+us/+Ca7/wDjddFRSWU0urYc7Od/4SGx/wCfXWf/AATXf/xutK9mW0tnuJY52RMZEUDy vyccKgLHr2FaFFDyml0bDnZzv/CQ2P8Az66z/wCCa7/+N0f8JDY/8+us/wDgmu//AI3XRUU/7Ko9 3+H+Qc7M+9mW0tnuJY52RMZEUDyvyccKgLHr2FZv/CQ2P/PrrP8A4Jrv/wCN10VFJZTS6thzsyfB kMtv4P0WCeJ4pY9PgR0dSrKwjUEEHoQe1a1FFeoQFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBmeGodZg06VNeu4bq7N9dvG8Qwot2uJGt0Pyr8 ywmJTx1U8t946dc/4Bh0aDQrlNBu5rq0Or6k8jyjDC4a+na4QfKvyrMZVHHRRy33j0FAHM+GLzW9 a0O41uz8QaLeWGq2y3WgSx6PNF5MUilo2nDzkzfK0ZIAhPDdNw2zXFp40bw7bQW+v+H49aWUm4u5 NEme2kT5sKkAugyNynzGVh8rcfMNs/gSf7T4H0G5/sL/AIR/zdNt3/snZs+wZiU/Z9u1cbPuY2rj b0HSsHU/EXiLWPGOoeFvB50uzbSI4n1LU9St3uY0klUskEcCSRlm24dnLgKCoAYsdp1sB0lxBr7e Irae31PTI9FWIi4tJNPd7mR/mwyTiYKi8p8piY/K3PzDbDbW3ipf7X+06zosnm7v7J8vSpU+y/e2 +fm4Pn4ymdvk52t03Dbm2Or+IPD+l61feP5dH/s/TIftS6rp0UsayQhWaTdbsZHRk29nfcCCMHKg k+IfhVNITVTdX5tprgW1qF0q6aS8cruH2eMR77hduW3xKy7QTnAJB/X3gW7i08aN4dtoLfX/AA/H rSyk3F3Jokz20ifNhUgF0GRuU+YysPlbj5htu3EGvt4itp7fU9Mj0VYiLi0k093uZH+bDJOJgqLy nymJj8rc/MNtCLxt4Zl8Nt4hGosunpdJaStJbSpLDO0qxCKSJlEkb73UFWUEZBOBzVjVvFegaTc6 nb6hf+TLpem/2peL5Lt5Vrlx5nCnP+qf5RluOnIym7b/ANaX/LX0HFOW39dPz0FtrbxUv9r/AGnW dFk83d/ZPl6VKn2X723z83B8/GUzt8nO1um4bYLi08aN4dtoLfX/AA/HrSyk3F3Jokz20ifNhUgF 0GRuU+YysPlbj5htraD8QPCet6rbabp2oTtNdxGWyeaxnghvEADEwTSIsc+AQf3bNxz0ryu0+Mms NDDd/wDCWeAr+/k1v+zl8LW9u6akym8NuPn+1MQwXEhJhxgHoOapJ8yj3/zsTdWbPariDX28RW09 vqemR6KsRFxaSae73Mj/ADYZJxMFReU+UxMflbn5hthtrbxUv9r/AGnWdFk83d/ZPl6VKn2X723z 83B8/GUzt8nO1um4bZrTXtJurvVbWG7/AH2kOEvleNk8omMSA5YAMpVgdy5HUZyCByV/46u9d1bS NC8BfZZLnU9NGrPqOo20pgtLMsFRzDmN5HkOQqbkwAzE8BWW7sv66/km/kPzf9dPzaOguLTxo3h2 2gt9f8Px60spNxdyaJM9tInzYVIBdBkblPmMrD5W4+YbbtxBr7eIrae31PTI9FWIi4tJNPd7mR/m wyTiYKi8p8piY/K3PzDbwnjDV/iL4c0N5NTvtDnDappsVvqOm2j25KS3kUUsL28ry4+VmxIJDnce FKgnpZ/iD4Wg1/8AsS4udQguPtYshPLpV0loZ2xtj+0mPydxJCgb+WIUcnFNK+3p+X+a/qwPRXZo W1t4qX+1/tOs6LJ5u7+yfL0qVPsv3tvn5uD5+Mpnb5OdrdNw2wXFp40bw7bQW+v+H49aWUm4u5NE me2kT5sKkAugyNynzGVh8rcfMNs1z4r0C2h1+aa/2p4eXfqp8lz9nHkibsvzfu2DfLnrjrxVTXPH XhvR7i1tribULq5ubcXUdvp2lXV9KsJOBI6QRu0ak5ALAAkEDJBxN0Oz/r+vNGlcQa+3iK2nt9T0 yPRViIuLSTT3e5kf5sMk4mCovKfKYmPytz8w2w21t4qX+1/tOs6LJ5u7+yfL0qVPsv3tvn5uD5+M pnb5OdrdNw20tR8eeGLGz025e6vbk6nbi5tILHTbm7uZIcA+YYIY2kVBuUFmUAFgCQSBWzoWradr mk2+q6TdpdWdwu6ORcjPOCCDyrAggqQCCCCARVWZN0cz411DxV4c+Gl9rk2t6L9v0i2nvr+4TQ5Z IpoIkkcpFbm7Uq+0KMtMQSDwNw29ba3drdbvs1zDPtxu8uQNjPTOK8y8TeKvGlsfiBq9nrHh+w0X wjKwaGXQZry5mRNPt7t2DC8hXcfOZQuAPlGTzU/gu38VeGPiLaeHNa1nRdWtNV0i8vQ9ppUtpJE9 tNaoBlriUMrC6bPAIKjmkM9MooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigDk/CGi6Beadrl0/gbTNGl1e+vbbVITYoraikdxNEss3yL5qypmQbgRiY8sDk3 LjwR4LufDtt4cuPCHh+bRbWUzW+nSabC1tC53EukRXarfO/IGfmb1NXfDUOswadKmvXcN1dm+u3j eIYUW7XEjW6H5V+ZYTEp46qeW+8dOgDM8Jw6zbeFdJt/Ed3Dea1FYwpqNxCMRzXAQCV1AVcKX3Ef KvB6DpXG6hpXiDwx4913xDpegP4m0bxFHAL6xtp4Y7qCeKMx71E7JG8TIEBBcMCMgMCcXPDup2/g 3wqnhxvD3iC3tPD9illpj3UlpJJqqQJsUxGOUgMQif60QjLjgfNtLj4kW8Xh221RPC3iCe7mlKPp cZtBcwD5vndmnEJX5R92Rj868fewmhp2OItvh5fr4X+Jr6B4JtfDEXiTSFtNN0VPssMglSGVCziB mhXezjBDnp82K7XxbpWt2us+FPFGmaTNrD6NBPa3WmwTxRzOk6RjzIzKyxlkaMcM6/Kz4JICm/ce O9Pi8RW2lppmpz2k0Rd9UjWIW0B+b5HVpBMW+UfdjYfOvP3sQ23xBs5f7X8zQdat/sG77N5n2c/2 ljdjyNsp252jHneV99c4+ba/6/r7xdPv/G3+RyWr+EPE+reD/GOpDSfsuqa3rFnqlrpElxH5ipaG 2xG7qxjEsgtz0YqCy5bgmqHju28RX9n8R/FOp+GbvQ9Pn8CSWUCXd1byTGSP7UzBlhkdV4kUjDMC COQcqO1uPiRbxeHbbVE8LeIJ7uaUo+lxm0FzAPm+d2acQlflH3ZGPzrx97E+q+MdGudVXw/c6Je6 hpd7bsLm+aKFrNAQwMUiO4lbIAGFjZfnGT97EThzRsu1v/JeX8jWnUcGr90/uaf6HOaZa+IPGOp+ B57nwrqXh7TvD8g1CS5v7i1Z7l/szwpHEsEshwfNLMz7cBQACWO3EXR/GFz8JtY+G03w91L7RqL3 9umo3N5Y/YY1nuJXSZts7TYVXDYEW7IAwOtd5Y+PrAx6rGPD2sWiaaCtorLb41ALuwIAsp252rjz vK++ucfNtiuPiRbxeHbbVE8LeIJ7uaUo+lxm0FzAPm+d2acQlflH3ZGPzrx97GtRqbfZ3/H+raGF NOHK+qt+H9dTi/in4bv28a+H9D0q/V5fFmmnRfEAYkPJZW+JHufl/i2tLDk97hcHiut8SaFrOh+P bHxp4Z0karbLpQ0m/wBKhljhmMKyb4XtzIVjyhZwVZ0BU5ByoBtXXirw+njazZfD1zcStaNEdeSC Dy7ZCSxhYs4nwWRThEZcspJ4O2S2+INnL/a/maDrVv8AYN32bzPs5/tLG7HkbZTtztGPO8r765x8 22bvfrdv77/o36XduhVtLdLJfdb/ACX3Iw/GC+NPGehvar4Mn0e3g1TTZoo72+t2upfKvIpZXKxS PGqKinH7wsxB+UYG7l/FnhLxtrWpzJe6P4k1C+i8SW95DfnxAkOliwjvI5ESO0SYBnSIc+bDksrk SMdgPe3HxIt4vDttqieFvEE93NKUfS4zaC5gHzfO7NOISvyj7sjH514+9i7ceO9Pi8RW2lppmpz2 k0Rd9UjWIW0B+b5HVpBMW+UfdjYfOvP3sOL5Wmujv89P8vuuNu6t/XX/AD/I4nxzofjCJ/iZpmke FLnV08W2WbG8ivLaKGGT7ELcxyiSQSA5jBBVGU7wCVwSH+PfDOpS3Wm3Wn+GfGcer22nWsaax4Z1 q1t33RszfZ54riZI5UB5+ZJQQ7D5e/W23xBs5f7X8zQdat/sG77N5n2c/wBpY3Y8jbKdudox53lf fXOPm2wXHxIt4vDttqieFvEE93NKUfS4zaC5gHzfO7NOISvyj7sjH514+9iFG34fhe35jcm7J+f4 2/yRxmo+CfFq61pHifxLZaz4mvpNAt9N1RPDmvSaXOl1E0jmUBZreOSJjIwILAqQCq4Y7fRvhlpc WkeEorSHw/eaCrXE832O91A3twC8rMXkl3ybncncfnbBbGTUNx470+LxFbaWmmanPaTRF31SNYhb QH5vkdWkExb5R92Nh868/exDbfEGzl/tfzNB1q3+wbvs3mfZz/aWN2PI2ynbnaMed5X31zj5tt33 t/WtyXrv5fgrfkecfFPwvFeQfEiHxH8OJtUtNRllutN8QFdLkj01H0u0t3nH2q6ieNke3ZiflGEU 7u42vhnb2N18RbC88N/DebwbounaRqEVyphsII5bi5msShCW0z5YpavliBwqjPStnxN4z0nV/AU0 Go+D/EF/Fq0Utle6NHJbJcpC6ujF3+0LGFK/3JSw3rwCDt1Phn/zEP8Atn/7PSA7KiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOf8AAMOjQaFcpoN3NdWh 1fUnkeUYYXDX07XCD5V+VZjKo46KOW+8egrG8Gz/AGjSJ5P7C/sTGpX6fZtm3zNt3Mv2jG1f9djz s4583OWzuOzQBT1PS7DUvL+2web5ednzsuM4z0I9BVL/AIRfQv8Anx/8iv8A41S0vRvE0uh+Gf7Z 8WXtvq1hbQ/2v/Z0VsbfUpwqebu8yAsqFlfHl+UcOehxt07fTL2LxFc6o/iHU57SaIImlyR24toD 8vzoyxCYt8p+9Iw+duPu4AIf+EX0L/nx/wDIr/40f8IvoX/Pj/5Ff/GoLfQNWi8O3Olv438QT3c0 odNUkhsRcwD5fkRVthCV+U/ejY/O3P3cT3OjajL/AGR5fizWrf7Bt+0+XFaH+0sbc+fugO3O058n yvvtjHy7QA/4RfQv+fH/AMiv/jR/wi+hf8+P/kV/8amt9MvYvEVzqj+IdTntJogiaXJHbi2gPy/O jLEJi3yn70jD524+7ilb6Bq0Xh250t/G/iCe7mlDpqkkNiLmAfL8iKtsISvyn70bH525+7gAn/4R fQv+fH/yK/8AjR/wi+hf8+P/AJFf/Gi50bUZf7I8vxZrVv8AYNv2ny4rQ/2ljbnz90B252nPk+V9 9sY+XbNb6ZexeIrnVH8Q6nPaTRBE0uSO3FtAfl+dGWITFvlP3pGHztx93ABD/wAIvoX/AD4/+RX/ AMaP+EX0L/nx/wDIr/41Bb6Bq0Xh250t/G/iCe7mlDpqkkNiLmAfL8iKtsISvyn70bH525+7ie50 bUZf7I8vxZrVv9g2/afLitD/AGljbnz90B252nPk+V99sY+XaAH/AAi+hf8APj/5Ff8Axo/4RfQv +fH/AMiv/jU1vpl7F4iudUfxDqc9pNEETS5I7cW0B+X50ZYhMW+U/ekYfO3H3cUrfQNWi8O3Olv4 38QT3c0odNUkhsRcwD5fkRVthCV+U/ejY/O3P3cAE/8Awi+hf8+P/kV/8aP+EX0L/nx/8iv/AI0X OjajL/ZHl+LNat/sG37T5cVof7Sxtz5+6A7c7TnyfK++2MfLtmt9MvYvEVzqj+IdTntJogiaXJHb i2gPy/OjLEJi3yn70jD524+7gAh/4RfQv+fH/wAiv/jR/wAIvoX/AD4/+RX/AMagt9A1aLw7c6W/ jfxBPdzSh01SSGxFzAPl+RFW2EJX5T96Nj87c/dxD8OvEH9teFdGa9F7Bq76bBNe217HtuIZSi+Y smI413hiQ2EQZzhVHAALv/CL6F/z4/8AkV/8au6ZpdhpvmfYoPK8zG/52bOM46k+pq5RQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQByfhDxNpzadriar 4x8P6jd6LfXr6k9texFdPt/tEzQpPjHlMkKqrbgOY3yWwWNy48b+C7bw7beI7jxf4fh0W6lMNvqM mpQrbTONwKJKW2s3yPwDn5W9DXQUUAc/8NYdGtvh14at/Dl3NeaLFpFqmnXEwxJNbiFRE7AquGKb SflXk9B0rmJ/H40f4peItD1Ya3c2NvZWM1pFp+g3V6I2fzvMLNbwuRnauA57cd667wJP9p8D6Dc/ 2F/wj/m6bbv/AGTs2fYMxKfs+3auNn3MbVxt6DpVPRtAvLL4heIvEMskBtdTtbKGFFY+YrQ+bu3D GAD5gxgnv0oEznvBHjjUtQ8Lavrf9k65rzLr9zZ2dnb2SW1ysKyYQMk5iCBR1MhU+uTV9viXpMHh fVNd1DSdYsP7Gvo7LVbOeOIz2Rcx/vHKSNGYwkqSFkdgFz3BAwta+Hmu3Hh+6s0GlaisviifV5dM uruWG01C2k3YgndY2OAWVypR0JjAIIORb+G/w5GjaP4u0rV9I8O2Om+IbsyjTNHQi2gia2iiePBR ATlW+YKN2d2FJ2hQvyarVRX32jp89bv+nbS5t9Lv7ry/S1jU+IXjjS9CXUtLkl1aO5g0K51ea502 KGR7SCPADfvcpvYltgZSrbGzwDVDVvirpulPrUY8PeJtRt/DyRPq99DDbiK3jeBJhIS0qGT5GJKx qzDaflwU3YehfC/xLF8MvFuka7q+n6l4m1rTW0q3vsuEW1jhaK2V2K7s/M0jkA/NI2MgCti58Bax LofxHsVubASeKLUQ2RLvtjb7BHbfvPl4G9CeN3GO/FOXupuOul/Xsvu0fmOmoycVLTv5fDr+bRva /wCNrTT9UtdI0vR9V8Rapc2v20WemiENHbE4EzvPJHGqluAC25jnAIViOXu/iNeeKB4f0bwjFcaR fa5e39tNc30UbyWEdkxS4dUVmR5N+1UySvzbiGA2mr4tux8PfFdjr58QeC7ea/0WHTbiz8Qa6NMD fZ2Zllhk8qQv/rnDKVHVTkdDl/DrwX4gvPAuh+JLKeCw8SadrWq6hZi5hkS3u7e6uZiYnX78ccqm N1bDMuEbDYKmmo622v8Arp+Gr+dtdDO7su+n/pOv46fd6m58RtN8ZeGvh94r1KHx/qmqW0ehXbYv ba3iubeZYmKSQTWscW33DKx6EMuCDua948fw1ZNcX/hTxJd6XZWkU99q9utubeFCuWYh5llfaOW8 uNj6ZPFUPFWj/Enxf4Y17RNRt/C2i217pNxaQxW19PetNPIhVWeVoIvKRc8hUctnqMYbl/iN8Jtc 8St4ihbSfCWstqlisOn6lrU8sk2jstuIzHBD5Tqql1L+YjxtmQkq+wApf1+P9f1Y0Si7Xff/ANt/ 4J6tb+JLCfxbceGoknN1Bp0OomXaPKaKV5EUA5zuzGxPGMEc+nPR/E3S7vRvDl7pGia1qt34itnu 7HTbdYEuPJQKXdzLKkShd6DG/JLDAPOI9R8O+K7DxxF4i8Ox6Ldrc6LDpV4l/dSwmAxSO6yx7I38 3/WvlCY87V+YZOOcuvhnqcvwp8MeC9X8K+DPFqafp5trxNQvJrXy5cKBJbTpDI6cbgcKrcjDDBBn +vxl+lv62UbdfL8lf8b/ANWv2d346jttP00yeGdf/tnUnmS20Py4BeN5RxIxJlEKoowd5l2kMoBJ ZQdPwh4ltfEltdtHZ3mn3ljcG1vrG8VBNbShVYK2xmQ5VlYMjMCGHPXHmd38I9UudF8O3OsJofiz VNHkvCdO8QvJeWrw3MgfyRcypJLuhCoEmZGLBSCqhvl7z4Z6BL4f0u7t5PCvhTwys1z5kdl4fBMW Nijc7+VFuckH+AYAUZPWrVtf6/rT11623h9Lf1v/AMDt9+3L+OddNt8RdTs9X+KE3gfRbPSNOlhY Pp8Uc1xcTX4YF7uGTLbLZcKpHCscHmuT+GGv2upap4E8RaH8Sb3XLjX7lY9d0mW4064+x+dpt3de XIbe3jdHWW3AydudjDb1A9G1jTfGlh8RdR8R+HNK8P6naahpFlZOl/q81nJE9vNduSAltMGVhcr3 BBU8Vw3wsk1vxDD8OLGy0vRbfw34Ziju7a9TWprme6txp01rF8jWcOGYXCOSduAD8oPFSM9yoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOG uNb8XeGdD8J2mq2ema1fyW0cevXv21rfbKixiWWGNYCJNzGRgp8ocKOM/KW/ju7bxFcwXGiwR6Ks QNvdx3pe5kf5cq8BjCovL/MJWPyrx8x29ndWlrdbftNtDPtzt8yMNjPXGah/snSv+gZZf9+F/wAK AOGt/iBr7eHbme48MaZHrSygW9pHrDvbSJ8uWec24ZG5f5REw+VefmO2a58faqv9kfZvD1lJ5u3+ 1vM1Nk+y/d3eRiE+fjL43eTnavTcdvZ/2TpX/QMsv+/C/wCFH9k6V/0DLL/vwv8AhQByVv47u28R XMFxosEeirEDb3cd6XuZH+XKvAYwqLy/zCVj8q8fMdtO3+IGvt4duZ7jwxpketLKBb2kesO9tIny 5Z5zbhkbl/lETD5V5+Y7e5/snSv+gZZf9+F/wo/snSv+gZZf9+F/woA4y58faqv9kfZvD1lJ5u3+ 1vM1Nk+y/d3eRiE+fjL43eTnavTcds1v47u28RXMFxosEeirEDb3cd6XuZH+XKvAYwqLy/zCVj8q 8fMdvW/2TpX/AEDLL/vwv+FH9k6V/wBAyy/78L/hQBw1v8QNfbw7cz3HhjTI9aWUC3tI9Yd7aRPl yzzm3DI3L/KImHyrz8x2zXPj7VV/sj7N4espPN2/2t5mpsn2X7u7yMQnz8ZfG7yc7V6bjt7P+ydK /wCgZZf9+F/wo/snSv8AoGWX/fhf8KAOSt/Hd23iK5guNFgj0VYgbe7jvS9zI/y5V4DGFReX+YSs flXj5jtp2/xA19vDtzPceGNMj1pZQLe0j1h3tpE+XLPObcMjcv8AKImHyrz8x29z/ZOlf9Ayy/78 L/hR/ZOlf9Ayy/78L/hQBxlz4+1Vf7I+zeHrKTzdv9reZqbJ9l+7u8jEJ8/GXxu8nO1em47Zrfx3 dt4iuYLjRYI9FWIG3u470vcyP8uVeAxhUXl/mErH5V4+Y7et/snSv+gZZf8Afhf8KP7J0r/oGWX/ AH4X/CgDhrf4ga+3h25nuPDGmR60soFvaR6w720ifLlnnNuGRuX+URMPlXn5jtX4Wqiajsj06001 Fs8LZ2hzBbDKfu4ztXKL0HyrwBwOldx/ZOlf9Ayy/wC/C/4VJbWNlbOZLazt4XIwWjjCkj04oAsU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABWf4i1rTPD2i3Os6zdraWFsAZpmUttyQo4UEnJIGAO9aFeTftYRyP8ACG4ZI3ZY72BnIGQoyRk+ gyQPqRWOJqulSlNbpHp5NgoY/MKOFqO0ZySbW9m+nmdz4K8aeGPGcFzN4a1VL9bVlWcCN42QsCRl XAODg4OMHB9DXQV8p+L/ABldnxN4nOjXtlZRXniGwguNS0PUWie8tis5TM8jmONgqqCyhVB3bsis 3UPE/jgaWl9ceMtXS90vw9HdqbTUhJDNIupC3UybCUk/dvyeSSo3E8g+as1UU1JXavttoz7OXAM6 0oypVOSMuWylrJc0U9bJXV3a9lpa6vdL6+or5Ou/GHjOXxP4nnj8U6giI+rW8kJ1WJFSOKEtD5Nv kOjKy5MiDkd+Hzf8VXupad4b01/+Fh+LpdSvPDa66bd9WW1jikkVQT5uMyIWACW4Gcq2GBfnT+1I tNqL0OV8CVozpwlXjedtk3b16L520t10PphdS05tVbShf2p1BYfPNqJl84R5xv2ZztyQM4xmrVfL VzqF/beN38VSeJb+LWZ/ACanEzTIoluGhXMYTGCg+eUIBwy7ugrN0PxX4qbRLSxvvG+p22lahq+l xz3Z1qGW5t45Y3NwTMpLQrlAwV8bQCCCd+V/aiTs49/6Zf8AqHUnBTp1la0b3T3e/L3t0767H1L4 Z13SvEuh2+t6JdfarC53eVL5bJu2sVPDAEfMpHI7VpV5H8Forq4/Zkt4LC4ktruSw1BIJo22vG5l nCspBGCDgg5FeVL4++IeqWUcSXer2w1mODRbeVQ6tDcQGAzTA7hhm3TbiMHGORtONJZgqdOEprWS T0OOjwjLF4zE0cPUSjSm4+9vZN2ei10Tbt2fkfSemeMvC+opI1trVqAmotpn78mEtdLjMShwN7cj G3Oe2ateHPEGkeIYryXR7v7SlldvZXB8t02TJjcvzAZxuHIyPevmXxC9zrEFne634o1iGGD4iTWI ma/KraQYjPmKzZCGMAlW6Lk8Va8Lvqek+IoNZ03XtWthefEaTTLixS5xaSRMULM0eMFyGxk9gMYI BrGOZT5knHQ9KrwXh/YSlCq1PWyequujdle68lbzPpHVtf0nStU0zTNQuzBdapI0VmpiciR1AJXc AVU4PG4jPbNYZ+JnggT2UJ1sBr6+k0+2JtZgsk6MiuobZjAMiDdnbz14OOf/AGhR52l+GLKzB/tu fxDanTHAz5UikkyMO6gdfqD2rxbVtKi1/wAAfDXSNGSe2vIbbWmaMHEouoUWUj2LMgx6Bh0xV4rG 1KU5Rik7W/FpW/H8jlyPhnBY/DUq9eco8zkna1laNSXNs9PdS9VLVaH0jd+P/CNprGr6RPq4W90e 1N5fxi3lbyYgFJbIXDffXhSTz04NTaz428LaN4YtPE2p6vHbaVeJG9tM0blpRIoZdqAbySDnGMgZ zjFfNGiQ30l54u1/Ud63XiHwVfaq8bHPliS82qB7bUUj2P4V6JqGoeCdZ+EHgq0ufGthpWp6dHp/ 2S6icT/Y7xYfkEqrkIMq2S+ANp6YqaePqTUnotLq/rp17ehvi+EsJhqlKN5yXMozcdbe7ra0Xpzb O0tOjPXvCfiTQ/Fejrq3h/UY76zLtHvQFSrL1VlYBlPQ4IHBB6EGtavlO98YT61caTG2uf8ACLoZ 9VTVLvQ737JBf3UUCOs5YYDmRtgyRk7sDqK1H8YeOdP0m1efUry7uvHOjwQaYzTMn2a7V1hZowBi PckgkyuMsQfSnDM421V7dV6dvVpGWI4GrKa9nNR5r2jLf4mviSSdoxlJuy0W2p9Fa/rGl6BpNxq2 sXsNlZW67pJZDgD2A6knoAMkngAms7wX4z8M+MrW4ufDWrR36WzhJgEeN0JGRlXAbB5wcYODg8HG D8StI0Rfg5LpXjHWbmOxtrW3iuNSZXml8xWRVkIUFmJfGeO/NeO6p4zvpXOhTeIrC2uP7f0+y1bx PosscLX9o6uUkaZejIq4POFwRyMitcRjJUaiTta3zvr56fd3OHKOHKWZ4ScqblzqTV/s8q5dbcvv PXVKSabjo0219Fp4g0h/FL+GFu86ulp9ta38t+IdwXduxt6kDGc+1alfKeriS+8RahqOmeO9avn0 zwbNcW+r2cjWst15N0yKkh6so6E9XKBs803TPGvjXUfHOmSnxReK6DSleFtRhghkimtwZ/3DEebI xfIZQSv1KYxWaJO0o7vSx6U+BZVIc1GslyxvLmTWum10mk77NXWzu9D6uor45tfEnjG28Kf2lH43 8StN/YqaxiS+Mi+empm0C/MCfL8tiSmcM2CcgADsrjxVqy/E7S7uw8Y6zeNL4qi026glvEithGxV XiSzwdwUNtM2R8wzjcwanHNYSS919PxM6/AWIpSklWi7cy2e8bXT0st+/on0+gPFPiDSPC+jS6zr t39ksYmVXl8t3wWIA4UE9SO1Z+heOfC2ueGL/wAS6Xqn2jSdP8z7VcfZ5V8vy0Dv8rKGOFIPAPtz XJftS/8AJGdT/wCu9v8A+jVrzf4s+IdXubKw0m9+JFlqVhdWuqST3GjSxwRSPHa7oreQqzBtzkAo T8wkAxnBrTE42VGo1bRJfe213/Q5ck4ao5nhKdTmanKc09dFGEYydkoO7abteS6WT1t7lpfxA8G6 lBeXFvr9qkFlHbyXMtyGt0jWdd0RLSBR8w7ZyOhwa6evjvVZ9R1L4X+JYrrWNTa10q18PtbWv2lj CA9vhl2HIxkhsDHzKD2rpdX8VaxZfEpbbT/HWqXMFnqek6bZRG/WRLyzmgfzZnUDErHCHzexkBzn bjCGaP7cfu9Zf5Hp4rgWLbWGq2tdtS1+zSa1SW7qdtF3s2/p+ivL/wBmmG/uPh1beI9T8Qa3qt3q u7zEv7xp44fKmlQeUG5XIxu5OSB0xV79oXxNceFvhje3llMYbu5kS1gcMAwZskkZ9ApOMHofqO9Y lew9tJWVrnyc8ln/AGr/AGZSlzS5+S9rK97P5J3+4yviJ8dfCvhS8n060jk1q/hJV47eQLGrjIKl +cYIIPBI44NcP/w1F/1I3/lW/wDtNfOFfSfwY8LeB9W+G+g67rdhppktzc6dc+bGgM8lxcqsTsSv LKpIU9s8HjjwaOPxeKqNQko9dkfrWY8JcP5BgoVMTRlWbfLfmkndptaJpWbVvmR/8NRf9SN/5Vv/ ALTR/wANRf8AUjf+Vb/7TXYt4I+HlpYW9pdaVowbwmkdxqE7QIDeBbdwRKdvzAuVYg55HbpUn/Cu Ph/9n/4RL+zNL+0eZ/aX23yU87yftXmeVv29PL+TGfu9u9dfLj/+fq+5f5ev3HzzrcIq18DP/wAC nt3+Ltyu395HFf8ADUX/AFI3/lW/+00f8NRf9SN/5Vv/ALTVH43+EdATwhYSeDdFt7q+8Q6qt/aJ p9sHlS3+yndFGEXPl7gXwOOvHHGl4L8NaRc/DHStauPC2jS+K00G9ewtHgi2XqKyCO4kjK4aRQRj Od24knJG3D2uO9o4e02V9l/keo8Bwt9Thivqb96XLZzkmnZ6v3trppvpa+xH/wANRf8AUjf+Vb/7 TWtrHx/1nSNH0rV9Q+HXk2WrI72Mv9tI3mqhAY4ERK43D7wHWt7SPD/hJja2kngvwzILfTdHuBI2 mx73e6llhk3nGG+VARkfeOTnjEmoeH9NkufD2nL4UtdTsrKPWIoDNEs8VgBOio5gZgZlGANqnd6c 10JYzlbdX00Xe3b1PHqS4b9tGMcC0k3zXnLVcjkrPnVn8O976pK9jh/+Gov+pG/8q3/2mj/hqL/q Rv8Ayrf/AGmu3sPA/h03Eum3Hw/0ERXuuT2155UHnm1t2s2lDxzbVaPMgTHQJ5m1cfKa4XxJofg0 +DtQ+Iel6DZy/wDCS6XDpuk6ZDaIRDfSFo38pBwHUoCNozkNjkms5yx0Ff2q69F0+Xp9524alwri KigsDLXlSfPJq8nZLSemik+1o3vqP/4ai/6kb/yrf/aaP+Gov+pG/wDKt/8AaaofDXwwsHwohlj+ G9p4m1m71ubT9QtruPy5oolikziVv+PdlYAbuME4+8QR3mm+B/Cp03TLd/Bmki1trbSLmG7azy88 008iTo8h/wBaAmw7WzjeCf4cTSnj6iT9pur7f8A0x2H4UwlScHg2+WXLpUeutr257rXa61V2tmly X/DUX/Ujf+Vb/wC00f8ADUX/AFI3/lW/+01seKtE8LXPh/XGXwd4etZn0fX2WW2shG0bafdeVAyY OFYiQlyBliF7ALXyxXNisZjMO0nUvfyX+R7eRcN8N5vCco4Nx5XbWc33XSXdP8z6P/4ai/6kb/yr f/aaK+cKK5f7Wxf8/wCC/wAj3f8AiH3Dv/QP/wCTz/8Akj9HqKKK+0P5nCiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAqC/s7TULOWyv7WC7tpRtkhnjD o49Cp4NFFDVxxk4tNOzRnL4U8Lrp8mnr4b0YWciqr24sY/LYKzMoK7cEBnZh6Fie5pZ/C3hm4TZP 4c0eVfsyWm17KNh5CEMkXI+4CqkL0BUHtRRUezh2Oj65iL39o777vfv+A+Xw54elvLu8k0HS3ub2 Iw3czWkZeeM4yjtjLKdq8HI4HpRdeHPD11HbR3Og6XOlpCbe2WS0jYQxFdpjQEfKpX5SBxjiiiny R7ErFV1b33p5vtb8tPQk/sTRfMspP7I0/fYRGGzb7MmbeMrtKRnHyKV4wMDHFQR+FvDMWkS6RH4c 0dNNlk82S0WyjELvx8xTG0n5V5x2HpRRRyR7AsVWW03979fzbfzL2mafYaXYx2OmWVtZWkWfLgt4 ljjTJJOFUADJJP1NV00DQkeF00XTVaGdrmJhaoDHM33pF44c92HJooo5Y7WJVeom5czu99d/UY/h zw89hc6e+g6W1ndTG4uLc2kZjmlOCZHXGGbgcnngUL4c8PLt26Dpa7Lv7cuLSPi44/fDj/WcD5+v HWiijkj2K+tV9ud/ey1dabp13e2t7dWFrPdWZY200kKs8BYANsYjK5AGcdcVWtvD2gWt3HeW2h6Z BcxzSTpNHaIrrJIAsjhgMhmAAY9SAM0UUOEW72JVerFcqk7bb9NdPxf3sG8PaAww2h6Yw+xiwwbR P+PYHIg6f6v/AGOntVaHwd4Rgsriyh8LaHFa3JQ3EKafEElKEldyhcNgk4z0yaKKXs4di1jMQlZV H976bHm/jrw9oC/Gj4daGND0waU0Ook2QtE8gnyS3+rxt+8AenXmn6haQah+1Jp9teK00GnaD9ps 4i52Qy79u5VBxnH8h6CiivMlFczVvtr/ANJR9zRrVHQpycnf6tUe/V1Kib9WtH3PXbq3gu7WW1uo I57eZDHLFIgZHUjBVgeCCDgg1lxeFPC8WlzaVF4b0ZNPmcSS2q2MYikYYwzJtwSMDkjsKKK9Rxi9 0fBwr1aatCTS30fVdSQ+HPDxznQdLObQWJ/0SPm3GMQ9P9XwPk6cdKE8OeHkvLa9TQdLW6tYRb28 wtIw8MQUqI0bGVXaSMDjBIooo5I9ivrVfbnf3sg/4RDwn9n+z/8ACMaJ5Pk/Z/L+wRbfK8zzfLxt xt8z58dN3PXmpm8NeHGvftraBpTXXnRz+cbOMv5kYxG+7GdygnB6jPFFFL2cOxTxmIf/AC8f3v8A roW9V03TtVsmstUsLW/tXILQ3MKyIxByMqwIODWafB3hE6cNNPhbQ/sQmM4tv7Pi8oSEbS+3bjdg AZ64oopuEZO7RNPE1qa5YTaW+ja17kn/AAinhf7LPa/8I3o32e4WJZ4vsMeyURjEYYbcEKOFz07V Inhzw8l5bXqaDpa3VrCLe3mFpGHhiClRGjYyq7SRgcYJFFFL2cOw3i67veb+99rflp6FvTNPsNLs Y7HTLK2srSLPlwW8SxxpkknCqABkkn6mvHf2yP8AkmOnf9hqL/0TPRRXJmCSws0ux9BwfJzz7DSk 7ty/zPkyr1lrOsWVk1lZ6rfW1q0yztDFcOiGRSCr7QcbgQMHqMCiiviU2tj+oZ04zVpK5K/iHX3k vpX1zU2k1BQl6xu3JuVAwBIc/OMcYOaf/wAJP4k/tH+0f+Eh1b7b5P2f7R9sk83yv+ee7Odvt0oo queXcy+q0P5F22Xp+iGxeI/EMU1jNFr2qRyaehjsnW7kDWykYKxnPyAjjAxxTofE3iSG4tbiHxBq 0c1nD9ntZEvJA0EWMeWhByq47Diiij2ku4PC0HvBfcvP/N/eyRPF3itG3J4n1pW2Rx5F/KDtjJaN fvdFJJUdiSRR/wAJd4r+1Q3X/CT619og8wwy/b5d8fmHMm07sjcRk4696KKPaT7sn6lhv+fcfuXp +Wh6VqGr6tH+y/bXUeqXqXF/4lljvJVuGD3CvFKXWQ5y4Y8kHOe9Xf2jNRvdK0zwHpmlzmxtLfTY r2GO2Aj8ucYxIpXBDDrwevPWiivVqSfsJO/2YHwGEo03mtFOKt7XEdOyVvu6HkUXiLxBDHfxxa7q kaaiWa+VbuQC6LZ3GQZ+fOTndnOTTovE3iSK1tLSPxBqyW9lIJLSJbyQJA4BAZBnCkBm5GOp9aKK 8r2ku5+gvC0HvBfcu1vy09Ak8T+JZI3jk8Q6s6Ok0bq17IQyzNumUjPIdgCw/iPJzWTRRScnLdl0 6NOn8EUvRWCiiipND//Z ------=_NextPart_000_0099_01C3EE52.8F3F86E0-- From owner-voql@eso.org Sun Feb 8 17:24:33 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 i18GODnX026706 for ; Sun, 8 Feb 2004 17:24:13 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18GODuf026705 for voql-outgoing; Sun, 8 Feb 2004 17:24:13 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18GOBnX026693 for ; Sun, 8 Feb 2004 17:24:11 +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 SMTP id i18GO5WR001279 for ; Sun, 8 Feb 2004 17:24:05 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 27A261C000FF; Sun, 8 Feb 2004 16:24:04 +0000 (GMT) Message-ID: <402662AC.7070503@dial.pipex.com> Date: Sun, 08 Feb 2004 16:24:12 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ael@star.le.ac.uk Cc: voql@ivoa.net Subject: Re: Adql.xsd References: <009801c3ee52$8f3f86e0$6124d28f@STAR.LE.AC.UK> In-Reply-To: <009801c3ee52$8f3f86e0$6124d28f@STAR.LE.AC.UK> Content-Type: multipart/mixed; boundary="------------070206090607010806060701" 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. --------------070206090607010806060701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tony Linde wrote: >>As a 'temporary fix' for examining the schema, delete the imports. > > > That just produces an error on the types defined within the namespaces of > those schema. yes - but you should be able to work with the rest of it, or? >>imports) and start from the WhereClause or TableExpression. >>This gives you a >>possible-instance tree but I think that's what you want anyway. > > > All I get is as attached (.jpg). Hmm. I get the attached. I've working with XML Spy 2004 release 3, working with the adql schema given at: http://skyservice.pha.jhu.edu/develop/vo/adql/doc/ADQLSchema.xsd -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org --------------070206090607010806060701 Content-Type: image/gif; name="tableexpression.gif" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="tableexpression.gif" R0lGODlhQALgAfcAAAQCBKSObMTCxPz+xKTK9Pz6/AQGBISChNTOvPz+/AASEwAAAAD0AABk AAD7AAB3wAAAAQAxBAD4AAB3AAD/cAD/MgD/aQD/AA3MoAC+vwASEgAAAACCAACWAAD8AAB3 AGTo9L0GZBIT+wAAdwDwYAC4QAATAgAAABbw/ya4//sT/3cA/wABAAAAsBMAUAAAAIjw8GK4 vhMTEgAAAADNnACr+QC6EgDcANRoqL++vxISEgAAADcw9LZHZEvh+wB3d2ZBWAAUFQBy+ABx d+yK/78K/xIB/wAA/8APuL8AvxIAEgAAAHIAKXIAG04A+QAAd+UAAP8AAP8AQP8AAACQ6AC+ xgASUAAAAFiKnLVVv0vhEgB3APBwAPAyABJpAAAAABsPpwAADwAAWQAAfOwAAL8AABIAQAAA AMCa6L9VxhLhUAB3APAAnPAAvxIAEgAAAAAAAAAAAAAAAAAAACAACAAAwAoAEgEAAHAAfRYA BPgAAHcAAP/oIP++AP8SCv8AAdB/IL0aABL5CgB3AYwAAToABFgTAHwAAAACAAAAABMACgAA AQAAAAAyAABpAAAAAGAPB0wAABQAAAAAABYAZAAAwAAAEsAAAJABAGIAABMAAAAAAADkAAC+ AAASAAAAAH6MAAAUAABYAMB8AAAAAAAAAAAAAAAAAP8A/P8Av/8AEv8AAP+QG/9iAP8TAP8A AADh/wAb/wBX/wB8/wDHGwAUAABYAAB8AAAE8AC/8AASEgAAAADgAAAbABNXAAB8AGsADAAA wAAAEgAAAAB9rmIEgRMASwAAAIgA7DQAv1gAEnwAABYgcwAAcgAKTsABAAEIIL7AwBISEgAA AAAgAAEUAABYAAB8AHQ0r72lwhJOEgAAAJw84/ml/xJO/wAAf5zglPkbwhJXEgB8APQE8GS/ 8PsSEncAAHAAABYAAPgAAHcAAP+A8P/78P9PEv8AALAA974AExIAWAAAfIS0rxsbAlhcR3x8 AABolAAkwhNXEgB8AAD/lAD/wgD/EgD/ACH5BAEAACcALAAAAABAAuABBwj/AAMIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEM+BECypMmTKFOqXMmypcuXMGPKnEmzps2b OHPq3Mmzp8+fQIMKHQoTAYAECQooXcq0qVIATp0inUq1qtWrWLNq3cq1q9evYMOKHUu2rNmz aNOqXcu2rdu3cL8aTSCgrt27eOsegJq0bwG/cQMLHky4sOHDiBMrXsx4sNECeSPf3Ru1aePL mDNr3sy5s+fPhOfWJWmgtGnTJPXy/csaMOjXsGPLnk27tm2kj+sa2ApAdWWmt4MLH068uPHg ogUc1dpbAGXArf8en069uvXr2MPmVg7gtHcDzSn//1aavbz58+jTd06+PGv41dD7qp9Pv779 +9qh6ubte7x0/AAGKOCA1bHX3Xeo+RZfawQ26OCDEHK23W7M9TdehBhmqOGGa7FHlXICUPVe dPFxaOKJKKaIm37cgaeci92l5hxU/qlo4404AughXSeFmMCIC8qX45BEFlkgi+1B1puIFv5m 5JNQRimbgSWB2OOMJJIo5ZZcdrnYdnk1l5d4F3pp5plodniUZGLi9VyWQqYp55x0agWmZGMa 4N9/dfbpZ5pGHSDooIQWSih8cP6p6KJcGhUjeJA+KimkezJq6aVDPhYknJy6JuAAoIJq6KiF hhoqqageYKqoqY666gCtuv+6aqyGvkprqbPeOqitugrKa6+/6hrsrcPSWmysx7aabKrLotos qc/Kamqqj+1prVSfvqrtttx26+234IYr7rjklmvuueimq+667Lbr7rvwtqtpp/QGOaCq8ear 77789uvvvwAHLPDA5lZ77cF84ocvwQw37PDDEEcs8cTxzrvpxYkKuDDFHHfs8ccghyyytgYj bO29I6es8sost+zytxbXK3OcAG788s0456zzzvmWbHKNGvMs9NBEF110zBgnnbDCRjft9NNQ U+zzz04GHfXVWGetNbtIz1wvyrkSqq2v09p8qtgBk7312my3TXJ7W5rNKrdqzz223G7nrffe PcP/LSXede8KK9pkE76xr4gbXrjgg6ttOKuLM8735JSPPFeXgC+Mb+Jzcz5445x77vnnny9O euibq2p65ay3LrXfUWZetuiq1y523Y3bPXqtaIN+9um12+368MQPfDmXsncefOnL/z677s3j Drnmu9IOfPHYZ8/v8XFv63jwplsfOPipk359+OWLX7727Le/Lvd/e3949Y/7Djr59wtv//71 94+3+wAM4LbgF7uISU+ACExgxAgIpf+lzYEKjKAE+8XAJ03wghjcWgWNlMEOerBpGyzSB0dI wpyFkEglTKEKU3bCIa3whTB8nZdiSMMaEqyFOYKgDXfIQ3ThEEc67KEQ/4forR/eKIgr+xFJ plISJi4RKU2E4hOV2J4oUtGJVZyiFbeoxS4CgIg9NKKNkKiy+oCRh2JUERlTRp8vntGGaUzR GkcGu/K48Y00jCOK5iiyOmanTXh8oR5PxMeQ+XE6LQmkCgdpokKCzD0mUUsklRiYQ95RkSNk JIcc+TFIsuWJS5ziW+BGSkyWUJMb4qTHPInF5UxyJVK0CihnGUsqZlGUIsolE01JQlRqSJUd 8+NJKFnLULrymMQU0VGQSctmIlOWuoQiLzN5yCIB818lCVU2QTVJWZIyi7GkJSVxScxIOtOL VsxlSn40zQ/6MkPX9NcluyXMbzoxnM80pjfHuf/MZ9oymVghpYja6cF3Yiie/Zont1hZy3L2 s5j5fKg+nYnPhkbzRwMlaAYNGiGESoyhAH1lRFsJ0VlGsZvdrIpAd6lRDHIUQh6N2Hks2VKX VpNIMYXYTYuTyJpO8KUPUplCt7VT6gDSpz8tKo6EGi6lHgcydkFqUmeYsqFqqz53kaoEgeqg otEHqnXRagS52iCvlmQpZ30KSdC6VrXSqABphWtb5frWuNp1rnetK15lFFaxJpCsBHoangZL 2MIa9rCIzapfEQhYsPWxXImNrGQnK9nFMtapY6wqZCnL2c56VgCWFWBjrfZYcn32tKg1bGgD ONoA5XS1sH1aa2sW29r/Ym+2TLOtbluH2/u8Nl5W3a1w39Vb+/wWXsEdrnLVVdz6HPddyV2u dMvVXPo8d7rY5Vh153Pd7HoXYttVT3fBiKvZCSts5zUvsdC7XvUai73vdS+y4Dtf+SqLvve1 L6nCm57xriu62vPvdx3GX/QIOF0Azt6BB3xDzKpRsxFcMIMFVuDzSHiHF57wvypsngzX0MMa 3p6D5ShdEIdYXxwuD1MjfOKjjRhFK1agiVsMrxRnJ8YJnDGN3WVj7EzXZo472wF3vMAXn+jH uYLc9IjssR5fB8lJpl/+lmy/3jGZuEZuJIRlzCtYeVl9ynPekK/swyxvcssZRNyXl5e421HP /8pkfp+ZU4lmDLoZzGVzXpxrPOdfTvh70Dsf9fS353Q52To65iGgr1fl+Y250OQ6dHUSDekr S5o6lKZnpb176elkmlsJxt6nN13EPsOzzgIcNam51enjqPqDr171q1ptnFh30NayDhWti4Nr O+facqY+KKoD2Otc75o4xQ518Yot62MPJ9kSZPaqnS0cabM4hVjMthRvqe0rbrvbXOT2t8ft 7XKHG9xexGK3qB0ca3M5hcF2UHLZfRt351iF8W7QvPMd1GED0N4u43dgWS3wsvrbfQBvWZcU ayp62wbHCEw4y57UU10XfODLlXgSA2pJwfizKyk1CzlV6p5VObw2UP8uYT05XskXi/MsI79o KRt+8QGlnIQrH6ZITXpMdGbbnD0P+se3Le6dE12YMjd5zUlryGjjm+UUdWgyoz7Rh/Kzovzs YjixfvWXyzyjFvcStH/Nrm0OwOzpVKnV9WlLtv/z6FaHqNRfDvSdx12UXmdi20OpdLEfnOz5 8iTV/YZLoKtdmVhne+HjXlGt3xOgeo+8NGnud8CzTvDMHKnjFS/RtXt+7plv/N07b1HJY5Sl Ycec5bEW6pyP9O14D7e4rw77iPqc6CEV58hXOvnUI2/1V2u9kWhKedXTEfjoEn6RKg6qk9Nm 7O8uIZfACtq+G7+00SfhwqNq/d9nXIVcOmr/8b2vXI0/TPlREr/vu/d9BLZ+OXRlq17nL//6 u9X+8b+//vPP/7zi3//7Z1cMt37xc3zXJkDKFiqptYAM2ICFNWtL51p/xz7m1zIOeIEY2IAQ WHnYd28wlIEgGIKctYHXN1wVyDIimIIq+IDdx37ll0AJGEPONxsnGGAwiEkzKBsQl2o3qEg5 GBs7SGzIp10RCCBB+G9DKENdcnNJ+DA/CBtM6D4xCENP+BpR2D5TKEhFmFsdGHE9+C3pRm7n JoZhaG5lOIZmOHtmR0Fb6FsT2ITJZ3D+UoWgAX1w+C5dtWFtaFx36DZ5OId76Fx9SDShpm8D WDGBaF2DODToVx/M/8dnHNh0i+gtjehNeVcWPCdJN0V8fROJIJOFrFODhsRKbgdzn4cWMWd6 M9eJJfiJTodtLHd4bzeLKGV4aheGRtd2AZV0KJaI3FVi4BeLiDd4oIdPm7dMXFd1pQdFvMiK 5GeCMEgS2iSN3JSK5MR5tKhz/lR3J9VEjid30LROoAgudPgZoihqX0iJwnhPdOeNhDd0pdh1 4PR4u9eMiOiJHzOOlHOOAlOJiCePifd5xEhRbqeMkMeMqrgv5egZduiF8MYc3Yh7EpmN3Xh7 /xR7r0dyCdmL+Ogx+jg5/LhK+MGJ99iKuxWSHQMgj4hlHWlbKIlN4WKI3MeRJqlbLylPTf9F IOpXklxyhAiXjvSkk4cIiUv4hgr2dANCfSJGVQaYfSOERf+3V/QXgFIZlVPZf1VJlTQylCxZ lO33QisYlpG1lF75gu63WWKZloRFlj0JjGdpWmoZl5LBli4oiU4phWgpl3rZVzT5jK44iVK1 kJ3RkICpUYLJGTdZmEJ0mJuRmMj3kb3ki+KlmDkDmdTUkhxjmWSnmQUlmf1llOhImQDDmJpB mEIomnqImbHlmBGjhmf4mq4Zm+gmm2TImTDjmQbmlgiYkzY3mrhpYboZQP5oH7ZZaqo5McXJ NqypL4U4IMlJcMcpMc+5Ncv5MEI5k31Zl395lx40kixBlwVolir/x3FpxxuYFXKYuIklp5C/ 2WHBCUDDKXWjNHRkkYoIeZ/sxJ7RGVrVCVy8uU8OhU6ex3P0WYtBN27DdBW8l5/ZKSU+2T79 iVwxGYvYSJChl3XzGErJSHoHeXr4OZ3N154qBprLFo13hHbWaHcVKpDb6I52N3X21KH9pHPg GSUPSoHBqKCnSI8cio3D+I60l3vL6KFECqIDQJqZcYUdtHK0t6LF2KQsGqQGWY8b2aA2+p54 CS5MiqGtNKCvZ6C3xHgRKaP2yJNboqTaE59eMY+yQZJmGp526YG7CS6oWJ6vsZJd6Zf5iJrn cp18aaUNRKJ8aioNwpV5qp2DyohJaag8/yai2RGhv6am9MGo8uKo2AGpuYZ+AIiVV7mpnpqV nGqV8kepXGOp12GalDmFe7mqbLifOvWKYLmqetmqNRlMsLpCsjqrNRqoX4mruRqXtKqnNgmU Z4SkmIGpbYOsZYeDpopogjo8yvpfzOqq53erifqmBdSUcnqt2Mqr4smtRCmsLkmsYGSslxGt 1EmuRGSujXGjNviWaVYr+FUo7MoY7nqU4DotpcqUXciD+Xoq+1qW0PivohKwbdmr8OlB8VSv i4Gm2WOkyWqwiOqR1pqlaSaxcLqdBFuxBdOsk/asG0s8C+uxmBayDisuDKsY6FppEKucXTYu KZsYKwtpLbs2Zv/zaG9DrQ5Ts2TGs3rTZujDKjGLGKj6kyYbZemDP0N7GEULoUeLtGHWZktr GDOLNVVrSmDGOVNbGFcbNV1LLj6bN9aTO5+ztYTxtU+DtuIStm4ztowjKGY7GE2Lo/Dqa3Km sw3DtkajtoqGsdnar9tSm7M5uIJbuGlIuGlIN/SkE8DFuIo0sngrMr05NqCWFrZpanr7rsxF sp5GiNlCudoSb5opuuqSuVADubV6M5xrGIr7KvwGma+LYArrt1Byr2cXIDtpNgWnj7ubfLN7 twKrsd1CnN8JsKZSc3iqTV9hp+SpEjSEugcLuFe1i/eJnvU5pnBBkjaDvOtJVCB3RQn/qqDd +0LQe6ZE4x4IyrxhEXXZO77bGxduuio71XMaKb4B9bwYSxT6u78qkRWU6LgA43qdJ3sSKVIA OqaZOJH1K0v6erzwO76uyxsSTL0KqmngQgAEUBIYnMEkscEajMEfzMEA4MEdDMIlLMIkPMIm rMIovMIp/MIuHMMi3LpEVRSEpyKHFJSoGDA5h1FOKqUXOowB+aRUWsHGq7yQRL/lZr9G7L3o 2234ucAqZcHfssFWfMVYnMVavMVc3MVe/MVfTMMR7BXws7qfcUh4Q7oIRo1nx8bWO04+zKK2 uHcHmYnnFKb1KI4toUw5oU4osXd/3KXvOKPrpHd67MbS2Hpg/7zIjNzIjvzIBCDGDiwXN5wi R7E0CSA3seu7dNq8FxnEDbV4+zSlYdqhFzXFlZvE6VtN8TvJIFd4T9zEodtUkFzLtnzLYCzJ 3JQfUswhbVIVujtKnPwtEMmjQ3yMcqeMA0mfRIrKTjxKECy/MBfLDAxqtIzL2JzNt5y7YwwW ZezLLEEV75u9xasuxQyOCYyR36R7FZnAs9jLqBe6D3y/qfzKlczE1awu2rzP/NzFzDfOvHzK gqyjsmiJ9ukWB80c1AzQCB3N5mLG0EzPz9zQEi3Pa2pM6tvK5bLFJ9zPWmwS2dzRWay90iwW 3wxSBT2kpgwbHTcVDN0WGg22jljOFv/tFnTlvPXMFepbFTedEuzC0Szs0VhcwiINyUV9xSTt yt58zwStbQmazvaE0VBtkQZce8zb0kjx0p/k0Nr0n/exkzX9SXgh0wg91mt7zUM9widhwhy8 wioM0iLMwnBd1HDdwnNN1HWN1Fy9yybN1AB6ek56x6THvsssekMMTRScySVNnqus0BXtuhOq koeoyWwBV3lRLvlm2WbdVGiN1Gr91p/d1njd1mwt2qAd1yTM1qd9wh3c2qc91Ht9u6p8RSe9 jrZYdXOcvhvKjSR1zMxMyC4KS4JcE36sjYj8Rc0p2djpZWENc5Hx0GvRJsv9vyd63EFtxa6t 2qGNEqSN2m7/zdoazN2oDd7Y/dp6fcjCDXcrUdtNDZDu/XhOHcS7R8A/XMSIndWLraNKvNMx fXaRjR9K2cDNXZ9zCd2oWODwAtSknd3ZXd6e3eAjHdoODuEdPdqw/dj5bYnfxt5/TcpQKqQ/ TMRRSoz3XeJaHd2x/X6XHKpaKaot/uIsHuNpNdmLmxMI/tA6cePvouAW/sGjTd6mrd1CHuQU vt3mjd0pPhYcntLcaHtCJ4/YS5GlHKAZKdCmd+KSFNvm8qtpOSve4oDrAub6wuOvHcJ3Xd7g neZybebhHdQ+fuQCAMJJ3tfwrBgJnRhYrdhKDdNanpdcnoJe/uUL2C4M+NCdjcFx/77BiY7o VrzoBODokN7okq7ok87olH7plp7pjz7S7pvhZOzXjHHniLHHLu3patHTKAEvfx6WgS7op/Uu qXUuiqzpQl3rtfzPps4VS74hbcInwVzWpCq/fr7qINjqrt5Z8fLqsn7ott7s2MzNuW4noM7r dwHMA24Wmh3sx8uxHeTs3q7N0B7tWLHrGtLr4jzRzn3ZZ32AJPTt7r7NNH7tWUHuGfLL547u BP7cMcS3O/7u/v7I8S7vVlEAZcy/Bs+/d8En1I0TOr5C/A6GTZXmMNzCFM/ma37xE2/xGS/x MvzBAR+6NowV1EfsXF4V3yLm+Fu34ULyamns2nJYG8Tyq/9u8ic/6JjN7Wk67DIfgi7/8oUV 8zv/qzRf88p+8+yuQkG/gj3v84MF9Em/qkNP9Mi+7EefQk8P6AJ+7JERt4JxsqhZvhl7kurK ndQF0cj2tJn5u5sbuQRjuifm9k4D9n8bp2iPhMArrmlf9/669qmr94sl997q9zurQr1CNlwf GA9PNIlPxXh0+HExt5ornNPa98iJ84IPnZQvnZZ/+Tmb+fzJ+TBr9s+GpVg4+Xi/mmO/mKJf bSDbOotvzT64+u3W+qEI+igr+/VG+5Xz+j7l+HDB+zsD/C3l+2/h9cQD98VD/G5h/MOj4oiL htAPm88v/YYbbrRrQbq/j6lPqCj/YpnK3xa2W6KweCLej/sPl/0gmaNHdvfmi7AfZP6Noe0D BP/PR/rsI6kCkry3yfa2L61a2rwAASDBQIIFDRIEIDDhQYYJBDZ0mPAhRIoGF1KceBDAAI4d PX78iCBjRZIlTZ5EmVIlwwMgXb6EGVMmzI0zbd7EmVPnTp49ff4ECrTmTIgXL548WjKpxYdL V0asmFFqT5FPrV7FmjVly6BdYw71GlbsWLJlzZ6NWbSpQokDJU58y9bt0bZv5xodGZEuXr53 nbotOJVnVa2FDR9+yhVtULCLHT+GHFlyT7VzoVqGijez3LWXNdvFvLDz3s2YLQYOTDUvYtat WyueHFv2/2zatctK7IibI2iNoPfa/Sw3cN21vIHH9XtZuefVbJE3xknY9XTqhWHbxp5d+/ba 0F+uXq58afDlooX/tTyeM1ypnTWiRqi6+nz6K69zx58f5339+b27BE89hEYjsDTzmEuvQAOF W9A0+ACLbzDw6qOwwoH4w++//vLDcEPtNPyosuGG++1AvQbUTC/2SkSRwRMRfA+h1CS0sEYb E+hwOxA91C5HHn8c4EYhUZpwR5ikGzLJ1340EkjafHRyQyWnbCguK+WjMkutoIyyS8m49JK7 CbVUsgABzhTAJyTJZBMlMMOE06w34zSryQHGbFNINNPEMk8/SZqTTkGDCnTQsP/sxPPPCgHY U81EFc2z0NjsNFTOSie9CVIqGUXTUU0/LUjSySi9dCxRS13srgJWlWjVAlplNSFXYX1V1lgB mNXWWnG9NVded/U12F6HBZZYTs/0FFRQT42MVFS9YvbZxfaktlprr8U2W2235bbbbZNVVtNo pZV2XHLL8jZddddlt91qwQ1X0XPn5clcer/byV199+XXXXjj9fNegW2yd2CPnB2gX4UXZpja fwFuE0iEDb6pYIrvvNjJNSFmU+KMTf045IE35lhLj0XuymKUV96O5JKpZHlglWOmeTaXX1Zy 5pq301ngiXc262ach+wZaKOd/PlosYQe+saiD1U6aqj/pbb50aYrfNqrpKnmumvZmL7awqy7 2tprs19CMe271H6x7bbWhtvt39h+W6/awA6bwrHP5lvHvKO62+q/q9u7b8Nvu0nwocsGCu/B CT+8y8KfRfRxiAK3nGgmI+doclTtzLyhRidzPHTWPO+J8ZVRz9h0K+MiXXHTDWN9J9VRrp1i EdFDr8q6seodQoZuj0722bfk3MncDQ7QPeCdvyp4hx50KPbjxU4eyOUFrXx4At/mq7gUSVwx uReRG5564m8q/Xrks+dxezq77y1B+8nbjLTM7L8fehn/d4v13Fcf+dlkfR8rIJx0c6eE5KZ3 +DsQBFfkHPARZ0AjCg9gXlc9/8m0b4BXSaBMDpixEJ5rd+dZD/8EtEIGJWV86ptRZDz4wcRs jnMlJNcJEWQiHqJwhynsn4MAOL0IydB4NFQJDuHnEiVSTi0p6iEUxdciKrpQiukb4ghlMkMk pmSJ8Tsc/R5XJAF20TVf9FATTzaTIyrrdW8poxlZs8bDqdGGRBng6DrYRjmShI6Gs+OlBmim TsWxj4b5Y98CWakBHotPezzkHNHYn0Uaio8Ac2RsuBhJilQSfp7UD6IeUixS0sqUujrlr1Ip rFKi0pWq1KMROXkYUE7SbAhrWC51qclLztIgntSiLaWFS10WU2G89KV17ijMSRrTmftCZjKz AkxmCv/zmddkVzSlCcJqdtObPNrkNglSy28eLZjJC6c4cVRO25BTTOzUSTrFSc0bhhGeOZHn NukZOXfeE075lOY+6+hPbwI0mf0EJEG7aVBfIlSR9lToFnupz4h+CaJspNvc4lY3jmpUbufU pjqTuMyEGk6MeSoVQ2cp0JJWc6LVAakhRXoSlj60m5CKKSRnOtKKQsahUcJpLP/50mT2NDI/ tQ3o2PTGBQ51pyoxqk8vKkLfJah8WKwfRooiKJVyMpF8Q2p3ElfV/LENg1ktivq4SlRffvVs YWXSE6foG/P0RUUBUiuduhpJt5oNrjyKygRVRMQeliaDRBQeB+O010NG9TH/f5XNAiUrPdIo hDmFveBhKViXtT51K45dDGSlJFerNuiFL8xiDJ3qWZqC1rU8aV7/UlhYzJ4mi51lrUlq+tqY xdaw7qEr3FCbWMEslq0rJSlve7vUrer1uJzcrXJR1iamNtC5udWtdLULk6AW8rrYBdR2xRsi SAk1TIzto2ilpt5QKoqQyMIteDuZXLB687mtMa+X0CvH6PrVvihi5SqN9coAvzK/XdqvGfvr NfZ6CJv8GlSCu9jgo1G4Pw+GZnzl2xALA63D+cGwviJ830N+uGYm5k6I/aXhDR9kwV1D8XjH ImEkvphrMZZxWGhMQxtTDcc57sqOP/hj3AHZa0Ie/6CRf0JkJfepxQdpck+YHOV4kriPfWUw laOGZPdhGcYHADNIwDxmMpeZzGI2c5rP/BE1t/k+blYzmuFcZjnPecx1tvOb83xnNu85zH32 M57nzOXreVnLh7YNoY+HaEZHTtGzm3KjJf2TR5su0pPGdJWfzGH6ZtrTi6l06Hr8aVIH2cr8 7XSpVe2VUGfu0quGdast92pYq1rWj6N1rUl968GNWte/jgmv/+ZrYBc7JKdWcKpD1NGrfjSj zWb2s6W9UY821djPEnbe1KvOa58r22Hb9jZz2u2vIXvCpTI3x8ZNbpluep08OiknM8luQ337 aqNON6iqu256n8XeTRt1YP+llxL0+W64hyFjv7/r7lCVCiP+ix7EQ+Mi1khFtQrXb74/iCoR kc98wamg+QbLFOECl9l4vS3GV8twgnyOrGeV4A9DbqIRKYi2Erd4EVWOYI0nmUnWZeBQeEPy E+nv5iqcbV7CJ/MJ/mWzotn5eXveZWUf7OU0j3nWgVhzILKIsnmNepT+PTRDc+Th/Psh0mHU 0SAe/bfNAXvYgTR2nHH84ac9+Wb90uyRL/2uIh86DHUud3BO/Xrhps7AD7uo5hL+R3R/mXrN TVnFw7S6jp+74Y+Hb3EfGPP4gXzJOC/N9z7y8xsKPccCLk7Pn147qYcY4pNZetd7CPYA27aA W6n/SgIPmPe/LzDwfR98X7W+9onWPKTJpWLmZ/j4+bl9vIjNkeZXP5vPh37yLV11l1jf+97C fvZZ3nB45+v7589W+EGvfVGr3/06Zr+r3z//xsV/1vTHP43GfyHu59/I0Q+X6fO/7QJAZRHA AZSuAlwWBGTAI7G/x2nACAQJBfwUu4s2aoO2atPADOTAZ5NA8du/BCi7IDGjD1y/EBTB/ruT EjTBlnnAwRnBFxSSFnRBFHQ5JJo3GqwaFJS92dk3HdzBEOxBDFK8yqOixSuMhAPCdtu01fMe IUpCBXGNnAugJWTCJxu9rLKrCNK7vcugLTQ5FsEqxFIsK4QMChQXFWwe/+BoOx/Cn5pTu5iL EeIyQ53aP2ACusninTBMurQzLCK0oPxpOrjbIH6rQzSElCHMLC40LZujuEY0jeOIirirQ1CT QW1zOLJixPNxQ5NrQz+sLcGrwkp0DERUFEWcuI+Tw4ILrr6jKzGcQzI0RDM0xT+RPPpgDyFR QlJEi1r0k1vExd+pkR/kRUvkQXTrohwsRn+7RHDLRBw0vmUMCl+MlGekIWWURrKgxjZBxeOh vWwMmma8N3S7iN0jvuFDR3NMR92DlWgERydjOQtDP+97x7LYRjaRx3msvnrURnFsmnPRx33k x6XxR7JbvoBkvoEkSBtUyM+7RzJpSIcsyLqLSODHe0iTqUjCu8gsybWMVJqNpJKO9EijAckp EcmR3JmSzJk8E7Q5a0k4e0k3i8k2m8k4A7Q9q8k0y0kz20k6u0mW/Ek768k18wg/+7OiNMqh 5DOkDLSgdEmnhDOVRMGppMqnksqqxMqsnKWr1Mqu9MoP4sqvFMuxfJywJMuzRMuSMcu0ZMu2 hJS1dMu4lEsqgcu5tMu7rJC6xMu95EvW0Mu+BMzAfIq/FMzCNEyKIMzDVMzFTMzFdEzBbMzH lMy9jMzJtEy5rMzL1My0zMzN9Eyx7MzPFM2sDM3RNE0URICAAAA7 --------------070206090607010806060701-- From owner-voql@eso.org Sun Feb 8 18:40:12 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 i18HdqnX004037 for ; Sun, 8 Feb 2004 18:39:52 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18HdqBT004036 for voql-outgoing; Sun, 8 Feb 2004 18:39:52 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18HdnnX004017 for ; Sun, 8 Feb 2004 18:39:49 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i18HdiEY018035 for ; Sun, 8 Feb 2004 18:39:44 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 0A7821C00146; Sun, 8 Feb 2004 17:39:43 +0000 (GMT) Message-ID: <40267467.9060108@dial.pipex.com> Date: Sun, 08 Feb 2004 17:39:51 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: ADQL schema versions 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi all, Can we agree where the ADQL schemas are going to be posted so that we can find them in one place? They should be versioned too, say in the schema name itself (eg ADQL-v0.5.xsd, ADQL-v0.6, etc). That way we don't suddenly break tools when the schema is updated, and it helps when parsing query documents as we can work out which version has been submitted. In the meantime I have made some guesses at versions and posted them here: http://wiki.astrogrid.org/pub/Astrogrid/AdqlNotes/ADQL-v0.5.xsd - from the SkyService ADQL definition page. http://wiki.astrogrid.org/pub/Astrogrid/AdqlNotes/ADQL-v0.6.xsd - from the SkyService Translator page Also - why is there such a difference between them? I can understand our own human-added elements changing (eg XMatch and Area) but if the rest of it is automatically generated why is it changing? Cheers, Martin -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Sun Feb 8 18:57:44 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 i18HvBnX005724 for ; Sun, 8 Feb 2004 18:57:11 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18HvBAx005723 for voql-outgoing; Sun, 8 Feb 2004 18:57:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18Hv8nX005712 for ; Sun, 8 Feb 2004 18:57:08 +0100 (MET) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i18Hv2WR003729 for ; Sun, 8 Feb 2004 18:57:02 +0100 (CET) Received: from gnowee ([81.98.151.223]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040208175701.DCYT1936.mta06-svc.ntlworld.com@gnowee>; Sun, 8 Feb 2004 17:57:01 +0000 From: "Tony Linde" To: "'Martin Hill'" Cc: Subject: RE: Adql.xsd Date: Sun, 8 Feb 2004 17:58:18 -0000 Organization: University of Leicester Message-ID: <00a901c3ee6d$21ed4670$6124d28f@STAR.LE.AC.UK> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00AA_01C3EE6D.21ED4670" 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: <402662AC.7070503@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01C3EE6D.21ED4670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The schema is the one I'm working with. When I load it (with the import statements removed, I get an error message: 'This schema doesn't appear = to be valid by itself(...): No type with name "q2:regionType" has been defined...'. Ah! But I can now see the same structure as you appended last time. = Guess it is slightly different. Now, when I expand IntersectionSearch, I can see it is a sequence of FirstCondition, SecondCondition (see attached) but cannot get any = indication of what they might contain (they are of type Search so should contain = the Search structure, no?). I guess this is because I don't really understand all the extension/inheritance stuff in xml schema. Cheers, Tony.=20 > -----Original Message----- > From: Martin Hill [mailto:mchill@dial.pipex.com]=20 > Sent: 08 February 2004 16:24 > To: ael@star.le.ac.uk > Cc: voql@ivoa.net > Subject: Re: Adql.xsd >=20 >=20 > Tony Linde wrote: >=20 > >>As a 'temporary fix' for examining the schema, delete the imports. > >=20 > >=20 > > That just produces an error on the types defined within the=20 > namespaces=20 > > of those schema. >=20 > yes - but you should be able to work with the rest of it, or? >=20 > >>imports) and start from the WhereClause or TableExpression. > >>This gives you a=20 > >>possible-instance tree but I think that's what you want anyway. > >=20 > >=20 > > All I get is as attached (.jpg). >=20 > Hmm. I get the attached. I've working with XML Spy 2004=20 > release 3, working=20 > with the adql schema given at: >=20 http://skyservice.pha.jhu.edu/develop/vo/adql/doc/ADQLSchema.xsd --=20 Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org ------=_NextPart_000_00AA_01C3EE6D.21ED4670 Content-Type: image/gif; name="intsrch.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="intsrch.gif" R0lGODlhlgFlAPcAAP///wAAAMDAwP//v3QAAEic3/+/dABInN+/dHS////fnEgAAAAASJzf/wAA dL///0gASN+cSJy//5y/nN///wB0v///35xIAHS/v790AJxIdEhInEicnJyc30gAdJxISP++vv5v cP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlgFlAAAI/gABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCg0aoOjAogGOGhWIVGlSpksBNIX6VGrUqVarYt16tatWr07DDh1LtqzZs2jT qq1Zda3bt3DjMmwrt67du2bp4t0YQIBfAXsDCx48s+9fwogTKx5p2O/ix5DTDiBQAOVfwJEzB9Y7 0ABSpAcQBEhwUcECpAwaZJxc2TPpgq43XtZM+y5ngQYcPCgNQfXACKN/B7/IuqCC3iBn114O9zaA 3LstHvf9fPhABRIwFic4/WNjzMzD/t+Fbhz58QkLUk8GTWF90QoWLhygkNDz+4GTMRAoWnlghs+V TedeABV0V919AuW3XwD9HfSdeBDWZR9SunVn2nwAbGeBBrsZuN1BBqQGQHwVJEiAbs+JCEAEKBZn IXIAdBeiaiSaiOKMCD0Y4Y40cfWVc8+hyJ15MJr22pC+fVhQfA12N9lrRmZIwGsuEunbdExeh9yT AkWJkHI8hvkSkAQ5Rx6SMcIIwH8BCJlmkpQhxKWJpM3JpYdxvnhlb3NKWeeUdCYEppiE5mSmm11a WRBwbXYIY3wYGtQnl3YCimeAir45KaCVHmnQoIWG2mN9iL5pqkFRGlidpzFKkGWi/qp1GuMCVOaZ KZYXNLkloH7mCKqowOZ0ppaqGajABvSlGGuc/lkHHGk41tjrtBlgCBymy/Yno4jSyurgr8GGyxdG w8J6anyoUWdfiV2eVpSKBxKIH6+VFsWBrb6ta+CE7E7bZ0E6iivwuAMvBG7BCENE5lHhHpzwwxot DKHDKH1m8cUYZ6zxxhx37PHHIIcsMlYKj3xxxcEG3JLEECvEcpkZvdzyQyqvJPPMBt18s8sX7Rxq zSn5jDPDNHckNFNDD0QxY0kHSvPSR/NMEcs+ipWV1VVThTVYWnd9tddZfy32VEuH1Bab8vIUG0UT FsUqR//mvLHU3s3N0WV45633/t589+3334AHLjjeLNGlKkKHn5Q4Rc92FqlHcQOcEJBRL+Rc5Z8O rvnmnHfuud6Fl0cd4mqitLhE0pYUOcw50u3R5R19LvvstNMeOpoK8mciUuxOGOl56TUwYKS+Jxvv aAMWCCO/8+qn+4gX9GtQ8QIxGgC8wIvYdgK5M5jz5K4bDf74ENVu/vno8307sVLeqKKqLEZXLX0X 0qchhysKOf+KwxmArbnRip6NdoMj/knvN/qz1mvi165INe45BZiM+0YnFfI5yGVLmQrJvtc6CzZt ZaKblpfwdCQ9tYtVfRIQs9D0pleZak5eOh6GUli6U12qIDCkleQwlhWNlclk/haDGQ8/ExbMfRAj httVraBUJHel61RrKoqQTGOx1MSQfZriVa+8ZZwFzIeKn1ER2t7XRBTSS4tI66AaHZTBNlLOg5I7 okuSuKwlmguKLBROoxZ3xTuq8EiUOuPbcGPFGkoJQ8YqIw4FGccLwpFgjlyjHFVCR3/x6oaoMuSs uLfCeTUIi7jSVR0DNYAOLEo3SuqSB6KTSDh90pKsgt0jIzbLScKkkt760AMt8IFiFQlZhFTNLnu5 IhX5T0raQk4A2SUrCbJyAewapvAAFR8yUicCxowgI1kXyW6KT5K2lMnZeMfFdbWLPee6wBPPWRTi feY1+loe7+ZlRym9kztO/sSQfRgwgSKVbntcpErGwscRjoXzJkZsGdAaWVDCFe2gNoOo5cqW0KPk TWE049rYNBq2jnL0oz/aWkjBBlKRFlSikytbBSMGuoeiNGgvzZlKV9qzvcX0pEYDok53ytOe+vRj M+2hTm3qHYhWlCDpS6pSl2q+8qXPbEYNakOYStWqWrVvEUHfRKgmUalO9apgDetSJdLUrd7UYIeJ nVjXylbZTcR2U5NMJ0GSypF49aw7apt1TqIkMF6PghQpztoIMtiaphWvYnLOA5/zOJPo0ll7Dexc T4fEuyJ2MbdJXUu2U9hWaWeymqzsYS+rGK4eRLOwQSdu7hmvfnXvk2jz/h6kjDe9eZrIed5rFlKw lbx92VZKuH1lQSxL2rVgDjgHrF4C6fPAYy5zgMpS7m6KU9fOcEuA7SOgihhYJV/uSTXPzW50vzTa 4hLGo2Rq2wy1qMJXutBJl9RhpSpTXeiJUoTyPeP/WvleJZ5QUOU1b7jq59d3NaCPm/qTHW9Y3wTD 8lTdtSGftBjIeso0wAKuzctmxEcdEsTBsrrhbA8CYkbe0IRZBCSntnlhx2RYPLcp5SkfUNdU9neU vfISZyOLnRs/WMf4knADfBzQMhH3xXiJ8YmeGc3h8FKY2Yxut7a5v2s160iNC6+3quw9+CYTvNdl Josz52IkE2pAe/Wr/juRAs/f5nJB9/qkX+HFPKfVKwBxPlU88+XmMQ8Xw2YOdFyOLOhC92Shhk7M UQmF6ESfN6qAdvRgFk0oQkv60jOxNKY37RJNc5os6DUpSUe6UVKHetSiLnWqfeTpT5elrbCOdUtd nRhZ21rWtFbMrXfN1lzXmtfAvqqvh03sYhv72MhOtrKXzexmO/vZ0I62tKdN7Wpb+9rYzra2SQsC EIRABOAOt7jHTe5ym/vc6E63utfN7nFvWzHe/na7503vetv73uT+ibzBDQKWgNshIPg3QQIugoTw GwAEB0C4B7LwhA+E4AKfiLgP4nCPQDziChdBxTXibXx7PN0hEMjH/keO7p/kuyMbPwjGFZLwlq+c IN8OecwzrnGENzziF385Q3Je8IKkfCM5Jwi///1zifCc5CQPOc2RzvSe80TeNnc60HUudKkDnOhU j3rG+x1umd/c6Q7PekLCbnWtf6ToGC86RI7edI8rve1N9wnUXY71cPcb4jaH+sQvHvWe813oIQ94 v79N8IvnvN8FGXrPJ753nB9cIIbPOMOlXviBf93ufe97wR8/cYNs3PCKr3vB/46Qjp877wAgPORF 4HXEB7z1SxfIzFMPc9m/XekKx73CRS5wceMe3L/Xfc/3nW65p33ch0c+ukEv7qBXPfWs33roNX5y mLM++kvn+8bl/q305Nc85dxfffPJ7X3yV//hwA9BCLzPfLt3HiHEL7fI7y7179ef/rwHvshtD3/Z F0T3AzF7Xfd/BKhy62Z8m6d40peACaeAucd7WteA1JeAiTeBE0h3EfhyEId4wHd9c5d23Ndt/xZz Mzd7DxeCCUd4dSeBEih9b1d23reAGciAYodw8XdyuKd7OVh7/rd0fidyb9eDSheEtLd7CGdz9Kd/ Cjd4+1eEi5d/xdcTeqd48saCHTiBJ/h1UVeF/7ZyMeeBrIeBGPh/Hsh7G1h3ngd8KRiGiod4PqeG jjd6VKiAXfh9+5aGGtdtViiHfCiDLKdud3eEdxeIhEiIgjhu/jmIfcPXg9gngEIoewNIc0RIhIt3 gFK4gspHg+Pnd6z3gXzofhRofVfIhn04hlVHdjQneUVXeCMYfV8IgJaHheIXdTFYhyKofhoYhzKI gQ6YEDdIfg/3cG44jMOIfs13iJPIiNjnbU34fZr3gorIiM1oiU+HiaMngpqIcNhohqqIhnpYh28Y etsohivHgpI3c2g4i6xYcDO3gQbRe1iognzYcttoiweXi2Bnj6Wojwvxi4gYgAG4g/zXg9AXiUOY jEU4hNL4gJAYiTWHkE/og6fnE+a3iQsIirx3h2e4iQs3cCUYhnSHheDnitGHdVz3idOXkhyocxWJ keuIkfp4pIfhCIouSZO9iBDrtn5IaIM6KXg8SX93923zt5PMaIQKWYQA+XwQyJBJmZQRyW765n6Z 14J453DrqI4dSXro53WBJ3BXmXIH14JGKHpkiY2PR3CwCIVJuI+fqHW2eJUzWZaiN5U1yG5ASYtE GZb2F5Gzh5C3x3DCt4zw+HvYx5BPSY3G9nmYpxhw15jmBo2J6Jjyh2yKWXOLIZmYqYQGmZnkFhAA ADs= ------=_NextPart_000_00AA_01C3EE6D.21ED4670-- From owner-voql@eso.org Sun Feb 8 19:19: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 i18IJ9nX007942 for ; Sun, 8 Feb 2004 19:19:10 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18IJ9b8007940 for voql-outgoing; Sun, 8 Feb 2004 19:19:09 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18IJ7nX007924 for ; Sun, 8 Feb 2004 19:19:07 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i18IJ4EY019067 for ; Sun, 8 Feb 2004 19:19:05 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id EC1351C000E9; Sun, 8 Feb 2004 18:19:03 +0000 (GMT) Message-ID: <40267DA0.5040806@dial.pipex.com> Date: Sun, 08 Feb 2004 18:19:12 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ael@star.le.ac.uk Cc: voql@ivoa.net Subject: Re: Adql.xsd References: <00a901c3ee6d$21ed4670$6124d28f@STAR.LE.AC.UK> In-Reply-To: <00a901c3ee6d$21ed4670$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony Linde wrote: > Ah! But I can now see the same structure as you appended last time. Guess it > is slightly different. You were probably working with what I think is v0.6. > Now, when I expand IntersectionSearch, I can see it is a sequence of > FirstCondition, SecondCondition (see attached) but cannot get any indication > of what they might contain (they are of type Search so should contain the > Search structure, no?). > > I guess this is because I don't really understand all the > extension/inheritance stuff in xml schema. The way inheritance/polymorphism works is not ideal in XML. When you look at FirstCondition and SecondCondition they are of type Search, but Search itself does not define what happens lower. You will notice that in ADQL documents you need to actually specify the non-abstract subclass as an xsi:type attribute. I would have thought XML Spy could parse the schema to find the possible subclasses but I'm not sure what the implications are. Remember also that a schema is structured around *ownership* of elements. Typing heirarchies are of course different to ownership heirarchies. Of course, SADQL's polymorphism via substitutionGroup works wonderfully under XML Spy :-) MC -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Sun Feb 8 22:25:54 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 i18LPMnX017940 for ; Sun, 8 Feb 2004 22:25:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i18LPLS4017939 for voql-outgoing; Sun, 8 Feb 2004 22:25:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i18LPJnX017929 for ; Sun, 8 Feb 2004 22:25:19 +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 i18LPHEY024172 for ; Sun, 8 Feb 2004 22:25:17 +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 <20040208212440.YEAU9105.mta05-svc.ntlworld.com@gnowee> for ; Sun, 8 Feb 2004 21:24:40 +0000 From: "Tony Linde" To: Subject: More ADQL.xsd Date: Sun, 8 Feb 2004 21:26:33 -0000 Organization: University of Leicester Message-ID: <00b401c3ee8a$39e851d0$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 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 i18LPLnX017936 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Part of Martin's argument against the complexity of ADQL is to do with the almost unending nesting of elements before we get to something useful: see eg ref (1) below (courtesy of Martin in another email). What I'd like to ask is how necessary these are. To my way of thinking, it boils down to the use we make of ADQL. If we only ever translate ADQL to SQL, then the complexity is unnecessary and we could make do with something like Martin's cut down SADQL (giving a structure like ref (2) below - also from Martin). If, however, we expect to use ADQL on non-SQL back-ends then it seems that it is better to know that you're dealing with an IntersectionSearch and can handle that as a whole structure rather than in SADQL where you have to wait until you find the element after your first clause before knowing what type of search you have. Another possible issue is one Clive Page has raised: optimising the translation of a SQL query to match the target database. It may be that the translator will need to know that it is dealing with an IntersectionSearch (or whatever) in order to perform the optimisation. If a simplified ADQL, which does not identify an IntersectionSearch upfront, has to be parsed to identify the search type before optimisation, then we've gained nothing over transmitting the ADQL/s. Cheers, Tony. (1) a z > 19.5 a i - a z > 2.2 (2) Z 19.5 I Z 2.2 __ 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-voql@eso.org Mon Feb 9 08:49:38 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 i197mr3n026613 for ; Mon, 9 Feb 2004 08:48:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i197mrIe026612 for voql-outgoing; Mon, 9 Feb 2004 08:48:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i197mo3n026603 for ; Mon, 9 Feb 2004 08:48:50 +0100 (MET) 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 SMTP id i197mkWR024790 for ; Mon, 9 Feb 2004 08:48:47 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i197mkW24340 for ; Mon, 9 Feb 2004 01:48:47 -0600 Date: Mon, 9 Feb 2004 01:48:46 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: Re: Adql.xsd In-Reply-To: <007201c3ed5a$f7d002f0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Tony, On Sat, 7 Feb 2004, Tony Linde wrote: > Does anyone have access to an xml expert who could cast their eye over the > automatically generated schema to see if it is using 'good practice' in xml > terms? I'll take a crack at this. The technique used here is an alternative way of implementing polymorphism to the use of substitution groups which we used in VOResource. Some in our VO community have advocated that we use the "xsi:type" technique over the "substitution group" technique. The pattern in the xsi:type technique looks like this: ... With the substitution group technique, it would look like this: ... I, too, found it harder to browse the schema; nevertheless, I do think it is an equally legitimate technique. Both are discussed in the XML Schema spec pt. 0. There are advantages and disadvantages to both; which are which depends on your viewpoint. The xsi:type technique has the advantage of explicitly signalling the use of polymorphism by showing both the base name and the derived type. (More to the point re: VOResource, the xsi:type technique is prefered by those who would rather see only one global element--the root element--defined in a schema.) To help get my head around this schema, I made a type inheritance chart (i.e. w/pencil & paper) for the types "ScalarExpression", "Search", and "Predicate", noting which local elements were of the base type. There's a consistant pattern there that actually makes sense when you see it. hope this helps, ray From owner-voql@eso.org Mon Feb 9 09:54: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 i198sM3n012377 for ; Mon, 9 Feb 2004 09:54:22 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i198sMXQ012376 for voql-outgoing; Mon, 9 Feb 2004 09:54:22 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i198sJ3n012358 for ; Mon, 9 Feb 2004 09:54:19 +0100 (MET) Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i198sIEY012148 for ; Mon, 9 Feb 2004 09:54:18 +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 1Aq7BJ-00006r-7z for voql@ivoa.net; Mon, 09 Feb 2004 08:54:17 +0000 Received: (qmail 10738 invoked from network); 9 Feb 2004 08:54:35 -0000 Received: from sparky.star.le.ac.uk (143.210.36.10) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 08:54:35 -0000 Date: Mon, 9 Feb 2004 08:54:36 +0000 (GMT) From: Clive Page To: Tony Linde , Subject: Re: Adql.xsd In-Reply-To: <40251FF8.4030005@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Sat, 7 Feb 2004, Martin Hill wrote: > There is a small inconsistency between XMatch and Region. Because the Region is > a single 'search function' with all its parameters included inside the brackets, > it's straightforward for the backend to optimise the SQL. However the XMatch > one is a function, of the form: > > XMatch(table1, table2) < sigma I think there's more than a small inconsistency. I don't understand, myself, how to implement XMATCH as currently defined. Surely you need to know the value of sigma before you can work out which sources in table1 will match to those in table2 (to compute the maximum position offsets)? If so, it would be better (well essential) to have the sigma value as one of the parameters of the function, e.g. XMATCH(sigma, table1, table2) I'm not sure, actually, whether "sigma" presumably meaning some multiplier of standard error, is the right thing to use. It assumes that our errors are always Gaussian. Some sort of probability or likelihood would be more appropriate, wouldn't it? I suppose the main advantage of sigma as a probability measure is its simplicty (e.g. with a 3-sigma result you can write a conference paper, a 5-sigma one means you can try to get something in a refereed journal) while the corresponding likelihood values (assuming a Gaussian distribution) have lots of zeros in them and are harder to remember. It's not clear that the same advantage applies here. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Leicester, LE1 7RH, U.K. From owner-voql@eso.org Mon Feb 9 10:44: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 i199id3n023781 for ; Mon, 9 Feb 2004 10:44:39 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i199idK9023779 for voql-outgoing; Mon, 9 Feb 2004 10:44:39 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i199iZ3n023745 for ; Mon, 9 Feb 2004 10:44:35 +0100 (MET) Received: from mail.mtk.nao.ac.jp (mail.mtk.nao.ac.jp [133.40.4.4]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i199iVEY014283 for ; Mon, 9 Feb 2004 10:44:32 +0100 (CET) Received: from Cassiopeia.mtk.nao.ac.jp (localhost [127.0.0.1]) by mail.mtk.nao.ac.jp (8.9.3p2-20031023/3.7W00121514) with ESMTP id SAA09790; Mon, 9 Feb 2004 18:44:16 +0900 (JST) Message-Id: <6.0.0.20.2.20040209184111.040560b0@mail.mtk.nao.ac.jp> X-Sender: ohishims@mail.mtk.nao.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Mon, 09 Feb 2004 18:44:14 +0900 To: "Tony Linde" , From: Masatoshi OHISHI Subject: RE: The case for XML ADQL In-Reply-To: <002a01c3eca7$a59f4d00$6124d28f@STAR.LE.AC.UK> References: <6.0.0.20.2.20040206200445.0441d8e0@mail.mtk.nao.ac.jp> <002a01c3eca7$a59f4d00$6124d28f@STAR.LE.AC.UK> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit 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-voql@eso.org Precedence: bulk Reply-To: Masatoshi OHISHI X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, I contacted to our delevoper, and he says that he is very happy to upload to our web page, but 1) the code has been made for use by only JVO prototype, 2) the prototype and the code is under improvement, 3) therefore it will take about a month to release the code. Cheers, Masatoshi At 11:52 04/02/06 +0000, Tony Linde wrote: > >Is the code available for download? > >Cheers, >Tony. From owner-voql@eso.org Mon Feb 9 11:10: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 i19AALLW028897 for ; Mon, 9 Feb 2004 11:10:21 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19AAL6D028895 for voql-outgoing; Mon, 9 Feb 2004 11:10:21 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19AA6LW028834 for ; Mon, 9 Feb 2004 11:10:06 +0100 (MET) 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 SMTP id i19AA3EY015291 for ; Mon, 9 Feb 2004 11:10:04 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19AA5Z25275 for ; Mon, 9 Feb 2004 04:10:05 -0600 Date: Mon, 9 Feb 2004 04:10:05 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: ADQL: comments on spec. 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi ADQL crafters, First, my apologies for not assembling these comments on the ADQL spec sooner. I know the effort it takes to develop such a document ;-) But, now that we've started in on a SkyNode spec, I've been digging deeper into the documents. I'll say off the top that I *don't* see ADQL as fundementally flawed; my comments are mainly about the effectiveness of the document as a formal specification to be standardized. My overall comment on this document is that it is not precise/explicit enough on the syntax and semantics. At the root of this is ADQL's relationship to SQL. The doc says that ADQL is based on a subset of SQL; however, it does not spell out exactly what SQL and what subset. Instead, it is merely implied (in words and in the reference to the ADQL schema). To clarify the syntax and semantics, the spec must: o indicate which version of standard SQL it draws on (referencing its specification document), and o spell out explicitly which constructs are allowed or disallowed. Or, it must spell out the syntax and semantics of the SQL subset independently of some referenced standard (e.g. provide BNF annotated with semantic meanings). For the XML schema, each element must be provided with a definition and its unambiguous relationship to an SQL component. (As mentioned in earlier message, I recommend the use of XML Schema documentation markup.) It should also (eventually) have a defined targetNamespace; this is how consumers know that it's official IVOA ADQL and not somebody's variant. Other specific points: o "SkyQL shall have SQL like Syntax": this is too vague for a specification. How do I know that my implementation passes this requirement? (It's okay as a motivating statement, but not as the sole content of "ADQL-7".) o Are regions formally part of ADQL? If so, the syntax for regions in SkyQL needs to be explicitly defined: What does each argument in the region string refer to, and exactly how does it map to the XML form? When developing our adql2sql XSL stylesheet, we found that we could not create generic mappings that matched the behavior of the JHU translator. For example, when the circle example is sent through the SQL to ADQL translator, the J2000 information seemingly disapears. And what is suppposed to be the difference between "J2000" and "Cartesian"? All possible values that can be put in there (that are formally part of this version of ADQL) must be enumerated and defined. Personally, I do not feel regions should be explicitly be part of ADQL. Instead, it should define a general syntax for functions. Another standard (e.g. the SkyNode Interface) would define the region functions in terms of this syntax. o Note that since ADQL appears to depend on the STC metadata, I do not think it is appropriate to advance the ADQL spec through the standardization process until the STC does. That is, STC needs be at the same or higher standardiation step. o I would recommend including a few more sentences that discuss the motivation for each form (XML and string). This is now well-known to those on this list; we just need to get it down in the document. In general, with its use of "should" and "something like", this document reads more like a requirements document rather than a specification. cheers, Ray From owner-voql@eso.org Mon Feb 9 15:30:18 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 i19ETeLW023945 for ; Mon, 9 Feb 2004 15:29:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19ETe8O023944 for voql-outgoing; Mon, 9 Feb 2004 15:29:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19ETaLW023935 for ; Mon, 9 Feb 2004 15:29:37 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19ETZWs025382 for ; Mon, 9 Feb 2004 15:29:35 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 18A171C00146; Mon, 9 Feb 2004 14:29:34 +0000 (GMT) Message-ID: <40279956.70202@dial.pipex.com> Date: Mon, 09 Feb 2004 14:29:42 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: ADQL/XML non compliance with SQL? 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: I'm pretty sure this is correct (standard) SQL: SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e I would expect that an SQL database will look at those ANDs and work out which is the quickest set to solve first depending on internal indexing. However ADQL/XML (and SADQL v1.0!) only allow pairwise ANDs. When transforming ADQL/XML -> Database SQL, we must use brackets around each boolean construct, because we don't know what the original priority might have been, ie: WHERE (f OR f) AND (t OR t) = f is different from WHERE f OR (f AND t) OR t = t and as soon as we use brackets we lose multiple Unions/Intersections. We could work with the backend ADQL/XML->Database SQL transformations to fix this, but I think it might be better if the schema represented the SQL 'properly'. Particularly as currently I expect it's the ADQL/SQL -> ADQL/XML parser that is prioritising the brackets, rather than the backend. So can I propose that IntersectionSearch and UnionSearch take 2..unbounded arguments? On another point, isn't XOR a standard SQL boolean operator? Cheers, Martin -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 16:09: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 i19F8lLW003545 for ; Mon, 9 Feb 2004 16:08:47 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19F8lBt003541 for voql-outgoing; Mon, 9 Feb 2004 16:08:47 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19F8gLW003523 for ; Mon, 9 Feb 2004 16:08:42 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19F8c4x011553 for ; Mon, 9 Feb 2004 16:08:39 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqD1Z-0001ZQ-Gf for voql@ivoa.net; Mon, 09 Feb 2004 15:08:37 +0000 Received: (qmail 4613 invoked from network); 9 Feb 2004 15:08:57 -0000 Received: from sparky.star.le.ac.uk (143.210.36.10) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 15:08:57 -0000 Date: Mon, 9 Feb 2004 15:08:59 +0000 (GMT) From: Clive Page To: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: <40279956.70202@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Clive Page X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Martin Hill wrote: > WHERE (f OR f) AND (t OR t) = f > > is different from > > WHERE f OR (f AND t) OR t = t As far as I can discover, the AND operator has higher precedence than OR in SQL, as it does in most languages. (I just tried to do a Google search on the operators AND and OR and it didn't get me anywhere, I suppose I should have expected that :-). > On another point, isn't XOR a standard SQL boolean operator? Not as far as I can tell from DBMS manuals that I've looked at, but I don't have access to an SQL Standard here. -- Clive Page Dept of Physics & Astronomy, University of Leicester, Tel +44 116 252 3551 Leicester, LE1 7RH, U.K. Fax +44 116 252 3311 From owner-voql@eso.org Mon Feb 9 16:14:43 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 i19FETLW004787 for ; Mon, 9 Feb 2004 16:14:29 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19FETFX004786 for voql-outgoing; Mon, 9 Feb 2004 16:14:29 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19FEMLW004721 for ; Mon, 9 Feb 2004 16:14:22 +0100 (MET) Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19FEJ4x011775 for ; Mon, 9 Feb 2004 16:14:20 +0100 (CET) Received: from localhost (budavari@localhost) by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i19FEG100775; Mon, 9 Feb 2004 10:14:16 -0500 X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs Date: Mon, 9 Feb 2004 10:14:16 -0500 (EST) From: Tamas Budavari To: Clive Page cc: Tony Linde , Subject: Re: Adql.xsd In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: Tamas Budavari X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Clive, XMatch() is not a function, even though it looks like one. It is interpreted by the portal and not necessarily at the SkyNodes. It all depends on where we want to put the smarts. We would like to keep the nodes simple (for obvious reasons) but without taking a factor of 2+ perfomance hits, e.g. portal talks to individual nodes one by one and does crossmatch and hence becomes the bottleneck. What the XMatch clause really means is that once you have the best estimate for the coordinates only those objects are kept from the different catalogs that are within say 3 sigma, where this sigma is their own astrometric uncertainty. The SkyNodes know their astrometry and will have to use different chisq/probability thresholds. The XMatch clause does not apply when you simply query a single database. It may be the case that subrequests in federated queries will be made using the same construct to keep ADQL simple but it probably would be best to separate out that functionality into a separate method (a.k.a. web service, web method, port, etc...). Then only the portal would have to know how to deal with XMatch but the nodes would have to implement an extra xmatch interface. I personally think that it doesn't really matter what the actual syntax is for XMatch but this one is very intuitive and remember, these queries we will have to write unlike the wire format XML representation. Cheers, T. -- Tamas Budavari Dept. of Physics and Astronomy The Johns Hopkins University 3400 N. Charles Street Baltimore, MD 21218 Phone: +1 (410) 516-0643 Fax: +1 (410) 516-5096 http://www.sdss.jhu.edu/~budavari On Mon, 9 Feb 2004, Clive Page wrote: > On Sat, 7 Feb 2004, Martin Hill wrote: > > > There is a small inconsistency between XMatch and Region. Because the Region is > > a single 'search function' with all its parameters included inside the brackets, > > it's straightforward for the backend to optimise the SQL. However the XMatch > > one is a function, of the form: > > > > XMatch(table1, table2) < sigma > > I think there's more than a small inconsistency. I don't understand, > myself, how to implement XMATCH as currently defined. Surely you need to > know the value of sigma before you can work out which sources in table1 > will match to those in table2 (to compute the maximum position offsets)? > If so, it would be better (well essential) to have the sigma value as one > of the parameters of the function, e.g. > > XMATCH(sigma, table1, table2) > > I'm not sure, actually, whether "sigma" presumably meaning some multiplier > of standard error, is the right thing to use. It assumes that our errors > are always Gaussian. Some sort of probability or likelihood would be more > appropriate, wouldn't it? > > I suppose the main advantage of sigma as a probability measure is its > simplicty (e.g. with a 3-sigma result you can write a conference paper, a > 5-sigma one means you can try to get something in a refereed journal) > while the corresponding likelihood values (assuming a Gaussian > distribution) have lots of zeros in them and are harder to remember. > It's not clear that the same advantage applies here. > > > From owner-voql@eso.org Mon Feb 9 16:17:13 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 i19FGpLW005352 for ; Mon, 9 Feb 2004 16:16:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19FGohR005347 for voql-outgoing; Mon, 9 Feb 2004 16:16:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19FGdLW005300 for ; Mon, 9 Feb 2004 16:16:39 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19FGYWs027451 for ; Mon, 9 Feb 2004 16:16:37 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqD9E-0002qW-NC for voql@ivoa.net; Mon, 09 Feb 2004 15:16:32 +0000 Received: (qmail 5801 invoked from network); 9 Feb 2004 15:16:53 -0000 Received: from sparky.star.le.ac.uk (143.210.36.10) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 15:16:53 -0000 Date: Mon, 9 Feb 2004 15:16:54 +0000 (GMT) From: "Patricio F. Ortiz" To: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: "Patricio F. Ortiz" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > On Mon, 9 Feb 2004, Martin Hill wrote: > > > On another point, isn't XOR a standard SQL boolean operator? > According to a couple of sites I've seen yes, XOR is part of SQL and should migrate to ADQL Cheers, Patricio --- Patricio F. Ortiz pfo@star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UK From owner-voql@eso.org Mon Feb 9 16:26:06 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 i19FPgLW007852 for ; Mon, 9 Feb 2004 16:25:42 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19FPgdp007847 for voql-outgoing; Mon, 9 Feb 2004 16:25:42 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19FPYLW007810 for ; Mon, 9 Feb 2004 16:25:34 +0100 (MET) Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19FPWWs027877 for ; Mon, 9 Feb 2004 16:25:32 +0100 (CET) Received: from katrine.roe.ac.uk (localhost [127.0.0.1]) by katrine.roe.ac.uk (Postfix) with ESMTP id 2F83044016; Mon, 9 Feb 2004 15:25:32 +0000 (GMT) Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP id 28016; Mon, 09 Feb 2004 15:25:31 +0000 (GMT) Received: from katrine (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DC2504400A; Mon, 9 Feb 2004 15:25:30 +0000 (GMT) Received: from localhost ([127.0.0.1]) by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ; Mon, 9 Feb 2004 15:25:30 +0000 (GMT) Received: from skiach.roe.ac.uk (skiach.roe.ac.uk [195.194.121.131]) by katrine.roe.ac.uk (Postfix) with ESMTP id 921314400A; Mon, 9 Feb 2004 15:25:30 +0000 (GMT) Date: Mon, 9 Feb 2004 15:25:30 +0000 (GMT) From: Clive Davenhall To: Clive Page Cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no version=2.62 X-Spam-Level: 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-voql@eso.org Precedence: bulk Reply-To: Clive Davenhall X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > On another point, isn't XOR a standard SQL boolean operator? Well, it is not included in the table of logical operators in O'Reilly's `SQL in a Nutshell' (Table 3.7, p123, an edition published in 2001). Though this is not definitive, of course. Clive. ----------------------------------------------------------------------------- Clive Davenhall Institute for Astronomy, e-mail (internet, JANET): acd @ roe.ac.uk Royal Observatory Edinburgh, fax from within the UK: 0131-668-8416 Blackford Hill, Edinburgh, fax from overseas: +44-131-668-8416 EH9 3HJ, Scotland. From owner-voql@eso.org Mon Feb 9 16:26:10 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 i19FPoLW007884 for ; Mon, 9 Feb 2004 16:25:50 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19FPoo5007883 for voql-outgoing; Mon, 9 Feb 2004 16:25:50 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19FPfLW007842 for ; Mon, 9 Feb 2004 16:25:41 +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 SMTP id i19FPd4x012278 for ; Mon, 9 Feb 2004 16:25:39 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 114BB1C003BC; Mon, 9 Feb 2004 15:25:37 +0000 (GMT) Message-ID: <4027A679.2010800@dial.pipex.com> Date: Mon, 09 Feb 2004 15:25:45 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Clive Page Cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Clive Page wrote: > On Mon, 9 Feb 2004, Martin Hill wrote: > > >> WHERE (f OR f) AND (t OR t) = f >> >>is different from >> >> WHERE f OR (f AND t) OR t = t > > As far as I can discover, the AND operator has higher precedence than OR > in SQL, as it does in most languages. That just means that we know that WHERE f OR f AND t OR t is the same as WHERE f OR (f AND t) OR t but doesn't help the problem which is that WHERE a AND b AND c AND d will get converted to WHERE (((a AND b) AND c) AND d) (or something equally arbitrary) which we don't want to force. I would imagine that many SQL databases will work out that they are equivelent, but I don't know... it may be that specifying brackets like that specifies the way the search is run. And there will be non-SQL backends. -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 17:02:51 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 i19G2XLW017884 for ; Mon, 9 Feb 2004 17:02:33 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19G2XuJ017883 for voql-outgoing; Mon, 9 Feb 2004 17:02:33 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19G2ULW017860 for ; Mon, 9 Feb 2004 17:02:30 +0100 (MET) Received: from jansky.ncsa.uiuc.edu (jansky.ncsa.uiuc.edu [141.142.65.221]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19G2PWs029780 for ; Mon, 9 Feb 2004 17:02:26 +0100 (CET) Received: from jansky.ncsa.uiuc.edu (ramonw@localhost) by jansky.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19G2Ov26996 for ; Mon, 9 Feb 2004 10:02:24 -0600 Message-Id: <200402091602.i19G2Ov26996@jansky.ncsa.uiuc.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: voql@ivoa.net Subject: XSL Stylesheet to convert from ADQL to SQL Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_6433042280" Date: Mon, 09 Feb 2004 10:02:24 -0600 From: Ramon Williamson 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-voql@eso.org Precedence: bulk Reply-To: Ramon Williamson X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: This is a multipart MIME message. --==_Exmh_6433042280 Content-Type: text/plain; charset=us-ascii Hello. Ray Plante and I have created XSL stylesheets that will convert ADQL to SQL. Two files are included. The file adql2sql.xsl works on ADQL documents that conform to the lastest xsd posted on the voql twiki. The other stylesheet, adql2sql-ns.xsl, works with output from the JHU SQL-to-ADQL translator service (which recently added a namespace). We have tried to make the output SQL conform to standard SQL, with the intent that particular "flavors" of SQL could be added by overriding the templates that require changing in a new stylesheet that imports these standard SQL stylesheets. This has already been done for PostgreSQL here. Ramon Williamson --==_Exmh_6433042280 Content-Type: text/plain ; name="adql2sql-ns.xsl"; charset=us-ascii Content-Description: adql2sql-ns.xsl Content-Disposition: attachment; filename="adql2sql-ns.xsl" SELECT FROM TOP ORDER BY , * , AS , , , AND OR NOT ( ) REGION('Circle J2000 Cartesian ') XMATCH( ! , ) NOT LIKE NOT BETWEEN AND WHERE GROUP BY HAVING ( ) ( ) ALL DISTINCT . , --==_Exmh_6433042280 Content-Type: text/plain ; name="adql2sql.xsl"; charset=us-ascii Content-Description: adql2sql.xsl Content-Disposition: attachment; filename="adql2sql.xsl" SELECT FROM TOP ORDER BY , * , AS , , , AND OR NOT ( ) REGION('Circle J2000 Cartesian ') XMATCH( ! , ) NOT LIKE NOT BETWEEN AND WHERE GROUP BY HAVING ( ) ( ) ALL DISTINCT . , --==_Exmh_6433042280 Content-Type: text/plain; charset=us-ascii --- ############################################################################## Ramon L. Williamson II INTERNET: ramonw@ncsa.uiuc.edu Research Programmer Voice: (217) 244-4208 Radio Astronomy Imaging Team National Center for Supercomputing Applications (NCSA) I tried to learn the piano, but I was getting errors with #include. ***************************************************************************** --==_Exmh_6433042280-- From owner-voql@eso.org Mon Feb 9 18:08: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 i19H7rLW004513 for ; Mon, 9 Feb 2004 18:07:53 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19H7rUr004510 for voql-outgoing; Mon, 9 Feb 2004 18:07:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19H7kLW004466 for ; Mon, 9 Feb 2004 18:07:46 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19H7iWs003395 for ; Mon, 9 Feb 2004 18:07:44 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqEsp-00021T-JA for voql@ivoa.net; Mon, 09 Feb 2004 17:07:43 +0000 Received: (qmail 17827 invoked from network); 9 Feb 2004 17:08:04 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 17:08:04 -0000 From: "Tony Linde" To: Subject: RE: XSL Stylesheet to convert from ADQL to SQL Date: Mon, 9 Feb 2004 17:08:59 -0000 Organization: University of Leicester Message-ID: <00f701c3ef2f$68c5f110$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200402091602.i19G2Ov26996@jansky.ncsa.uiuc.edu> 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 i19H7qLW004498 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: But we need a complete *set* of schemas to create the ADQL: latest ADQL.xsd, coords.xsd and region.xsd. Can someone point us to the definitive downloads for all of these. Plus instructions on what needs to be done to 'fix' them to work in a local context. All I want to do is create a blank xml file in xmlspy, point it at the ADQL.xsd and have the software prompt me for the bits that need to be filled in. If we cannot do that, we aren't ready to even look at the ADQL proposal. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Ramon Williamson > Sent: 09 February 2004 16:02 > To: voql@ivoa.net > Subject: XSL Stylesheet to convert from ADQL to SQL > > > Hello. > > Ray Plante and I have created XSL stylesheets that will > convert ADQL to SQL. Two files are included. The file > adql2sql.xsl works on ADQL > documents that conform to the lastest xsd posted on the voql > twiki. The other > stylesheet, adql2sql-ns.xsl, works with output from the JHU > SQL-to-ADQL > translator service (which recently added a namespace). > > We have tried to make the output SQL conform to standard SQL, > with the intent > that particular "flavors" of SQL could be added by overriding > the templates > that require changing in a new stylesheet that imports these > standard SQL > stylesheets. This has already been done for PostgreSQL here. > > Ramon Williamson > > > From owner-voql@eso.org Mon Feb 9 18:12:48 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 i19HCWLW005613 for ; Mon, 9 Feb 2004 18:12:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19HCWlU005612 for voql-outgoing; Mon, 9 Feb 2004 18:12:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HCULW005604 for ; Mon, 9 Feb 2004 18:12:30 +0100 (MET) 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 SMTP id i19HCR4x017929 for ; Mon, 9 Feb 2004 18:12:28 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19HCNn28672; Mon, 9 Feb 2004 11:12:24 -0600 Date: Mon, 9 Feb 2004 11:12:23 -0600 (CST) From: Ray Plante To: Martin Hill cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: <40279956.70202@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Martin Hill wrote: > I'm pretty sure this is correct (standard) SQL: > > SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e > > I would expect that an SQL database will look at those ANDs and work out which > is the quickest set to solve first depending on internal indexing. > > However ADQL/XML (and SADQL v1.0!) only allow pairwise ANDs. When transforming > ADQL/XML -> Database SQL, we must use brackets around each boolean construct, > because we don't know what the original priority might have been, ie: > > WHERE (f OR f) AND (t OR t) = f > > is different from > > WHERE f OR (f AND t) OR t = t > > and as soon as we use brackets we lose multiple Unions/Intersections. As mentioned this is a question of precedence, so it's important to know what the standard says. The SQL-92 is a bit vague on the point of precedence between AND and OR. As best as I can follow the rules, AND & OR have equal precedence, and therefore (in the absence of parentheses) the precedence is left to right. That is, WHERE a OR b AND c OR d is equivalent to WHERE ((a OR b) AND c) OR d This is the precedence assumed by the JHU SQL->ADQL translator. (BTW, how it is actually evaluated is impl-dep, as long as the precedence is preserved.) It would be good if we could get a clarification from a standard-based document (i.e. not just a vendor-specific manual). I looked in Date & Darwin's "Guide to the SQL Standard" but could not find a definitive statement. Note that it is generally not a good idea, I believe, to insert parentheses unless they are actually needed (or explicitly specified by the user) as I think that this can degrade a database's ability to optimize the query. I could be wrong on this point. > On another point, isn't XOR a standard SQL boolean operator? It is *not* part of SQL-92. cheers, Ray From owner-voql@eso.org Mon Feb 9 18:25:05 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 i19HOpLW007958 for ; Mon, 9 Feb 2004 18:24:51 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19HOpr8007957 for voql-outgoing; Mon, 9 Feb 2004 18:24:51 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HOnLW007944 for ; Mon, 9 Feb 2004 18:24:49 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19HOlWs004248 for ; Mon, 9 Feb 2004 18:24:47 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 69BCE1C00312; Mon, 9 Feb 2004 17:24:46 +0000 (GMT) Message-ID: <4027C265.1010704@dial.pipex.com> Date: Mon, 09 Feb 2004 17:24:53 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante Cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hmm I haven't explained this very well and we seem to be getting diverted. My point is that ADQL/XML pair-only UnionSearch/IntersectionSearch impose precedence on statements like this: SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e when none is given in the original SQL, with implied performance loss at the SQL database. The other stuff was just to point out that it's not simple to remove the implied brackets at the ADQL/XML->SQL stage. I'm proposing that we give IntersectionSearch and UnionSearch from 2..unbound children so that ADQL/XML can in fact match SQL. Cheers, Martin Ray Plante wrote: > On Mon, 9 Feb 2004, Martin Hill wrote: > >>I'm pretty sure this is correct (standard) SQL: >> >>SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e >> >>I would expect that an SQL database will look at those ANDs and work out which >>is the quickest set to solve first depending on internal indexing. >> >>However ADQL/XML (and SADQL v1.0!) only allow pairwise ANDs. When transforming >> ADQL/XML -> Database SQL, we must use brackets around each boolean construct, >>because we don't know what the original priority might have been, ie: >> >> WHERE (f OR f) AND (t OR t) = f >> >>is different from >> >> WHERE f OR (f AND t) OR t = t >> >>and as soon as we use brackets we lose multiple Unions/Intersections. > > > As mentioned this is a question of precedence, so it's important to know > what the standard says. The SQL-92 is a bit vague on the point of > precedence between AND and OR. As best as I can follow the rules, AND & > OR have equal precedence, and therefore (in the absence of parentheses) > the precedence is left to right. That is, > > WHERE a OR b AND c OR d > > is equivalent to > > WHERE ((a OR b) AND c) OR d > > This is the precedence assumed by the JHU SQL->ADQL translator. > > (BTW, how it is actually evaluated is impl-dep, as long as the precedence > is preserved.) > > It would be good if we could get a clarification from a standard-based > document (i.e. not just a vendor-specific manual). I looked in Date & > Darwin's "Guide to the SQL Standard" but could not find a definitive > statement. > > Note that it is generally not a good idea, I believe, to insert > parentheses unless they are actually needed (or explicitly specified by > the user) as I think that this can degrade a database's ability to > optimize the query. I could be wrong on this point. > > >>On another point, isn't XOR a standard SQL boolean operator? > > > It is *not* part of SQL-92. > > cheers, > Ray > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 18:56: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 i19HtnLW014444 for ; Mon, 9 Feb 2004 18:55:49 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19HtnsX014443 for voql-outgoing; Mon, 9 Feb 2004 18:55:49 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HthLW014398 for ; Mon, 9 Feb 2004 18:55:43 +0100 (MET) 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 SMTP id i19HiJWs005060 for ; Mon, 9 Feb 2004 18:44:19 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19Hi9w29186; Mon, 9 Feb 2004 11:44:09 -0600 Date: Mon, 9 Feb 2004 11:44:09 -0600 (CST) From: Ray Plante To: Martin Hill cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: <4027C265.1010704@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Martin Hill wrote: > My point is that ADQL/XML pair-only UnionSearch/IntersectionSearch impose > precedence on statements like this: > > SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e > > when none is given in the original SQL, with implied performance loss at the SQL > database. The other stuff was just to point out that it's not simple to remove > the implied brackets at the ADQL/XML->SQL stage. I was about to suggest that you plug this into the JHU SQL to ADQL converter (http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx), but when I did it myself, it choked! Apparently, it doesn't like tables to be called "table". However, this works: SELECT * FROM tab t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e and it applies the precedence rule (left to right) that I describe earlier. does this do it? Ray From owner-voql@eso.org Mon Feb 9 18:56: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 i19HtwLW014518 for ; Mon, 9 Feb 2004 18:55:58 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19Htw6L014517 for voql-outgoing; Mon, 9 Feb 2004 18:55:58 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HthLa014398 for ; Mon, 9 Feb 2004 18:55:52 +0100 (MET) 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 SMTP id i19HVIWs004502 for ; Mon, 9 Feb 2004 18:31:18 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19HVH629180 for ; Mon, 9 Feb 2004 11:31:17 -0600 Date: Mon, 9 Feb 2004 11:31:17 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: RE: XSL Stylesheet to convert from ADQL to SQL In-Reply-To: <00f701c3ef2f$68c5f110$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Tony Linde wrote: > But we need a complete *set* of schemas to create the ADQL: latest ADQL.xsd, > coords.xsd and region.xsd. Can someone point us to the definitive downloads > for all of these. Plus instructions on what needs to be done to 'fix' them > to work in a local context. Here's where I understand the definitive versions are. The actual caretakers should correct me. ADQL: from the VOQL Twiki page, http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL, click, "Here is the latest ADQL XSD". This link currently goes to: http://skyservice.pha.jhu.edu/devel/AdqlTranslator/ADQLschema.xsd coords.xsd, region.xsd: The home page for STC is http://hea-www.harvard.edu/~arots/nvometa/SpaceTime.html The links to the schemas are found there. The specific URLs are: http://hea-www.harvard.edu/~arots/nvometa/coords.xsd http://hea-www.harvard.edu/~arots/nvometa/region.xsd As I mentioned in a previous post, if ADQL depends on STC, STC needs to start going through the standardization process. A good start would be to create a IVOA Twiki page for it. As for getting these schemas to work together, try downloading the STC schemas to the same directory as ADQLschema.xsd. Then edit the import statements in ADQLschema.xsd to add the attribute 'schemaLocation="coords.xsd"' and 'schemaLocation="region.xsd"'. One more comment (since you replied to the announcement of the stylesheet post): the stylesheet only supports a specific form of Circle. This is because the spec is unclear about the conversion of regions between ADQL and SkyQL. hope this helps, Ray From owner-voql@eso.org Mon Feb 9 18:56: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 i19HtsLW014478 for ; Mon, 9 Feb 2004 18:55:54 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19Htrq3014472 for voql-outgoing; Mon, 9 Feb 2004 18:55:53 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HthLY014398 for ; Mon, 9 Feb 2004 18:55:48 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19HV7Ws004481 for ; Mon, 9 Feb 2004 18:31:08 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqFFT-0003lo-3l for voql@ivoa.net; Mon, 09 Feb 2004 17:31:07 +0000 Received: (qmail 19641 invoked from network); 9 Feb 2004 17:31:13 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 17:31:13 -0000 From: "Tony Linde" To: Subject: RE: ADQL/XML non compliance with SQL? Date: Mon, 9 Feb 2004 17:32:09 -0000 Organization: University of Leicester Message-ID: <00f901c3ef32$a523dca0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: > Note that it is generally not a good idea, I believe, to insert > parentheses unless they are actually needed (or explicitly > specified by > the user) as I think that this can degrade a database's ability to If the ADQL/x structure does not *imply* brackets (which I thought it did), how are these designated in the spec? Is there a element? Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Ray Plante > Sent: 09 February 2004 17:12 > To: Martin Hill > Cc: voql@ivoa.net > Subject: Re: ADQL/XML non compliance with SQL? > ... From owner-voql@eso.org Mon Feb 9 18:57:06 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 i19HulLW014937 for ; Mon, 9 Feb 2004 18:56:47 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19Huljv014935 for voql-outgoing; Mon, 9 Feb 2004 18:56:47 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19HuYLW014852 for ; Mon, 9 Feb 2004 18:56:34 +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 SMTP id i19HuK4x020042 for ; Mon, 9 Feb 2004 18:56:24 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 958631C00125; Mon, 9 Feb 2004 17:56:19 +0000 (GMT) Message-ID: <4027C9CA.1090503@dial.pipex.com> Date: Mon, 09 Feb 2004 17:56:26 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ray Plante Cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Ray, As you put it yourself, should we be imposing these precedence rules? My understanding of SQL in practice is that statements with many sequential ANDs (or sequential ORs) are resolved at the database in the most efficent manner, rather than blindly left to right. Clive Page probably knows more about this. If this is so, I guess this means the discussion has changed to deciding between whether we 'stick rigorously to the SQL syntax' or 'interpret for practical cases'. Cheers, Martin Ray Plante wrote: > On Mon, 9 Feb 2004, Martin Hill wrote: > > >>My point is that ADQL/XML pair-only UnionSearch/IntersectionSearch impose >>precedence on statements like this: >> >> SELECT * FROM table t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e >> >>when none is given in the original SQL, with implied performance loss at the SQL >>database. The other stuff was just to point out that it's not simple to remove >>the implied brackets at the ADQL/XML->SQL stage. > > > I was about to suggest that you plug this into the JHU SQL to ADQL > converter (http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx), > but when I did it myself, it choked! Apparently, it doesn't like tables > to be called "table". However, this works: > > SELECT * FROM tab t WHERE t.i=t.z AND t.i=t.a AND t.b=t.e > > and it applies the precedence rule (left to right) that I describe > earlier. > > does this do it? > > Ray > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 19:11:39 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 i19IBELW017787 for ; Mon, 9 Feb 2004 19:11:14 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IBENf017782 for voql-outgoing; Mon, 9 Feb 2004 19:11:14 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IBBLW017772 for ; Mon, 9 Feb 2004 19:11:11 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19IB9Ws006380 for ; Mon, 9 Feb 2004 19:11:10 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqFsC-0006TD-N3 for voql@ivoa.net; Mon, 09 Feb 2004 18:11:08 +0000 Received: (qmail 23158 invoked from network); 9 Feb 2004 18:11:20 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 18:11:20 -0000 From: "Tony Linde" To: "'Ray Plante'" , Subject: RE: XSL Stylesheet to convert from ADQL to SQL Date: Mon, 9 Feb 2004 18:12:15 -0000 Organization: University of Leicester Message-ID: <00fc01c3ef38$3f851840$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: 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 i19IBDLW017779 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hi Ray, This gives the error I mentioned earlier, about q7:astronTimeTypeRelativeTime not being defined. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Ray Plante > Sent: 09 February 2004 17:31 > To: voql@ivoa.net > Subject: RE: XSL Stylesheet to convert from ADQL to SQL > > > On Mon, 9 Feb 2004, Tony Linde wrote: > > But we need a complete *set* of schemas to create the ADQL: latest > > ADQL.xsd, coords.xsd and region.xsd. Can someone point us to the > > definitive downloads for all of these. Plus instructions on > what needs > > to be done to 'fix' them to work in a local context. > > Here's where I understand the definitive versions are. The > actual caretakers should correct me. > > ADQL: > from the VOQL Twiki page, > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL, > click, "Here is the latest ADQL XSD". This link currently goes > to: > > http://skyservice.pha.jhu.edu/devel/AdqlTranslator/ADQLschema. xsd coords.xsd, region.xsd: The home page for STC is http://hea-www.harvard.edu/~arots/nvometa/SpaceTime.html The links to the schemas are found there. The specific URLs are: http://hea-www.harvard.edu/~arots/nvometa/coords.xsd http://hea-www.harvard.edu/~arots/nvometa/region.xsd As I mentioned in a previous post, if ADQL depends on STC, STC needs to start going through the standardization process. A good start would be to create a IVOA Twiki page for it. As for getting these schemas to work together, try downloading the STC schemas to the same directory as ADQLschema.xsd. Then edit the import statements in ADQLschema.xsd to add the attribute 'schemaLocation="coords.xsd"' and 'schemaLocation="region.xsd"'. One more comment (since you replied to the announcement of the stylesheet post): the stylesheet only supports a specific form of Circle. This is because the spec is unclear about the conversion of regions between ADQL and SkyQL. hope this helps, Ray From owner-voql@eso.org Mon Feb 9 19:13:51 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 i19IDWLW018329 for ; Mon, 9 Feb 2004 19:13:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IDWx6018327 for voql-outgoing; Mon, 9 Feb 2004 19:13:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IDPLW018301 for ; Mon, 9 Feb 2004 19:13:25 +0100 (MET) 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 SMTP id i19IDNWs006487 for ; Mon, 9 Feb 2004 19:13:24 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19IDMO30656 for ; Mon, 9 Feb 2004 12:13:23 -0600 Date: Mon, 9 Feb 2004 12:13:22 -0600 (CST) From: Ray Plante To: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? In-Reply-To: <4027C9CA.1090503@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Martin Hill wrote: > Hi Ray, > > As you put it yourself, should we be imposing these precedence rules? We should try to follow the SQL standard, whatever that is. > My > understanding of SQL in practice is that statements with many sequential ANDs > (or sequential ORs) are resolved at the database in the most efficent manner, > rather than blindly left to right. Clive Page probably knows more about this. I believe this is true. As I understand it, the DB may not strictly evaluate left to right for efficiency purposes; however, the final result must match according to the precedence rules. > If this is so, I guess this means the discussion has changed to deciding > between > whether we 'stick rigorously to the SQL syntax' or 'interpret for practical > cases'. If we need predictable behavior across all DBs and the SQL standard does not provide that, then we may need to apply the latter. cheers, Ray From owner-voql@eso.org Mon Feb 9 19:25:09 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 i19IOtLW020514 for ; Mon, 9 Feb 2004 19:24:55 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IOtcU020513 for voql-outgoing; Mon, 9 Feb 2004 19:24:55 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IOrLW020504 for ; Mon, 9 Feb 2004 19:24:53 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19IOpWs007045 for ; Mon, 9 Feb 2004 19:24:51 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqG5S-0007Rt-KA for voql@ivoa.net; Mon, 09 Feb 2004 18:24:50 +0000 Received: (qmail 24079 invoked from network); 9 Feb 2004 18:25:11 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 18:25:11 -0000 From: "Tony Linde" To: Subject: RE: ADQL/XML non compliance with SQL? Date: Mon, 9 Feb 2004 18:26:06 -0000 Organization: University of Leicester Message-ID: <010001c3ef3a$2ea89e50$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: 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-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Nearest BNF I could find included: ::= | OR ::= | AND ::= [ NOT ] ::= [ IS [ NOT ] ] ::= | Which would indicate that we ought to have and elements in the language for explicit setting of precedence. Cheers, Tony. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Ray Plante > Sent: 09 February 2004 18:13 > To: voql@ivoa.net > Subject: Re: ADQL/XML non compliance with SQL? > > > On Mon, 9 Feb 2004, Martin Hill wrote: > > > Hi Ray, > > > > As you put it yourself, should we be imposing these > precedence rules? > > We should try to follow the SQL standard, whatever that is. > > > My > > understanding of SQL in practice is that statements with > many sequential ANDs > > (or sequential ORs) are resolved at the database in the > most efficent manner, > > rather than blindly left to right. Clive Page probably > knows more about this. > > I believe this is true. As I understand it, the DB may not > strictly evaluate left to right for efficiency purposes; > however, the final result must match according to the > precedence rules. > > > If this is so, I guess this means the discussion has changed to > > deciding > > between > > whether we 'stick rigorously to the SQL syntax' or > 'interpret for practical > > cases'. > > If we need predictable behavior across all DBs and the SQL > standard does > not provide that, then we may need to apply the latter. > > cheers, > Ray > From owner-voql@eso.org Mon Feb 9 19:39:24 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 i19IdALW023153 for ; Mon, 9 Feb 2004 19:39:10 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IdAsP023152 for voql-outgoing; Mon, 9 Feb 2004 19:39:10 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19Id8LW023139 for ; Mon, 9 Feb 2004 19:39:08 +0100 (MET) 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 SMTP id i19Id64x021895 for ; Mon, 9 Feb 2004 19:39:06 +0100 (CET) Received: from localhost (rplante@localhost) by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i19Id3R31475; Mon, 9 Feb 2004 12:39:03 -0600 Date: Mon, 9 Feb 2004 12:39:03 -0600 (CST) From: Ray Plante To: Tony Linde cc: voql@ivoa.net Subject: RE: ADQL/XML non compliance with SQL? In-Reply-To: <00f901c3ef32$a523dca0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Ray Plante X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: On Mon, 9 Feb 2004, Tony Linde wrote: > If the ADQL/x structure does not *imply* brackets (which I thought it did), > how are these designated in the spec? Is there a element? In ADQL, the "ClosedExpression" type maps to (Expr). Ray From owner-voql@eso.org Mon Feb 9 19:40:46 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 i19IeWLW023466 for ; Mon, 9 Feb 2004 19:40:32 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IeWA3023464 for voql-outgoing; Mon, 9 Feb 2004 19:40:32 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IeULW023455 for ; Mon, 9 Feb 2004 19:40:30 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19IeSWs007743 for ; Mon, 9 Feb 2004 19:40:28 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 912771C00296; Mon, 9 Feb 2004 18:40:27 +0000 (GMT) Message-ID: <4027D423.9040402@dial.pipex.com> Date: Mon, 09 Feb 2004 18:40:35 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Linde Cc: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL? References: <010001c3ef3a$2ea89e50$6124d28f@STAR.LE.AC.UK> In-Reply-To: <010001c3ef3a$2ea89e50$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Or we can assume that the heirarchical structure of XML defines the precedence. ie put brackets around each search element. As you're all aware, I would hate to see ADQL get even more obfuscated... As Thomas McGlynn pointed out (in an email that I *think* was supposed to go the list), this whole thing is not important *if* we assume that the SQL database can ignore redundant brackets and work out the most efficient statement anyway. Tony Linde wrote: > Nearest BNF I could find included: > > ::= > > | OR > > ::= > > | AND > > ::= > [ NOT ] > > ::= > [ IS [ NOT ] > ] > > ::= > > | > > Which would indicate that we ought to have and > elements in the language for explicit setting of precedence. > > Cheers, > Tony. > > >>-----Original Message----- >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On >>Behalf Of Ray Plante >>Sent: 09 February 2004 18:13 >>To: voql@ivoa.net >>Subject: Re: ADQL/XML non compliance with SQL? >> >> >>On Mon, 9 Feb 2004, Martin Hill wrote: >> >> >>>Hi Ray, >>> >>>As you put it yourself, should we be imposing these >> >>precedence rules? >> >>We should try to follow the SQL standard, whatever that is. >> >> >>>My >>>understanding of SQL in practice is that statements with >> >>many sequential ANDs >> >>>(or sequential ORs) are resolved at the database in the >> >>most efficent manner, >> >>>rather than blindly left to right. Clive Page probably >> >>knows more about this. >> >>I believe this is true. As I understand it, the DB may not >>strictly evaluate left to right for efficiency purposes; >>however, the final result must match according to the >>precedence rules. >> >> >>>If this is so, I guess this means the discussion has changed to >>>deciding >>>between >>>whether we 'stick rigorously to the SQL syntax' or >> >>'interpret for practical >> >>>cases'. >> >>If we need predictable behavior across all DBs and the SQL >>standard does >>not provide that, then we may need to apply the latter. >> >>cheers, >>Ray >> > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 19:55: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 i19IsuLW026086 for ; Mon, 9 Feb 2004 19:54:56 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19Isu0e026085 for voql-outgoing; Mon, 9 Feb 2004 19:54:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IsrLW026077 for ; Mon, 9 Feb 2004 19:54:53 +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 SMTP id i19Isq4x022709 for ; Mon, 9 Feb 2004 19:54:52 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id E53621C002CC; Mon, 9 Feb 2004 18:54:51 +0000 (GMT) Message-ID: <4027D783.6000703@dial.pipex.com> Date: Mon, 09 Feb 2004 18:54:59 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: voql@ivoa.net Subject: Re: ADQL/XML non compliance with SQL not true... 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Aha! In that case I've been spreading FUD, sorry about that. Iff ClosedExpression specifies brackets then my original question has no meaning... Ray Plante wrote: > On Mon, 9 Feb 2004, Tony Linde wrote: > >>If the ADQL/x structure does not *imply* brackets (which I thought it did), >>how are these designated in the spec? Is there a element? > > > In ADQL, the "ClosedExpression" type maps to (Expr). > > Ray > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Mon Feb 9 19:59:51 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 i19IxbLW026999 for ; Mon, 9 Feb 2004 19:59:37 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19IxaFo026998 for voql-outgoing; Mon, 9 Feb 2004 19:59:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19IxYLW026990 for ; Mon, 9 Feb 2004 19:59:34 +0100 (MET) Received: from artemis.le.ac.uk (artemis.le.ac.uk [143.210.16.126]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19IxX4x022910 for ; Mon, 9 Feb 2004 19:59:33 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqGd2-0002OA-92 for voql@ivoa.net; Mon, 09 Feb 2004 18:59:32 +0000 Received: (qmail 26468 invoked from network); 9 Feb 2004 18:59:52 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 18:59:52 -0000 From: "Tony Linde" To: Subject: RE: ADQL/XML non compliance with SQL not true... Date: Mon, 9 Feb 2004 19:00:48 -0000 Organization: University of Leicester Message-ID: <010701c3ef3f$076a2200$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4027D783.6000703@dial.pipex.com> 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 i19IxaLW026995 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Yep - just tried it! With: Select t.a, g.d from Tab a, Tab d where a.d < d.e and (a.f < d.f or a.f=1.7) order by t.f, g.b into http://skyservice.pha.jhu.edu/devel/AdqlTranslator/Convertor.aspx T. > -----Original Message----- > From: owner-voql@eso.org [mailto:owner-voql@eso.org] On > Behalf Of Martin Hill > Sent: 09 February 2004 18:55 > To: voql@ivoa.net > Subject: Re: ADQL/XML non compliance with SQL not true... > > > Aha! In that case I've been spreading FUD, sorry about that. Iff > ClosedExpression specifies brackets then my original question > has no meaning... > > Ray Plante wrote: > > > On Mon, 9 Feb 2004, Tony Linde wrote: > > > >>If the ADQL/x structure does not *imply* brackets (which I > thought it > >>did), how are these designated in the spec? Is there a > >>element? > > > > > > In ADQL, the "ClosedExpression" type maps to (Expr). > > > > Ray > > > > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > From owner-voql@eso.org Mon Feb 9 22:25:43 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 i19LP7LW013258 for ; Mon, 9 Feb 2004 22:25:07 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19LP7nv013256 for voql-outgoing; Mon, 9 Feb 2004 22:25:07 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19LP2LW013214 for ; Mon, 9 Feb 2004 22:25:02 +0100 (MET) Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19LOuWs014688 for ; Mon, 9 Feb 2004 22:25:00 +0100 (CET) Received: from [143.210.36.58] (helo=mail.star.le.ac.uk) by artemis.le.ac.uk with smtp (Exim 4.30) id 1AqItj-0001Pf-Vm for voql@ivoa.net; Mon, 09 Feb 2004 21:24:55 +0000 Received: (qmail 4897 invoked from network); 9 Feb 2004 21:25:16 -0000 Received: from gnowee.star.le.ac.uk (HELO gnowee) (143.210.36.97) by mail.star.le.ac.uk with SMTP; 9 Feb 2004 21:25:16 -0000 From: "Tony Linde" To: Subject: Just make it work Date: Mon, 9 Feb 2004 21:26:11 -0000 Organization: University of Leicester Message-ID: <011501c3ef53$572432e0$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 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 i19LP6LW013249 Sender: owner-voql@eso.org Precedence: bulk Reply-To: "Tony Linde" X-Mozilla-Status: 8001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Can anyone tell me how to make ADQL work in xmlspy? I managed to get the schema to load by deleting all the coords/region stuff at the end - nothing seemed to be referencing it - at least xmlspy then said the schema was valid. I then created a new xml document based on the schema. Made 'Select' the root element. Xmlspy then offered me various child elements of Select: OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. I added Selection and it then told me the document was invalid: 'element Selection is undefined'!! Am I doing something wrong or is the ADQLschema.xsd simply invalid? Thanks, 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-voql@eso.org Mon Feb 9 22:43:13 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 i19LguLW021559 for ; Mon, 9 Feb 2004 22:42:57 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19Lgumd021558 for voql-outgoing; Mon, 9 Feb 2004 22:42:56 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19LgqLW021539 for ; Mon, 9 Feb 2004 22:42:52 +0100 (MET) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19LgoWs016726 for ; Mon, 9 Feb 2004 22:42:50 +0100 (CET) Received: from phd6.cs.jhu.edu (phd6.cs.jhu.edu [128.220.223.228]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id i19LhC8U011745; Mon, 9 Feb 2004 16:43:12 -0500 (EST) Received: from localhost (haridas@localhost) by phd6.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id i19Lhcr05587; Mon, 9 Feb 2004 16:43:38 -0500 (EST) Date: Mon, 9 Feb 2004 16:43:38 -0500 (EST) From: Vivek Haridas To: Tony Linde cc: Subject: Re: Just make it work In-Reply-To: <011501c3ef53$572432e0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Vivek Haridas X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, I am working on getting out an xsd working fine on xmlspy. Should be out soon, may be within a couple of hours. with Best Regards, Vivek Haridas On Mon, 9 Feb 2004, Tony Linde wrote: > Can anyone tell me how to make ADQL work in xmlspy? I managed to get the > schema to load by deleting all the coords/region stuff at the end - nothing > seemed to be referencing it - at least xmlspy then said the schema was > valid. > > I then created a new xml document based on the schema. Made 'Select' the > root element. Xmlspy then offered me various child elements of Select: > OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. I added > Selection and it then told me the document was invalid: 'element Selection > is undefined'!! > > Am I doing something wrong or is the ADQLschema.xsd simply invalid? > > Thanks, > 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-voql@eso.org Mon Feb 9 23:34:58 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 i19MYa8t000936 for ; Mon, 9 Feb 2004 23:34:36 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19MYaYk000935 for voql-outgoing; Mon, 9 Feb 2004 23:34:36 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19MYX8t000923 for ; Mon, 9 Feb 2004 23:34:33 +0100 (MET) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19MYVWs018730 for ; Mon, 9 Feb 2004 23:34:32 +0100 (CET) Received: from phd6.cs.jhu.edu (phd6.cs.jhu.edu [128.220.223.228]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id i19MYt8U018381; Mon, 9 Feb 2004 17:34:55 -0500 (EST) Received: from localhost (haridas@localhost) by phd6.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id i19MZL505696; Mon, 9 Feb 2004 17:35:21 -0500 (EST) Date: Mon, 9 Feb 2004 17:35:21 -0500 (EST) From: Vivek Haridas To: Tony Linde cc: Subject: Re: Just make it work In-Reply-To: <011501c3ef53$572432e0$6124d28f@STAR.LE.AC.UK> 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-voql@eso.org Precedence: bulk Reply-To: Vivek Haridas X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Tony, I have the xsd's posted on twiki. Here is the link to the main xsd. http://www.ivoa.net/internal/IVOA/IvoaVOQL/Main.xsd It imports from three other xsds: ADQL, Region and Coords. with Best Regards, Vivek Haridas On Mon, 9 Feb 2004, Tony Linde wrote: > Can anyone tell me how to make ADQL work in xmlspy? I managed to get the > schema to load by deleting all the coords/region stuff at the end - nothing > seemed to be referencing it - at least xmlspy then said the schema was > valid. > > I then created a new xml document based on the schema. Made 'Select' the > root element. Xmlspy then offered me various child elements of Select: > OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. I added > Selection and it then told me the document was invalid: 'element Selection > is undefined'!! > > Am I doing something wrong or is the ADQLschema.xsd simply invalid? > > Thanks, > 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-voql@eso.org Mon Feb 9 23:47: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 i19MlK8t002593 for ; Mon, 9 Feb 2004 23:47:20 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19MlKsZ002591 for voql-outgoing; Mon, 9 Feb 2004 23:47:20 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19MlH8t002574 for ; Mon, 9 Feb 2004 23:47:17 +0100 (MET) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19MlFWs019191 for ; Mon, 9 Feb 2004 23:47:15 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 394101C000BA; Mon, 9 Feb 2004 22:47:13 +0000 (GMT) Message-ID: <40280DF7.1060809@dial.pipex.com> Date: Mon, 09 Feb 2004 22:47:19 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vivek Haridas Cc: Tony Linde , voql@ivoa.net Subject: Re: Just make it work 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Thanks Vivek Can we version these please? I take it this is an update of version 0.6, so can we call it version ADQL-v0.61, or any other variation you're happy with. Otherwise it gets very difficult to build against them. Cheers, Martin Vivek Haridas wrote: > Tony, > > I have the xsd's posted on twiki. > Here is the link to the main xsd. > > http://www.ivoa.net/internal/IVOA/IvoaVOQL/Main.xsd > > It imports from three other xsds: ADQL, Region and Coords. > > with Best Regards, > Vivek Haridas > > > > On Mon, 9 Feb 2004, Tony Linde wrote: > > >>Can anyone tell me how to make ADQL work in xmlspy? I managed to get the >>schema to load by deleting all the coords/region stuff at the end - nothing >>seemed to be referencing it - at least xmlspy then said the schema was >>valid. >> >>I then created a new xml document based on the schema. Made 'Select' the >>root element. Xmlspy then offered me various child elements of Select: >>OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. I added >>Selection and it then told me the document was invalid: 'element Selection >>is undefined'!! >> >>Am I doing something wrong or is the ADQLschema.xsd simply invalid? >> >>Thanks, >>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/ >> >> > > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Tue Feb 10 00:04:25 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 i19N4C8t004754 for ; Tue, 10 Feb 2004 00:04:12 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19N4BZA004753 for voql-outgoing; Tue, 10 Feb 2004 00:04:11 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19N498t004743 for ; Tue, 10 Feb 2004 00:04:09 +0100 (MET) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19N464x003954 for ; Tue, 10 Feb 2004 00:04:07 +0100 (CET) Received: from phd6.cs.jhu.edu (phd6.cs.jhu.edu [128.220.223.228]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id i19N4R8U022192; Mon, 9 Feb 2004 18:04:27 -0500 (EST) Received: from localhost (haridas@localhost) by phd6.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id i19N4qT05722; Mon, 9 Feb 2004 18:04:53 -0500 (EST) Date: Mon, 9 Feb 2004 18:04:52 -0500 (EST) From: Vivek Haridas To: Martin Hill cc: Tony Linde , Subject: Re: Just make it work In-Reply-To: <40280DF7.1060809@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Vivek Haridas X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, I have named it as V0.8 in the xsd's namespace. The last ADQL document revision was 0.7.1, I think. So, Thought better to have it as 0.8 to start clean. I should soon get the ADQL Translator Service at Hopkins to work with it. Also, Java source files along with a test application to use the translator will be posted. with Best Regards, Vivek On Mon, 9 Feb 2004, Martin Hill wrote: > Thanks Vivek > > Can we version these please? I take it this is an update of version 0.6, so can > we call it version ADQL-v0.61, or any other variation you're happy with. > Otherwise it gets very difficult to build against them. > > Cheers, > > Martin > > Vivek Haridas wrote: > > > Tony, > > > > I have the xsd's posted on twiki. > > Here is the link to the main xsd. > > > > http://www.ivoa.net/internal/IVOA/IvoaVOQL/Main.xsd > > > > It imports from three other xsds: ADQL, Region and Coords. > > > > with Best Regards, > > Vivek Haridas > > > > > > > > On Mon, 9 Feb 2004, Tony Linde wrote: > > > > > >>Can anyone tell me how to make ADQL work in xmlspy? I managed to get the > >>schema to load by deleting all the coords/region stuff at the end - nothing > >>seemed to be referencing it - at least xmlspy then said the schema was > >>valid. > >> > >>I then created a new xml document based on the schema. Made 'Select' the > >>root element. Xmlspy then offered me various child elements of Select: > >>OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. I added > >>Selection and it then told me the document was invalid: 'element Selection > >>is undefined'!! > >> > >>Am I doing something wrong or is the ADQLschema.xsd simply invalid? > >> > >>Thanks, > >>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/ > >> > >> > > > > > > -- > Martin Hill > Software Engineer > AstroGrid @ ROE > Tel: +44 7901 55 24 66 > www.astrogrid.org > From owner-voql@eso.org Tue Feb 10 00:04:58 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 i19N4j8t004832 for ; Tue, 10 Feb 2004 00:04:45 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19N4j0B004831 for voql-outgoing; Tue, 10 Feb 2004 00:04:45 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19N4g8t004819 for ; Tue, 10 Feb 2004 00:04:42 +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 SMTP id i19N4f4x003973 for ; Tue, 10 Feb 2004 00:04:41 +0100 (CET) Received: from dial.pipex.com (81-86-233-7.dsl.pipex.com [81.86.233.7]) by shockwave.systems.pipex.net (Postfix) with ESMTP id DEEB61C00128; Mon, 9 Feb 2004 23:04:40 +0000 (GMT) Message-ID: <4028120E.2040707@dial.pipex.com> Date: Mon, 09 Feb 2004 23:04:46 +0000 From: Martin Hill User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: voql@ivoa.net Subject: Re: Just make it work - naming and versioning... References: <40280DF7.1060809@dial.pipex.com> In-Reply-To: <40280DF7.1060809@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Martin Hill X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Hmmm in fact does this count as being the new ADQL, as I take it we submit documents conforming to this 'wrapping' schema to datacenters/skynodes? Anyway XML Spy still can't find ADQL.xsd from: Is there really a v0.8? Where would we find one to download? Or am I just too eager and it's not available yet?! Thanks for this work though! Martin Martin Hill wrote: > Thanks Vivek > > Can we version these please? I take it this is an update of version 0.6, > so can we call it version ADQL-v0.61, or any other variation you're > happy with. Otherwise it gets very difficult to build against them. > > Cheers, > > Martin > > Vivek Haridas wrote: > >> Tony, >> >> I have the xsd's posted on twiki. >> Here is the link to the main xsd. >> >> http://www.ivoa.net/internal/IVOA/IvoaVOQL/Main.xsd >> >> It imports from three other xsds: ADQL, Region and Coords. >> >> with Best Regards, >> Vivek Haridas >> >> >> >> On Mon, 9 Feb 2004, Tony Linde wrote: >> >> >>> Can anyone tell me how to make ADQL work in xmlspy? I managed to get the >>> schema to load by deleting all the coords/region stuff at the end - >>> nothing >>> seemed to be referencing it - at least xmlspy then said the schema was >>> valid. >>> >>> I then created a new xml document based on the schema. Made 'Select' the >>> root element. Xmlspy then offered me various child elements of Select: >>> OptionalAllOrDistinct, OptionalTop, Selection, TableClause, OrderBy. >>> I added >>> Selection and it then told me the document was invalid: 'element >>> Selection >>> is undefined'!! >>> >>> Am I doing something wrong or is the ADQLschema.xsd simply invalid? >>> >>> Thanks, >>> 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/ >>> >>> >> >> > -- Martin Hill Software Engineer AstroGrid @ ROE Tel: +44 7901 55 24 66 www.astrogrid.org From owner-voql@eso.org Tue Feb 10 00:17:54 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 i19NHe8t006598 for ; Tue, 10 Feb 2004 00:17:40 +0100 (MET) Received: (from majordomo@localhost) by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i19NHe5O006597 for voql-outgoing; Tue, 10 Feb 2004 00:17:40 +0100 (MET) X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-voql@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 i19NHb8t006584 for ; Tue, 10 Feb 2004 00:17:37 +0100 (MET) Received: from blaze.cs.jhu.edu (blaze.cs.jhu.edu [128.220.13.50]) by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i19NHZ4x004338 for ; Tue, 10 Feb 2004 00:17:35 +0100 (CET) Received: from phd6.cs.jhu.edu (phd6.cs.jhu.edu [128.220.223.228]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id i19NHv8U023686; Mon, 9 Feb 2004 18:17:57 -0500 (EST) Received: from localhost (haridas@localhost) by phd6.cs.jhu.edu (8.11.1/8.11.1) with ESMTP id i19NIMD05735; Mon, 9 Feb 2004 18:18:23 -0500 (EST) Date: Mon, 9 Feb 2004 18:18:22 -0500 (EST) From: Vivek Haridas To: Martin Hill cc: Subject: Re: Just make it work - naming and versioning... In-Reply-To: <4028120E.2040707@dial.pipex.com> 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-voql@eso.org Precedence: bulk Reply-To: Vivek Haridas X-Mozilla-Status: 8011 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Martin, These are the xsds. http://www.ivoa.net/internal/IVOA/IvoaVOQL/Main.xsd http://www.ivoa.net/internal/IVOA/IvoaVOQL/ADQL.xsd http://www.ivoa.net/internal/IVOA/IvoaVOQL/Region.xsd http://www.ivoa.net/internal/IVOA/IvoaVOQL/Coords.xsd with Best Regards, Vivek On Mon, 9 Feb 2004, Martin Hill wrote: > Hmmm in fact does this count as being the new ADQL, as I take it we submit > documents conforming to this 'wrapping' schema to datacenters/skynodes? > > Anyway XML Spy still can't find ADQL.xsd from: > > > > Is there really a v0.8? Where would we find one to download? Or am I just too > eager and it's not available yet?! > > Thanks for this work though! > > Martin > > Martin Hill wrote: > > > Thanks Vivek > > > > Can we version these please? I take it this is an update of version 0.6, > > so can we call it version ADQL-v0.61, or any other variation you're > > happy with. Otherwise it gets very difficult to build against them. > > > > Cheers, > > > > Martin