XML Messages in the LAS Architecture
In this picture there are two places where LAS exchanges information via an XML message.
(Click image to see full-sized version.)
The UI Request
The pink arrow represents an XML message that has not changed significantly since the previous version. Here is an example of one such message:
<?xml version="1.0" encoding="UTF-8"?>
<lasRequest package="" href="file:las.xml">
<link match="/lasdata/operations/operation[@ID='Plot_2D']" />
<link match="/lasdata/datasets/NOAA-CIRES-CDC-Leetmaa_Ocean_Analysis/variables/CDC_DS17-otemp2027" />
<range low="122.0" type="x" high="288.5" />
<range low="-35.0" type="y" high="45.0" />
<point v="500.00" type="z" />
<point v="01-Jan-1980" type="t" />
There are (at least) three interesting things (highlighted in bold) to note about this message. The first is the pointer to the operation that is being requested. This is an XPath statement which refers to an operation element in the configuration with an ID attribute with the value "Plot_2D". Some details of the operations definition is here.
The second highlighted area of the UI Request XML is the colleciton of arbitrary properties that gets passed around with the request. In this example there is a group of related properties under the <ferret> element which are used by the Ferret backend service to decide how to render the plot. The other group (highligted in bold) under the <arbitrary_name> illustrate the the configuration can include any collection of properties the installer wants to include. Those properties will be passed all the way through the product server to the backend service and back to the output template and can be used (or ignored) by any step in the generation of the product.
Finally, the strange syntax of an <link> element followed by a match attribute is how the UI Request protocol passes along to the product server which variables the product server is to operate on. These XPath pointers to variable configuration information will get translated by the product server into actual data access information (local file names, OPeNDAP URLs, database or DRDS server access information) which can then be used by the backend service to actually read the data.