Parse NcML

Back: AIS Using NcML

Since we are interested in only the part of NcML which adds attributes and variables to a data set, build a parser for those parts of NcML and ignore the parts for aggregation.

The NcML schema.

How to treat NcML elements relative to the DAP

Build a parser for these elements: <netcdf>, <readMetadata>, <explicit>, <group>, <variable>, <dimension>, <attribute>, <remove>

netcdf

The design of NcML is such that using it as an AIS - augmenting an existing dataset - is really exploiting one of its optional features. When the <netcdf> element has a netcdf@localtion attribute, then the NcML file is providing information that will augment the stuff in the data set named by location. The original NcML design intended for location to name a netCDF file, but we are going to generalize that to be any file served by the BES running this handler (for location that is a file:/ URL) or any remote Hyrax server (when location is a DAP URL).

In most uses foreseen for this handler, the netcdf@location attribute will always be present.

In the initial version of the handler, we might require this attribute be present and we might not allow new variables to be defined, and instead only allow attributes to be specified for existing variables.

readMetadata

If present read the metadata from the data source and augment with the information supplied in this file. This will normally be present.

explicit

If present, retain only the variables from the data set named by netcdf@location and then add the information included here.

group

A group will be used to represent, in DAP2 or any DAP version upto 3.3, a DAP Structure, Sequence or Grid. That is, all of the types that define a lexical scope can be represented using the <group> element. Nesting of the group elements must match the nesting of the various constructor types.

For versions of the DAP that actually include the notion of a Group type, the group element will apply to that as well.

Limitation: DAP supports arrays of Structures but <group> does not support arrays. This may not be an issue in practice since we never alter the type of a variable using the NcML AIS so we don't need the full range of expressiveness for existing variables. For new variables, a feature most likely used to add arrays of numerical data, this is not a factor. The only type we could not add would be an array of Structures. However, since the notion of group as representing any of a set of lexical types means that we're not actually able to define new instances of any of the Structure, Sequence or Grid types because any such definition would be ambiguous.

variable

The the <variable> element will be used to represent any of the scalar and array types of Bytes, integers, floats and strings/urls.

dimension

Dimensions are part of the netCDF common data model and bind a name with a size (but not a type). These will be part of DAP 3.3(?) but are not currently part of our software. When a dimension element is processed, it will be used to create a binding between the name and the size (an integer) and any used of that name in a 'dimension context' will be treated as the same as the integer size. In practice, dimensions are used to declare the sizes of an Array with the additional notion that all variables that use a particular dimension are related (as in a DAP Grid). However, in a data set served by DAP, an existing Grid will already be explicit, so the dimension element is not needed to establish this relation.

Because the <dimension> element encodes information that is redundant for a DAP2--3.2 data source, we might not support it in the initial version of this handler.