## 3 New Generation Sensor Web Enablement
### KVP and SOAP Binding Introduced  
With the aim of facilitating the usage of the SOS, the version 2.0 of the standard adds a lightweight HTTP GET binding for selected operations. The operation parameters are passed to the service as key-value pairs (KVP) in the URL of the service endpoint. Further, a SOAP binding is introduced by extending what has been defined by the SWES specification (Section 3.3.1). The KVP binding is reduced in complexity, but also in functionality, compared to the XML-based SOAP binding. So, while the KVP binding provides more simple access to the SOS functionality, the SOAP binding enables the integration of the SOS in service oriented enterprise architectures. A step towards simplifying the standard and streamlining the different SWE services is the introduction of the SWES specification (Section 3.3.1) which is the basis for SOS 2.0. For the _contents_ section of the capabilities document, SWES defines abstract types which are reused by SOS 2.0 and SPS 2.0. The contents offered by a service are grouped into so-called _offerings_. In case of the SOS it is an _observation offering_. This concept has already been used by SOS 1.0; however, a redesign of the offering type restricts it now to aggregate only the observations gathered by one instead of multiple sensor systems. Formerly, it has been up to the SOS provider to group observations into offerings. This could have been done by different criteria: spatially, thematically (e.g., per sensor or observed property), or temporally. The simple conceptual change of limiting the offering to one sensor eases the set up and the access of an SOS server, since grouping of observations to offerings is not ambiguous anymore with respect to the sensor that generated the observations in that offering. An important concept within the SWE framework is the _feature of interest_, the computational representation of a real-world entity modeled with a certain set of properties. This could be for example the feature \"Gulf of Mexico\". Also, a sampling point \"P_42\" within the Gulf of Mexico, where a measurement was taken by a certain (maybe mobile) sensor system, is a feature of interest. Both could have properties such as water depth, salinity or geometry. In SOS 1.0 all features of interest of the observations associated with the SOS server needed to be listed for each observation offering. This is helpful to provide clients a list of features for which observations can be requested. However, this listing of all features has been identified as a problem for mobile sensor systems (e.g., a boat taking measurements on the Gulf of Mexico) which create many sampling features (e.g., sampling points) during operation [78]. Those sampling features could accumulate to huge numbers and could increase the capabilities document up to an unusable state. Hence, the SOS 2.0 does not list sampling features anymore, but instead, _related features_ are listed in the capabilities of an SOS 2.0 server. The listing of those related features has the purpose of improving the discovery of observations. The SOS provider decides which related features are meaningfully listed. In the example above, this would be \"Gulf of Mexico\" and not \"P_42\". Advanced Feature Retrieval  
Clients still need to be able to retrieve a list of sampling features from the SOS. The knowledge about existing sampling features is for example necessary for the construction of queries for sensor observations. For the retrieval of sampling features a separate operation, called _GetFeatureOfInterest_, has already been defined in SOS 1.0. In SOS 2.0 this operation is extended in its parameterization. Not only a specific feature, or features for a certain spatial filter can be requested, but also features which are observed by specified sensors or which carry certain observed properties. Result Handling Redesign  
Allowing the retrieval of the pure observation results for a specified timestamp without the complete set of associated observation metadata has already been supported by SOS 1.0.