OWS Evolution: WFS3.0, WPS and WCS are developing approaches for using REST and web APIs within future OWS. How should OGC ensure that the approach taken is consistent?

[ogcscotts]

TC Discussion: Chris Little: O&M is missing from this discussion Michael Gordon: Architecture DWG has action from OAB to look at consistency and report back. Should be striving toward more consistency, identify the building blocks and allow standards developers to build upon those blocks. When do we need to make exceptions? Stan Tillman: WPS slowing modernization to fall more in line with WFS practices. Getting assistance in review from WFS. Jerome St-Louis: unified map service concept in Testbed 13 is a good example. Take into consideration this work now as WFS3 is in comment. Linda van den Brink: WFS3 is setting a good examples, especially with respect to Spatial Data on the Web. Should we also add SensorThings API to the mix. Josh Lieberman: SensorThings is a great example and should be considered. Ed Parsons: OpenAPI is a good tool. But “evolution” is a bad term: how about “revolution” and don’t be constrained by reimagining services we already offer, but consider completely new types of services. Jeff DLB: let’s be careful as we develop this approach; a revolution needs more consideration Scott Simmons: WFS3 briefing over the last 18 months has been a good example Josh: But note that WFS3 is built on years of thought Peter Baumann: the revolution should also be briefed to WCS. WFS3 proponents should brief specific SWG sessions beyond just TC-wide briefings. Peter Rushforth: still need to recognize backward compatibility for some standards as being more critical than others. Chuck Heazel: use of OpenAPI helps with backward compatibility. OpenAPI is what many other components use. Ted Habermann: what about OWS Common? Scott Simmons: can summarize OWS Common meeting discussion this week as perhaps OWS Common elements will naturally settle-out of the Web Services efforts. Andreas Matheus: proposed in OWS Common SWG something like everything to the left of “?” in a URL string is “common.” Jerome: even consider just having a Service SWG (the new OWS Common). Chuck Heazel: OpenAPI provides a consistent design pattern. Gobe: what is up in WCS SWG? Peter Baumann: separate functionality from encoding. REST is just an encoding. We need a common base. Maybe not “common” as being defined by WFS3. Chuck Heazel: there is some coordination occurring mostly informally. ACTION: hold a joint session for everyone developing APIs, W*S SWGs all need to be present. Tracy Birch: hard for a new person to OGC to know which standards do what. Show relationships between efforts. ACTION: Scott to sends wiring diagram to Tracy. Matt Purss: take a look at clustering of SWGs

[pebau]

it does not seem the proper "OGC way" that a small group unilaterally establishes some definitions, and then it is expected that all groups just wave it through. if we want yet another, overarching protocol binding then this must be an open consensus process. As it stands, nobody has contacted WCS.SWG, for example, to discuss concepts and issues - the Ft Collins meeting would have been a nice opportunity, which has been missed.

[pebau]

As this topic is pretty much OWS Common discussion should be led by this group.

[jerstlouis]

Dear Peter, I totally agree that no small group should unilaterally establish some definitions. It should definitely be an open consensus process. No one is suggesting that a small group imposes their ways on any other group.

We did some work in Testbed 13 trying to harmonize the different services with the idea of a unified map service ( presentation to the OWS Common SWG in Orléans here: https://portal.opengeospatial.org/files/?artifact_id=78302 ).

Separately, the WFS 3.0 efforts also seems to be heading in this direction with work in Testbed 14 already taking a look at applying the concepts to WCS and WMS. The WFS 3.0 work has already garnered a lot of interest and a lot of adoption. It was their stated goal that this should inform the future of all the OGC services.

What I have been trying to convey is precisely that before heading too far in a particular direction, a 'common' group involving as many people as possible from the WxS services should seriously look at this and attempt to agree on a common approach for what really is common about geospatial services. It does seem that this would be a task suited to the Architecture DWG and/or the OWS Common SWG, but it seems to be difficult to get things to be handed over to or coordinated by those groups. For example the TilingMatrixSet description has been handled by the WMS group for a long time, and this new 'NextGen' REST / OpenAPI work has spawned from the WFS SWG.

Perhaps due to the importance and overarching aspects of Architecture DWG / OWS Common SWG, they should never overlap with other sessions?

From the perspective of a vendor working on implementing all these services and clients, having them agree on common approaches to common concepts is priceless. From the perspective of a user trying to integrate different data sources together in a portal or an application, more consistency would also be greatly beneficial. The 3 data services in particular (WM(T)S, WCS and WFS) really do share a lot of things: CRSes, geospatial extents, temporal extents, tiles, security, service description, the concept of some geospatial data entity which can be displayed and styled in a specific order as part of a 'map' (layer / feature collection / coverage), general aspects of styling, the ability to be rendered either server-side or client-side. WPS is a bit of a different beast, not to say there is no commonality with the other services. Same for IoT services.

I sincerely apologize for mismanaging the time during the Vector Tiles ad-hoc and not being able to give you the chance to present your input regarding tiling from a coverage perspective. I totally agree we need to consider the input from the coverage and other communities if we are to try to shape a common approach to services, and I think the WFS 3.0 community agrees with this and this why they are being cautious and requesting input and waiting before anything gets standardized. I do suggest we start this input process (and hopefully harmonization) as soon as possible before we end up with a de-facto standard because everyone is already supporting the current WFS 3.0 approach.

We might have missed an opportunity in Ft. Collins, but these TCs are so bursting with action; we should not be too hard on ourselves. I think we have agreed to have a session in Stuttgart with folks from all services participating, so let's try to organize this well and perhaps have constructive exchanges before then, to make the most of our time over there and make good progress!

Kind regards

-Jerome

[MichaelGordon]

@pebau I think there may be some confusion here (and this might have been useful to address in the TC discussion)

I don't think any group is looking to impose a proposal. WFS 3 work has been advancing the new version of that specifically. Separately WPS has REST binding work advancing. Various testbed work on REST / web APIs and associated tech is or has taken place. And these topics have been on the tech trends for a while.

I think what was raised at the TC (and has been a topic for a while) is that these separate pieces of work are advancing in similar directions but with somewhat different approaches,

Therefore I think the question to the TC is / has been - given these developments, whether we need to achieve more consistency so that the next generation of OWS make sense as a conceptual whole to developers and end users, if so what's the scope and how should that be achieved?

I don't think there was any kind of proposal from any group that was looking to be passed, whether waved through or otherwise (or if there is I haven't seen it).

[MichaelGordon]

@ogcscotts As a comment I raised in conversations after this - I mostly agree with Andreas' comment regarding "Andreas Matheus: proposed in OWS Common SWG something like everything to the left of “?” in a URL string is “common.”" - though I would comment that I think there are various elements to the right of the ? that are common potential building blocks - for example security, tiling schemes, formats, CRS and potentially some semantics - though as he rightly said, there's a lot of domain specific sections there too.

I wonder if that OWS Commons session could look at consistency left of the ? and identifying common building blocks right of the ? as well as other consistency things like using an API definition language (for example but not limited to OpenAPI) instead of Get Capabilities etc.

[ogcscotts]

@MichaelGordon @joanma747 I think that a discussion of what should sit on either side of the "?" and where the items sit is a perfect topic for the OWS Common SWG. Perhaps some more discussion in this Issue, then build the agenda for a web meeting or the Stuttgart session.