In addition to the optional values listed in Table 6, there are many optional values of the “name” attributes and “value” elements in the OperationsMetadata section, which may be
included when considered useful. Most of these attributes and elements are for recording the domains of various parameters and quantities.
EXAMPLE 1 The domain of the exceptionCode parameter could record all the codes implemented for each
operation by that specific server. Similarly, each of the GetCapabilities operation optional request parameters might have its domain recorded.
EXAMPLE 2 The domain of the Sections parameter in the GetCapabilities operation request could record all the
sections implemented by that specific server.
12.3.3 Contents section
The Contents section of a service metadata document contains metadata about the data served by this server. For the SPS, this Contents section shall contain information about
the sensors that can be tasked and the phenomena that can be measured by these sensors. The following questions shall be answered in the contents section:
• Which sensors can be tasked by the service? • Which phenomena can be measured with these sensors?
• In which position or region are the sensors operating in or can be tasked to operate?
• Where from can a detailed description of each sensor be received? • What ID has to be used when invoking operations for a sensor at this service?
A SPS supports the discovery of itself through a registry by two different views. A registry could identify suitable SPSs by either searching the capabilities for a certain type
of phenomenon that can be sensed by at least one sensor managed by the SPS under investigation in a certain target-area or by searching for sensors with a certain ID and
or certain characteristics which are able to sense a phenomenon in a certain target-area.
The structure of the contents section is given by spsContents.xsd which can be found in annex B and is shown in Figure 17. Following constraints apply for each contents-
instance which can be controlled by a combination of uniquekeykeyref-elements declared in XMLSchema:
• All SensorOfferings must have different SensorIDs. • All PhenomenonOfferings must have different Phenomena.
• Each Phenomenon referenced by a SensorOffering must also be declared in a PhenomenonOffering.
• Each SensorID referenced by a PhenomenonOffering must be declared in a SensorOffering.
48
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
• There may not be two identical SensorIDs in the same PhenomenonOffering.
«Element»
Contents
«Element»
SensorOfferingList
«Element»
PhenomenonOfferingList
«SensorOfferingType»
SensorOffering PhenomenonOffering
1.. 1..
+ «Element» AreaOfService: AreaOfServiceType + «Element» Phenomenon: anyUIR
+ «Element» SensorDefinition: anyURI + «Element» SensorID: ID
+ «Element» Phenomenon: anyURI + «Element» SensorID: ID [1..]
Figure 17: contens section in UML notation normative, further constraints apply
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
49
Figure 18: contents section in XMLSpy notation informative
12.3.4 Capabilities document XML encoding
