Review terminology

[cportele]

We need to make the document understandable to the developers that have no geo/OGC background (in addition to those that have that background). This may require some clarifications (e.g. use of "service" vs "API").

Agree with this approach in general, we should try to match the current terminology used by mainstream web / mobile developers , however I think it's OK to have some expectation of a knowledge simple Geo terms as used in other API's e.g Google Maps, Mapbox etc.

[jvanulde]

Maybe it's time we consider dropping WFS for GFR (Geo Feature Resource) or some other acronym? Since HTTP is the API it seems as though we are really just talking about documents. I might be oversimplifying things as usual though. Can WMS and WFS be conflated in this new paradigm - the distinction reduced to simple media-type declarations?

[cportele]

Discussed during the meeting on 2017-11-28: At least for now we keep WFS 3.0 as the name.

[jvanulde]

Some ideas here https://www.w3.org/TR/sdw-bp/#spatial-things-features-and-geometry

[cmheazel]

If our goal is to publish a standard which is "understandable to the developers that have no geo/OGC background" then we need to do much more than just change the name (in fact I would argue against it). At a minimum we could include an "Introduction to Geospatial" informative annex. We could also add up front a guide to the standard along the lines of:

1. If you are new to geospatial, then read these sections --------
2. If you are a system designer, then read ------
3. If you are an experienced developer - then read Annex A and the schema, examples, and reference implementations available from -----

[ogcscotts]

I like the idea of an "intro to geo" annex and a guide to the document!

[serich]

Maybe pattern a guide after one of the Testbed 12 user guides at http://docs.opengeospatial.org/guides/?

[cmheazel]

Let's go one step further and establish the WFS 3.0 Standard and the WFS 3.0 Guide. Back in the day, I had a UNIX Programmers Reference Manual and a UNIX Programmers Guide. The guide provided the dense reading needed to understand the features and capabilities of the OS. The Reference Manual was the go-to resource to make sure you coded the API correctly. The two worked well together.
Note: Man pages are the modern version of the Reference Manual.

[cportele]

Having a Standard and a Guide would make sense to me. This is also related to #3. Any volunteers for writing the Guide?

[cmheazel]

We are generating a lot of the raw material as we go along. I'm doing a security write-up for Issue 10. That would be better suited for a guide than the standard. We also talked about an intro to geospatial section. Then there is Annex B. And we can look at the controversial issues we have discussed and capture the rational for the decisions we made.

[cportele]

Meeting on 2018-02-01: @cmheazel agreed to be the editor for the Guide (the informative content). Parallel folder next to core. Different schedule, one guide for multiple parts. Lots of discussion can be moved and explained in the Guide.