;#   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.