Initial commit

1 files changed, 95 insertions, 0 deletions

diff --git a/vo/votest/tests/req.men b/vo/votest/tests/req.men
new file mode 100644
index 00000000..88fc03d1
--- /dev/null
+++ b/vo/votest/tests/req.men
@@ -0,0 +1,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.