/[volute]/trunk/projects/dal/AccessData/AccessData.tex
ViewVC logotype

Diff of /trunk/projects/dal/AccessData/AccessData.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 3182 by francois, Mon Dec 14 11:08:49 2015 UTC revision 3183 by francois, Mon Dec 14 14:56:17 2015 UTC
# Line 7  Line 7 
7  showstringspaces=False}  showstringspaces=False}
8  \usepackage{todonotes}  \usepackage{todonotes}
9    
10  \title{IVOA AccessData}  \title{IVOA Server-side Operations for Data Access}
11    
12  \ivoagroup{DAL}  \ivoagroup{DAL}
13    
14  \author{TBD}  \author{Fran\c cois Bonnarel, Markus Demleitner, Patrick Dowler, Douglas Tody }
15    
16  \editor{TBD}  \editor{Fran\c cois Bonnarel}
17    
18  \previousversion{WD-AccessData-1.0-20151021}  \previousversion{WD-AccessData-1.0-20151021}
19  \previousversion{WD-AccessData-1.0-20140730}  \previousversion{WD-AccessData-1.0-20140730}
# Line 23  Line 23 
23  \begin{document}  \begin{document}
24    
25  \begin{abstract}  \begin{abstract}
26  This document describes the AccessData web service  This document describes the SODA web service capability. SODA is a low-level data access capability or server side data processing that can act upon the data files, performing various kinds of operations: filtering/subsection, transformations, pixel operations, and applying functions to the data.
 capability. AccessData is a low-level data access capability  
 or server side data processing that can act upon the data  
 files, performing various kinds of operations:  
 filtering/subsection, transformations, pixel operations, and  
 applying functions to the data.  
27    
28  \end{abstract}  \end{abstract}
29    
# Line 38  Line 33 
33  contributions to this document.  contributions to this document.
34    
35  \section{Introduction}  \section{Introduction}
36  The AccessData web service interface defines a RESTful web  The SODA web service interface defines a RESTful web service for performing server-side operations and processing on data before transfer.
37  service for performing server-side operations and processing  
 on data before transfer.  
38    
39  \subsection{The Role in the IVOA Architecture}  \subsection{The Role in the IVOA Architecture}
40    
41    
42    
43    
44  TODO: new diagram from TCG  TODO: new diagram from TCG
45    
46  AccessData services conform to the Data Access  SODA services conform to the Data Access
47  layer Interface \citep{std:DALI} specification, including the  layer Interface \citep{std:DALI} specification, including the
48  Virtual Observatory Support Interfaces \citep{std:VOSI} resources.  Virtual Observatory Support Interfaces \citep{std:VOSI} resources.
49    
50  \subsection{Motivating Use Cases}  \subsection{Motivating Use Cases}
51    Below are some of the more common use cases that have motivated the development of the SODA specification. While this is not complete, it helps to understand the problem area covered by this specification.
 Below are some of the more common use cases that have  
 motivated the development of the AccessData specification.  
 While this is not complete, it helps to understand the  
 problem area covered by this specification.  
52    
53  \subsubsection{Retrieve Subsection of a Datacube}  \subsubsection{Retrieve Subsection of a Datacube}
54  \label{sect:use-cube}  \label{sect:use-cube}
55    
56  Cutout a subsection using coordinate axis values. The input  Cutout a subsection using coordinate axis values. The input to the cutout operation will include one or more of the following:
57  to the cutout operation will include one or more of the  
 following:  
58    
59  \begin{itemize}  \begin{itemize}
60  \item a region on the sky  \item a region on the sky
# Line 83  Line 75 
75  This is a special case of \ref{sect:use-cube},  This is a special case of \ref{sect:use-cube},
76  where the cutout is only in the spectral axis.  where the cutout is only in the spectral axis.
77    
78    \subsection{Provide the data in different formats}
79    
80    Examples are images in PNG, or JPEG instead of FITS and spectra in csv, FITS or VOTable.    
81    
82  \subsubsection{Flatten a Datacube into a 2D Image}  \subsubsection{Flatten a Datacube into a 2D Image}
83    
84  This use case will be developed and supported in the  This use case will be developed and supported in the
85  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
86    
87  \subsubsection{Flatten a Datacube into a 1D Spectrum}  \subsubsection{Flatten a Datacube into a 1D Spectrum}
88    
89  This use case will be developed and supported in the  This use case will be developed and supported in the
90  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
91    
92  \subsubsection{Rebin Data by a Fixed Factor}  \subsubsection{Rebin Data by a Fixed Factor}
93    
94  This use case will be developed and supported in the  This use case will be developed and supported in the
95  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
96    
97  \subsubsection{Reproject Data onto a Specified Grid}  \subsubsection{Reproject Data onto a Specified Grid}
98    
99  This use case will be developed and supported in the  This use case will be developed and supported in the
100  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
101    
102  \subsubsection{Compute Aggregate Functions over the Data}  \subsubsection{Compute Aggregate Functions over the Data}
103    
104  This use case will be developed and supported in the  This use case will be developed and supported in the
105  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
106    
107    
108  \subsubsection{Apply Standard Function to Data Values}  \subsubsection{Apply Standard Function to Data Values}
109    
110  This use case will be developed and supported in the  It could be
111  AccessData-1.1 (or later) specification.  
112    
113    denoising" with standard methods or "on the fly" recalibration. This use case will be developed and supported in the
114    SODA-1.1 (or later) specification.
115    
116  \subsubsection{Apply Arbitrary User-Specified Function to Data Values}  \subsubsection{Apply Arbitrary User-Specified Function to Data Values}
117    
118  This use case will be developed and supported in the  This use case will be developed and supported in the
119  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
120    
121  \subsubsection{Run Arbitrary User-Supplied Code on the Data}  \subsubsection{Run Arbitrary User-Supplied Code on the Data}
122    
123  This use case will be developed and supported in the  This use case will be developed and supported in the
124  AccessData-1.1 (or later) specification.  SODA-1.1 (or later) specification.
125    
126  \section{Resources}  \section{Resources}
127    
128  AccessData services are implemented as HTTP REST \citep{richardson07} web  SODA services are implemented as HTTP REST \citep{richardson07} web
129  services with a \{sync\} resource that conforms to the DALI-  services with a \{sync\} resource that conforms to the DALI-
130  sync resource description.  sync resource description.
131    
# Line 145  Line 144 
144  \caption{Endpoints for AccessData services}  \caption{Endpoints for AccessData services}
145  \end{table}  \end{table}
146    
147  A stand-alone AccessData service may have one or both of the  A stand-alone SODA service may have one or both of the \{sync\} and \{async\} resources. For either type, it could have multiple resources (e.g. to support alternate authentication schemes). The SODA service may also include other custom or supporting resources.
148  \{sync\} and \{async\} resources. For either type, it could have  
149  multiple resources (e.g. to support alternate authentication  Either the \{sync\} or \{async\} SODA capability may be included as part of other web services. For example, a single web service could contain the SIA-2.0 \{query\} capability, the DataLink-1.0 \{links\} capability, and the SODA \{sync\} capability. Such a service must also have the VOSI-availability and VOSI-capabilities resources to report on and describe all the implemented capabilities.
 schemes). The AccessData service may also include other  
 custom or supporting resources.  
   
 Either the \{sync\} or \{async\} AccessData capability may be  
 included as part of other web services. For example, a  
 single web service could contain the SIA-2.0 {query}  
 capability, the DataLink-1.0 \{links\} capability, and the  
 AccessData \{sync\} capability. Such a service must also have  
 the VOSI-availability and VOSI-capabilities resources to  
 report on and describe all the implemented capabilities.  
150    
151  \subsection{\{sync\} resource}  \subsection{\{sync\} resource}
152    
# Line 206  Line 195 
195    
196  \subsection{Availability: VOSI-availability}  \subsection{Availability: VOSI-availability}
197    
198  An AccessData web service must have a VOSI-availability  A SODA web service must have a VOSI-availability
199  resource \citep{std:VOSI} as described in DALI \citep{std:DALI}.  resource \citep{std:VOSI} as described in DALI \citep{std:DALI}.
200    
201  \subsection{Capabilities: VOSI-capabilities}  \subsection{Capabilities: VOSI-capabilities}
202    
203  A web service that includes AccessData capabilities must  A web service that includes SODA capabilities must
204  have a VOSI-capabilities resource \citep{std:VOSI} as described in DALI  have a VOSI-capabilities resource \citep{std:VOSI} as described in DALI
205  \citep{std:DALI}. The standardID for the \{sync\} resource is  \citep{std:DALI}. The standardID for the \{sync\} resource is
206  $$\hbox{\texttt{ivo://ivoa.net/std/AccessData\#sync}.}$$  $$\hbox{\texttt{ivo://ivoa.net/std/SODA\#sync}.}$$
207    
208  The standardID for the \{async\} resource is  The standardID for the \{async\} resource is
209    
210  $$\hbox{\texttt{ivo://ivoa.net/std/AccessData\#async}.}$$  $$\hbox{\texttt{ivo://ivoa.net/std/SODA\#async}.}$$
211    
212  All DAL services must implement the \texttt{/capabilities} resource.  All DAL services must implement the \texttt{/capabilities} resource.
213  The following capabilities document shows the minimal  The following capabilities document shows the minimal
214  metadata for a stand-alone AccessData service and does not  metadata for a stand-alone SODA service and does not
215  require a registry extension schema:  require a registry extension schema:
216    
217  \begin{lstlisting}[language=XML]  \begin{lstlisting}[language=XML]
# Line 243  Line 232 
232        </accessURL>        </accessURL>
233      </interface>      </interface>
234    </capability>    </capability>
235    <capability standardid="ivo://ivoa.net/std/AccessData#sync">    <capability standardid="ivo://ivoa.net/std/SODA#sync">
236      <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">      <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
237        <accessurl use="full">        <accessurl use="full">
238          http://example.com/data/sync          http://example.com/data/sync
# Line 251  Line 240 
240      </interface>      </interface>
241      <!-- service details from extension schema could go here -->      <!-- service details from extension schema could go here -->
242    </capability>    </capability>
243    <capability standardid="ivo://ivoa.net/std/AccessData#async">    <capability standardid="ivo://ivoa.net/std/SODA#async">
244      <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">      <interface xsi:type="vod:ParamHTTP" role="std" version="1.0">
245        <accessurl use="full">        <accessurl use="full">
246          http://example.com/data/async          http://example.com/data/async
# Line 276  Line 265 
265  The \{sync\} and \{async\} resources accept the same set of  The \{sync\} and \{async\} resources accept the same set of
266  parameters.  parameters.
267    
268  \subsection{Parameter description}  \subsection{Parameter description: : 3 factor semantics}
269    Each SODA input parameter follows a generic rule  of semantic description  by three attributes: name, ucd -identifying the queried astronomical quantity-, and unit. With this three factors it is  possible in principal to identify the nature and the style of the parameters. This also achieve  overall consistency between input parameters and the VOTable PARAM element.     Datatype and  xtype attributes come to complete the definition of the value type and format.
270  The input parameters defined in this section are fully  The input parameters listed and defined in this section are fully described according to this rule. However these parameters should also be described this way each time the service is invocated with an empty request (see below \ref{sect:serv-desc}). Custom parameters of the service, if any, MUST be described  in the same way.
 described. However these parameters should also be described  
 each time the service is invocated. The DataLink  
 specification \citep{std:Datalink} defines a general mechanism for a ``service  
 descriptor'' which is plainly relevant to describe an  
 AccessData service in the response of a data discovery  
 service. Any occurrence of the service descriptor for an  
 AccessData service SHOULD contain the description of these  
 parameters. Each input parameter is described by a PARAM  
 element with a MANDATORY occurrence of the 3 following  
 attributes: datatype, ucd, unit. The xtype attribute is  
 useful and recommended for several parameters. Datatype is  
 one of the basic VOTABLE types. For string syntax parameters  
 it will be char. UCD will identify the astronomical quantity  
 queried via this parameter. The unit is relative to the  
 values of the PARAMETER. In the case of string-syntax  
 parameters of datatype char, there is generally no unit. The  
 xtype value is chosen in a set of complex types defined by a  
 BNF syntax and described in the Appendix. \todo{Do we keep  
 that?}  
271    
 Custom parameters of the service, if any, MUST be described  
 in the same way.  
272    
273  \subsection{Common Parameters}  \subsection{Common Parameters}
274    
# Line 310  Line 278 
278  be accessed. The values for the ID parameter are generally  be accessed. The values for the ID parameter are generally
279  discovered from data discovery or DataLink requests. The  discovered from data discovery or DataLink requests. The
280  values must be treated as opaque identifiers that are used  values must be treated as opaque identifiers that are used
281  as-is. The DataLink specification [8] describes mechanisms  as-is. The DataLink specification  \citep{std:DataLink} describes mechanisms
282  for conveying opaque parameters and values in service  for conveying opaque parameters and values in service
283  descriptor resources that can be used by clients to set the  descriptor resources that can be used by clients to set the
284  ID parameter.  ID parameter.
285    
286  The ID parameter is single-valued in \{sync\} requests, so  The ID parameter is single-valued in \{sync\} requests, so
287  \{sync\} access data requests access a single dataset or file.  \{sync\} soda requests access a single dataset or file.
288  Multiple ID parameters may be submitted in \{async\} requests  Multiple ID parameters may be submitted in \{async\} requests
289  on order to bundle access to multiple datasets or files in a  on order to bundle access to multiple datasets or files in a
290  single job.  single job.
291    
292  The ID parameter datatype is ``char'', its ucd is ``'', its  
293  xtype is ``ivoident'' and its unit is blank.  The ID  ucd is “meta.id”, and its unit is blank.
294    In addition its  xtype is “ivoident” and its datatype "char".
295    
296    
297  \subsection{Filtering Parameters}  \subsection{Filtering Parameters}
298    
# Line 357  Line 327 
327  \caption{POS Values in Spherical Coordinates}  \caption{POS Values in Spherical Coordinates}
328  \end{table}  \end{table}
329    
330  Unlimited value is coded by NaN.  Unlimited value is coded by -Inf or +Inf.
331    
332  A circle at (12,34) with radius 0.5:  A circle at (12,34) with radius 0.5:
333    
# Line 391  Line 361 
361  The north pole:  The north pole:
362    
363  \begin{lstlisting}  \begin{lstlisting}
364  POS=RANGE 0 360 89 NaN  POS=RANGE 0 360 89 +Inf
365  \end{lstlisting}  \end{lstlisting}
366    
367  This syntax is in the same style as STC-S, but with no  This syntax is in the same style as STC-S, but with no
# Line 402  Line 372 
372  CIRCLE) are expressed in degrees in the ICRS. A future  CIRCLE) are expressed in degrees in the ICRS. A future
373  version of this specification may allow the use of other  version of this specification may allow the use of other
374  reference systems (specifically the native system of the  reference systems (specifically the native system of the
375  data).\todo{Put an explicit and suitable reference system and STC  data).
 ref here...consistent with the language in SIA-2.0 \{query\}.}  
376    
377  The POS parameter is single-valued for \{sync\} requests and  The POS parameter is single-valued for \{sync\} requests and
378  multi-valued for \{async\} jobs.  multi-valued for \{async\} jobs.
379    
380  The datatype of the POS parameter is ``char'', the VOTABLE  The unit of POS is "deg" and the ucd is "pos". However the datatype of the POS parameter is “char”, and the xtype can take one of the three values “circle”, “range” and “polygon” as defined in DALI.
 unit is ``none'' (but the underlying unit is assumed to be  
 "deg"), the ucd is ``pos'' and the xtype can take one of the  
 three values ``circle'', ``range'' and ``polygon''.  
381    
382  \subsubsection{BAND}  \subsubsection{BAND}
383    
# Line 419  Line 385 
385  extracted from the data. The value is an open or closed  extracted from the data. The value is an open or closed
386  numeric interval of values in the native spectral axis  numeric interval of values in the native spectral axis
387  coordinate system and units of the data. The intervals  coordinate system and units of the data. The intervals
388  always include the bounding values.  always include the bounding values. Unlimited values are coded by +Inf or -Inf.
389    
390  If there is one single value the interval is assumed to be  If there is one single value the interval is assumed to be
391  infinitely small (a scalar value).  infinitely small (a scalar value).
# Line 433  Line 399 
399  The open interval (-inf,300]:  The open interval (-inf,300]:
400    
401  \begin{lstlisting}  \begin{lstlisting}
402  BAND=NaN 300  BAND=-Inf 300
403  \end{lstlisting}  \end{lstlisting}
404    
405  The open interval [750,inf):  The open interval [750,inf):
406    
407  \begin{lstlisting}  \begin{lstlisting}
408  BAND=750 NaN  BAND=750 +Inf
409  \end{lstlisting}  \end{lstlisting}
410    
411  The scalar value 550, equivalent to [550,550]:  The scalar value 550, equivalent to [550,550]:
# Line 460  Line 426 
426  The BAND parameter is single-valued for \{sync\} requests and  The BAND parameter is single-valued for \{sync\} requests and
427  multi-valued for \{async\} jobs.  multi-valued for \{async\} jobs.
428    
429  The datatype of the BAND parameter is ``double'', the ucd is  The ucd of the BAND parameter is “em”, the unit is “m”. Its datatype id double and the xtype is “interval” as defined in DALI.
430  ``em'', the unit is ``m'' and the xtype is ``interval''.  
431    
432  \subsubsection{TIME}  \subsubsection{TIME}
433    
434  The TIME parameter defines the time interval(s) to be  The TIME parameter defines the time interval(s) to be
435  extracted from the data. The value is an open or closed  extracted from the data. The value is an open or closed
436  interval with either numeric values (interpreted as Modified  interval with either numeric values (interpreted as Modified
437  Julian Dates).  Julian Dates). Unlimited values are coded by +Inf or -Inf.
438    
439  If there is one single value the numeric interval is assumed  If there is one single value the numeric interval is assumed
440  to be infinitely small (a scalar value).  to be infinitely small (a scalar value).
# Line 476  Line 442 
442  An open interval from the MJD 55100.0 and all later times:  An open interval from the MJD 55100.0 and all later times:
443    
444  \begin{lstlisting}  \begin{lstlisting}
445  TIME= 55100.0 NaN  TIME= 55100.0 +Inf
446  \end{lstlisting}  \end{lstlisting}
447    
448  A range of MJD values:  A range of MJD values:
# Line 491  Line 457 
457  TIME=55678.123456  TIME=55678.123456
458  \end{lstlisting}  \end{lstlisting}
459    
460  Time values are always UTC.\todo{put an explicit and suitable reference system and STC  Time values are always UTC.
 ref here... Arnold?}  
   
461  The TIME parameter is single-valued for \{sync\} requests and  The TIME parameter is single-valued for \{sync\} requests and
462  multi-valued for \{async\} jobs.  multi-valued for \{async\} jobs.
463    
464  The datatype of the TIME parameter is ``double'', the ucd is  The ucd of the TIME parameter is “time” and the unit is "day". The datatype is "double" and the xtype is, again, "interval" as defined in DALI
465  ``time'' and the xtype is ``interval''. The unit is day.  
466    
467  \subsubsection{POL}  \subsubsection{POL}
468    
# Line 529  Line 493 
493  result with some or all of these polarization states (per  result with some or all of these polarization states (per
494  combination of ID and other filtering parameters).</p>  combination of ID and other filtering parameters).</p>
495    
496  The datatype for the POL parameter is ``char", the ucd is  The ucd of the POL PARAMETER is "pol" and the unit is none. The datatype  is “char", and the xtype is “stokes”.
 ``pol''. the xtype is ``stokes''. The unit is blank.  
   
 \subsubsection{COORD}  
   
 The COORD parameter is used to extract a range of values  
 from an arbitrary coordinate axis. The value is made up of  
 an axis name and a numeric interval. The axis names must be  
 obtained from the detailed metadata for the dataset. This  
 coordinate axis can be an additional observation axis (such  
 as redshift for example) or an axis defined in a simulation  
 for a result dataset.  
   
 Extract from 20 to 40 along the foo axis:  
497    
 \begin{lstlisting}  
 COORD=foo 20 40  
 \end{lstlisting}  
   
 Extract from 20 to 40 in foo, bar larger than 50, and two  
 slices in baz:  
   
 \begin{lstlisting}  
 COORD=foo 20 40  
 COORD=bar 50  
 COORD=baz 1 2  
 COORD=baz 8 9  
 \end{lstlisting}  
498    
 The COORD parameter as defined here is limited to ranges of  
 scalar values. It is intended for use with highly processed  
 datasets that do not have normal physical axes that can be  
 interpreted using the POS, BAND, TIME, and POL parameters,  
 such as simulations (and it could be applied to tables or  
 catalogues, although those might be better served via TAP  
 \citep{std:TAP}).  
   
 Note: The scalar range parameters for observational data  
 (BAND, TIME, POL) could be expressed using the COORD  
 parameter. For example, the following could be equivalent:  
   
 \begin{lstlisting}  
 BAND=500 550  
 COORD=WAVE 500 550  
 \end{lstlisting}  
   
 The COORD PARAMETER has a ``char`` datatype, the ucd is undefined as well as the unit.  
   
 \subsubsection{SELECT}  
   
 The SELECT parameter is used to select a subset of the  
 observable values (properties or attributes). Normally,  
 observational data has a single value (typically an  
 intensity) at each sampled coordinate (pixel) and the SELECT  
 parameter is not used. However, for datasets produced from  
 arbitrary computations, including theoretical simulations,  
 there can be many properties for every sample (grid cell,  
 particle for n-body, etc.); in this case the SELECT  
 parameter lets the client extract a subset of the  
 properties.  
   
 The value for the SELECT parameter is the name of the  
 property to be extracted. The parameter is multi-valued, so  
 extracting multiple properties requires the use of multiple  
 parameters.  
   
   
 Extract the luminosity:  
 \begin{lstlisting}  
 SELECT=luminosity  
 \end{lstlisting}  
   
 Extract several properties:  
 \begin{lstlisting}  
 SELECT=temperature  
 SELECT=density  
 SELECT=pressure  
 SELECT=Fe_H  
 SELECT=HeIII  
 \end{lstlisting}  
   
 The SELECT PARAMETER has ``char'' datatype, the ucd is ``phys'', the unit is  
 blank and the xtype is ``quantity''.  
   
 \subsection{Transformation Parameters}  
   
 Transformations will be defined in a future version of  
 AccessData.  
499    
500  \section{\{sync\} Responses}  \section{\{sync\} Responses}
501    
502  All responses from the \{links\}\todo{that should be \{sync\}, no? --  All responses from the \{sync\} resource follow the rules for
503  Markus} resource follow the rules for  DALI-sync resources, except that the \{sync\} response allows
 DALI-sync resources, except that the \{links\} response allows  
504  for error messages for individual input identifier values.  for error messages for individual input identifier values.
505    
506  \subsection{Successful Requests}  \subsection{Successful Requests}
# Line 656  Line 534 
534  set.\todo{If we say that, we should at least mention chunked transfers, or  set.\todo{If we say that, we should at least mention chunked transfers, or
535  people might think they have to close the connections. -- Markus}  people might think they have to close the connections. -- Markus}
536    
537  \subsection{AccessData Service Descriptor}  \subsection{SODA Service Descriptor}
538    \label{sect: serv-desc}
539    
540  The DataLink \citep{std:Datalink} specification describes a mechanism for  The DataLink \citep{std:DataLink} specification describes a mechanism for
541  describing a service within a VOTable resource and  describing a service within a VOTable resource and
542  recommends that services can describe themselves with a  recommends that services can describe themselves with a
543  special resource with \texttt{name="this"}. AccessData responses for  special resource with \texttt{name="this"}. SODA responses for
544  empty sync queries should include a descriptor describing  empty sync queries should include a descriptor describing
545  both standard and custom query parameters (if applicable).  both standard and custom query parameters (if applicable).
546  The descriptor for a service with standard parameters (see  The descriptor for a service with standard parameters (see
547  sect.~\ref{sect:stdpars}) would be:  sect.~\ref{sect:stdpars}) would be:
548    
549  \begin{lstlisting}[language=XML]  \begin{lstlisting}[language=XML]
550    
551  <RESOURCE type="meta" utype="adhoc:service" name="this">  <RESOURCE type="meta" utype="adhoc:service" name="this">
552    <PARAM name="standardID" datatype="char" arraysize="*"  
553      value="ivo://ivoa.net/std/AccessData#sync-1.0"/>    <PARAM name="standardID" datatype="char" arraysize="*"
554    <PARAM name="accessURL" datatype="char" arraysize="*"          value="ivo://ivoa.net/std/SODA#sync-1.0" />
555      value="http://example.com/accessdata/sync"/>  
556      <PARAM name="accessURL" datatype="char" arraysize="*"
557            value="http://example.com/SODA/sync" />
558    
559    <GROUP name="inputParams">    <GROUP name="inputParams">
560      <PARAM name="POS" datatype="char" arraysize="*" xtype="circle"/>       <PARAM name="ID" ucd="meta.id" datatype="char" arraysize="*" xtype="ivoident" />
561      <PARAM name="POS" datatype="char" arraysize="*" xtype="range"/>       <PARAM name="POS" ucd="pos" unit="deg" datatype="char" arraysize="*" xtype="circle" />
562      <PARAM name="POS" datatype="char" arraysize="*" xtype="polygon"/>       <PARAM name="POS" ucd="pos" unit="deg" datatype="char" arraysize="*" xtype="range" />
563      <PARAM name="BAND" datatype="double" arraysize="*"       <PARAM name="POS" ucd="pos" unit="deg" datatype="char" arraysize="*" xtype="polygon" />
564        xtype="interval" unit="m"/>       <PARAM name="BAND" ucd="em" unit="m" datatype="double" arraysize="*"
565      <PARAM name="TIME" datatype="double" arraysize="*"           xtype="interval" />
566        xtype="interval" unit="d"/>       <PARAM name="TIME" ucd="time" unit="d" datatype="double" arraysize="*" xtype="interval"  />
567      <PARAM name="POL" datatype="char" arraysize="*"/>       <PARAM name="POL" ucd="pol" datatype="char" arraysize="*" xtype="Stokes" />
     <PARAM name="COORD" datatype="char" arraysize="*"/>  
     <PARAM name="SELECT" datatype="char" arraysize="*"/>  
568    </GROUP>    </GROUP>
569  </RESOURCE>  </RESOURCE>
570    
571  \end{lstlisting}  \end{lstlisting}
572    
573  This VOTable resource should be output for empty sync  This VOTable resource should be output for empty sync
# Line 722  Line 604 
604    
605  \section{Changes from Previous Versions}  \section{Changes from Previous Versions}
606    
607    \subsection{WD-SODA-1.0-20151120}
608    
609    Change the name of the protocol. Suppression of SELECT and COORD. xtype description are in DALI. Reference to this has been added.
610    
611  \subsection{WD-AccessData-1.0-20151021}  \subsection{WD-AccessData-1.0-20151021}
612    
613  Added general introduction on PARAMETER description to  Added general introduction on PARAMETER description to

Legend:
Removed from v.3182  
changed lines
  Added in v.3183

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26