Case Study – Standards Development Strategy

The wonderful xkcd comic No. 927 appears at almost every Standards Meeting at some point, because behind it is of course a truism, the existing standard to solve problem X is great but…

In retrospect I’m not quite sure how it happened but as a member of both the Open Geospatial Consortium (OGC) and the World Wide Web Consortium (W3C) I was asked to co-chair a working group to define a more modern approach to handling spatial data in the web..

For years, accessing and utilising spatial data on the web often felt like navigating a specialised, somewhat isolated corner of the internet. Traditional geospatial web services, largely defined by the OGC and based on technologies like SOAP (Simple Object Access Protocol), while foundational, presented significant hurdles for mainstream web developers and applications. The joint W3C/OGC Spatial Data on the Web Working Group subsequently emerged as a critical force in bridging this gap, advocating for and influencing a fundamental shift towards a more modern, web-friendly paradigm based on RESTful principles and the OpenAPI interface.

Navigating the Cultures of working groups – herding techno-kittens!

Chairing a standards working group within an organization like the W3C or OGC is a significant undertaking: guiding a diverse group of experts to forge consensus on technical specifications that will shape future technologies. This role demands not just technical acumen, but also considerable skill in facilitation, organisation, and diplomacy to keep the group on track towards its chartered goals and deliverables.

The core duties are universally challenging: setting clear agendas, moderating discussions to ensure productive dialogue, managing timelines, overseeing the drafting and refinement of documents by editors, and ensuring that the group adheres to the organization’s established processes and procedures. A chair must cultivate an environment where all participants feel their contributions are valued, even when navigating strong disagreements, and ultimately steer the group towards decisions that reflect the best technical path forward.

However, the complexity of this role can escalate considerably when a working group includes active participants from two distinct standards bodies, each with its own history, culture, processes, and even philosophies regarding standardisation.

Here, the chair isn’t just facilitating consensus within one organizational framework; they are bridging two. This introduces several layers of complexity:

• Process Harmonization: The two originating bodies likely have different rules for everything from meeting protocols and document balloting to intellectual property policies. The chair must navigate these differences, potentially even needing to establish hybrid processes or clear guidelines on which process takes precedence for different aspects of the work.
• Cultural Translation: Beyond formal processes, standards bodies develop distinct cultures – ways of communicating, norms for debate, and even different levels of formality. Participants from one body might be accustomed to rapid iteration and public feedback, while those from another might favour more formal, closed-door deliberations. The chair needs to be acutely aware of these cultural nuances and work to foster mutual understanding and effective cross-cultural communication.
• Aligning Priorities and Perspectives: Members from different organizations may arrive with differing priorities and perspectives shaped by the specific needs and use cases emphasized within their primary standards body. Reconciling these can be a delicate balancing act, requiring the chair to highlight common goals and the benefits of a unified standard.
• Building Trust Across Boundaries: Trust is paramount in collaborative standards development. When participants hail from different organizational homes, the chair must actively work to build trust and a sense of shared purpose that transcends organizational affiliations. This might involve extra effort in ensuring transparency, fairness, and equal opportunity for contribution.

In this environment, the chair becomes more than just a facilitator; they become a crucial bridge builder. They must not only understand the technical challenges at hand but also possess a deep well of patience, cultural sensitivity, and diplomatic skill to navigate the complexities introduced by differing organisational landscapes.

The Challenge: Navigating the “Deep Geospatial Web”

The early generation of OGC web services, such as the Web Feature Service (WFS) for accessing vector data and the Web Map Service (WMS) for accessing map images, were designed in an era when enterprise-level, service-oriented architectures (SOA) were prevalent. While successful within the traditional Geographic Information System (GIS) community, these services often exhibited characteristics that hindered their broader adoption and seamless integration with the burgeoning world of web development:

• Complexity and Steep Learning Curve: The specifications were often extensive and complex, requiring specialized knowledge of geospatial standards and XML-based protocols (like SOAP) that were not standard fare for most web developers.
• Rigidity: The fixed nature of the operations and responses could make it challenging to retrieve precisely the data needed without excessive overhead.
• Limited Web Integration: These services often felt disconnected from core web architecture principles. They were frequently described as part of the “deep web,” not easily discoverable or consumable by standard web search engines and general-purpose web development tools.
• Performance Issues: Accessing large datasets or performing complex queries could be inefficient due to the protocol overhead and the request/response patterns.

This created a divide between the rich world of spatial data and the increasingly dynamic and interconnected web. There was a clear need for a more accessible, flexible, and web-native approach to exposing geospatial information.

The Intervention: The Spatial Data on the Web Working Group

Recognizing this challenge, the World Wide Web Consortium (W3C), the international community that develops open standards to ensure the long-term growth of the Web, and the Open Geospatial Consortium (OGC), a key player in developing geospatial standards, joined forces to form the Spatial Data on the Web Working Group.

The group’s core mission was to integrate spatial data more effectively into the broader web. This involved:

• Developing and maintaining best practices for publishing and using spatial data on the web.
• Identifying areas where joint W3C and OGC standardization efforts were needed.
• Promoting the use of web technologies and principles for spatial data.

A key output of the working group was the “Spatial Data on the Web Best Practices” document. This document emphasized principles like using URIs for spatial things, making spatial data indexable, and linking spatial data to other data on the web. Crucially, it highlighted the importance of using standard web patterns for data access.

The Shift: Embracing REST and OpenAPI

The working group’s deliberations and the identified best practices strongly aligned with the principles of REST (Representational State Transfer), the architectural style that underpins the modern web. RESTful APIs leverage standard HTTP methods (GET, POST, PUT, DELETE) and focus on resources identifiable by URIs, offering a more intuitive, scalable, and developer-friendly approach compared to SOAP-based services.

Furthermore, the rise of OpenAPI (formerly Swagger) provided a standardized, language-agnostic way to describe RESTful APIs. This machine-readable description allows for automated documentation, code generation, and testing, significantly improving the developer experience.

The W3C/OGC Spatial Data on the Web Working Group played a pivotal role in advocating for the adoption of these web-native technologies within the geospatial domain. Their work provided the theoretical and practical foundation for a new generation of OGC standards.

The Outcome: The OGC API Family

A direct and significant outcome influenced by the working group’s efforts is the development of the OGC API family of standards. These new standards, such as OGC API – Features (the successor to WFS), OGC API – Coverages, and OGC API – Tiles, are explicitly designed around RESTful principles and are defined using OpenAPI.

This represents a major paradigm shift:

• Resource-Centric Access: Instead of complex, operation-based requests, OGC APIs provide access to spatial data as well-defined resources (e.g., feature collections, individual features) identifiable by simple URIs.
• Developer-Friendly: By using standard HTTP methods and common data formats like GeoJSON, OGC APIs are immediately familiar and easier to consume for the vast community of web developers.
• Improved Interoperability: The use of OpenAPI provides a clear contract for how to interact with the API, facilitating easier integration and reducing the potential for misinterpretation.
• Enhanced Web Integration: OGC APIs are inherently more web-native, making spatial data more discoverable, linkable, and integratable with other web resources.

The W3C/OGC Spatial Data on the Web Working Group’s work on best practices and its role as a liaison between the web and geospatial communities were instrumental in paving the way for this transition. The group’s advocacy for web standards and its focus on making spatial data more accessible to a wider audience directly influenced the OGC’s strategic decision to develop the OGC API suite based on REST and OpenAPI.

The ‘End Result”

The joint W3C/OGC Spatial Data on the Web Working Group has been a vital catalyst in modernizing the way spatial data is exposed and consumed on the web. By highlighting the limitations of traditional web services and championing the adoption of RESTful principles and OpenAPI, the working group has significantly contributed to the development of the OGC API family. This shift is making spatial data more accessible, interoperable, and usable for a much broader range of developers and applications, truly integrating spatial information into the fabric of the world wide web. The legacy of the working group lies in its successful push to move geospatial standards from a specialized, service-oriented paradigm to a modern, web-centric, and developer-friendly ecosystem.