blob: 88fc03d19a486015641c3b7fc4a276252ae3cbaa (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
;# Requirement Tests -- Tests which demonstrate the package requirements.
req_1.1 -- TABLES support: Print VOTable information
req_1.1 -- TABLES support: Print VOTable column information
req_1.1 -- TABLES support: Get a value from a VOTable
req_1.1 -- TABLES support: Copy Columns
req_1.1 -- TABLES support: Operation on a Column
req_1.1 -- TABLES support: VOTable Copy
;#
;# Requirement Demo Script
;# ------------------------------------------------------------- -----------
VOTable Support
1. Users shall be able to use a VOTable in places where req_1
tasks accept tabular data in other formats (ASCII
files, FITS bintables, .tab files, etc) for input.
1.1 Users shall be able to access the <PARAM> and <INFO> req_1.1
elements of a VOTable as standard table header
information.
1.2 Users shall be able to select specific rows and/or req_1.2
columns of a VOTable using the existing task
functionality.
1.2.1 Users shall be able to identify a column in a VOTable req_1.2.1
by the 'id', 'name' or 'ucd' attribute of a <FIELD>
or by column number.
1.3 Users shall be able to select a column in a VOTable req_1.2
for use in tasks that expect a list of values.
1.4 VOTable Interface code will support the IVOA Standard req_1.2
specification of the VOTable format at time of release.
SAMP Interoperability
2. Users shall be able to interoperate with other SAMP req_2
(or WebSAMP) enabled applications.
2.1 Users shall be able to send messages to specific req_2.1
clients or broadcast to all available clients.
2.2 Users shall be able to execute IRAF tasks and set or req_2.2
retrieve information in/from the IRAF environment via
SAMP messaging from clients that implement the required
message types.
Registry Query and Access
3. Users shall be able to query the VO Registry using the req_3
keyword-search services provided by the VO Directory
service.
3.1 Users shall be able to constrain the results of a search req_3.1
by supplying additional parameters to a query (e.g. band-
pass, service type, etc).
3.2 Users shall have access to all information in the query req_3.2
return record.
3.3 Users shall be able to refer to a VO Resource (in tasks req_3.3
requiring a Resource parameter) in multiple ways:
3.3.1 .... By the IVOA identifier req_3.3.1
3.3.2 .... By the ShortName? value in the Registry record req_3.3.2
3.3.3 .... By the "anonymous" result of a Registry query, or req_3.3.3
3.3.4 .... By a "personal alias" for the Resource req_3.3.4
3.4 Users shall have the option to cache query search req_3.4
results to avoid redundant service calls.
Data Query and Access
4. Users shall be able to access all DAL services supported req_4
by the underlying VOClient interface (SCS/SIA/SSA in Y1).
4.1 Users shall be able to use the WCS footprint of a 2-D req_4.1
image as the basis of a data access query.
4.2 Users shall be able to query multiple resources at a req_4.2
single position on the sky, OR a single resource for
multiple positions.
4.3 Users shall be able to specify a base ServiceURL to data- req_4.3
access tasks expecting a Resource parameter.
4.4 Users shall be able to save the results of a query in req_4.4
a tabular format other than VOTable.
4.5 Users shall be able to select which data returned by a req_4.5
DAL service query is to be downloaded to local disk.
|
