RCTML

RCTML is what I am calling the XML based telescope markup language used for submitting requests to the RCT. It is an informal extension of the version 2.2 RTML taken from Bob Denny's site. Which in turn is based on version 2.1 html reference. I have stayed away from Hesseman's version 3.+ as I don't want to introduce the larger level of generality (yet). The purpose of RCTML is to enter data into the datbase. If you look at the tables in the Request database you will see the correspondence between the RTML elements and the Tables and Entities in the database.

Writing RCTML

Unfortunately it is no easy task to write RCTML directly from a text editor. If you have access to an XML editor such as XMLSpy or Oxygen you can use it in conjunction with the Schema to generate structurally correct files. However, these may still contain errors.

However, if you have an example file, it isn't too hard to modify it to do what you need (sort of like working with TeX). Here are some example files you might want to hack.

There are two terms used below that are features of XML:

element - a piece of data delimited by tags like <Picture> and terminated with an end tag </Picture>. For example: <ExposureTime>3.5</ExposureTime> . RTML uses the convention that elements start with capital letters.

An attribute is something stuffed inside an element. Like count: <Picture count="2" guide="true"> RTML use the convention that attributes are lower case. There is a lively debate on the relative roles of attributes relative to elements.

Introduction

Note: To best understand the following print yourself a full copy of the schema and then follow the more fully annotated discussion.

The RCTML script consists of a <Contact> which is specified solely by the e-mail address of the person submitting the script.

The script then contains one or more <Request> elements. The number of times and frequency the request can be specified by the attributes count and interval. The details of exactly how the request is scheduled can be changed by modifying entities under the <Schedule>

Each <Request> can contain one or more <Target> which are point to a celestial object. The number of times the target is observed can be modified by the count attribute. The celestial target has a <Name> which, if the coordinates are already entered, can be used to lookup the coordinates. If not the coordinates can be specified directly with the <Coordinates> entity. Each <Target> can have one or more individual <Picture> associated with it.

The <Request> are scheduled separately. They have a <Name> which is a name associated with the request. In addition there is are option <Schedule> criteria.

The <Target> specifies the celestial object to be looked at together at the same time. The entire collection can be observed multiple times by changing the count attribute.

An individual exposure is set by the <Picture> which specifies the <ExposureTime> <Filter> and optionally the binning and amplifier.

Most of the time you will be taking FITs images of celestial objects. However, if you wish to do other things, like darks or flats, the <Procedure> can be changed. See procedure listing for more details.

Differences from RTML

Email - is used to determine the observer and is mandatory.

RightAscension and Declination are specified in sexagesimal format with either spaces or colons as delimiters. If no equinox is specified the current one (not J2000) is used.

<Name> is used to specify the name of the request rather than Project.

<Planet> is a boolean, rather than a name, the planet name is specified by <Name>.

Many elements are optional rather than mandatory.

The count attribute is allowed in extra places.


RCT Index