1. Declared QoS information for OGC Web Services using extended capabilities – initial ideas
102nd OGC Technical Committee
Delft, The Netherlands
Ilkka Rinne / Spatineo
22nd March 2017
Copyright © 2017 Open Geospatial Consortium

2. Why Extended Capabilities?
Designed extensions points for non-standard capabilities in OGC Web Services Capabilities documents.
Provide service metadata that was not imagined when creating the standard or is vendor specific.
Allows embedding QoS information for any OGC Web Service capabilities without changing the Web Service standard or it’s XML Schemas.
Can be safely ignored by clients, can be provided case-by-case or gradually only for particular service endpoints.
QoS metadata aware clients can easily recognize and extract the extra information.
Own XML namespaces + XML Schema
Copyright © 2017 Open Geospatial Consortium

3. Copyright © 2017 Open Geospatial Consortium
Declared QoS Metadata
Operating Info
Operational status (test/demo/beta/production etc.)
Operating days & hours (default: 24/7)
Scheduled maintenance
Regular maintenance windows, upcoming planned downtime events
QoS statements applying to the entire service
Metrics & minimum values to be expected, availability, capacity etc.
Representative operations
QoS statements for given operations & limited request parameters
Intended use cases: auto-configuration for QoS monitoring tools, automatic cataloguing, generating relevant preview data for client software etc.
Copyright © 2017 Open Geospatial Consortium

4. XML Schema Implementation
QoS Common schema & namespace
QoS metadata general structure and common data content
Abstract extension points for operation specific limitations for representative operations (qos:_Operation element)
Service-specific binding schemas & namespaces
Concrete operation specific limitations (layer names etc. for WMS)
Containing QoS top level element, substitution with abstract extended capabilities element if required (wms:_ExtendedCapabilities)
Easy to extend to new OGC service types
GML not imported
Limited usefulness (BBOX, reference type, srsName)
Heavy for capabilities parsers
Copyright © 2017 Open Geospatial Consortium

5. Copyright © 2017 Open Geospatial Consortium
External Codelists
Flexible referencing of terms and concepts: avoid “hardcoding” codelist values to XML Schema
Clear definitions of the values retrievable using the URI
Examples (of what might be):
/availabilityMonthly
/initialResponseTime
/operational
OGC Codelist registry? Yes!
Other groups need this too (OWS Common Security)
Controlled codelist management, QoSE DWG to approve changes
Copyright © 2017 Open Geospatial Consortium

6. Copyright © 2017 Open Geospatial Consortium
Operating hours (WMS)
Copyright © 2017 Open Geospatial Consortium

7. Scheduled maintenance
Copyright © 2017 Open Geospatial Consortium

8. QoS metrics for the whole service
Copyright © 2017 Open Geospatial Consortium

9. Representative operation (WMS 1.3)
Copyright © 2017 Open Geospatial Consortium

10. Representative operation (WFS 2.0)
Copyright © 2017 Open Geospatial Consortium

11. Representative operation (WFS 2.0)
Most details are optional:
Copyright © 2017 Open Geospatial Consortium

12. OGC Process for QoS Capabilities
Up to discussion:
OGC Discussion Paper for the general structure and intended use cases?
OGC Best Practice(s) for QoS Common Metadata and service-specific QoS capabilities with XML Schemas?
Offer service-specific extensions to corresponding SWGs for standardization?
Nice and simple new standard + extensions?
OWS Common Extension??, but WMS & 1.3?
Codelist values managed in a registry.
In any case: need to test and collect feedback from service providers and software vendors before releasing 1.0
Use OGC Testbeds, other interoperability experiments?
Copyright © 2017 Open Geospatial Consortium