Change collection name to collection id

[m-mohr]

In the specification it is defined that each collection has a name. This name is expected to be a unique identifier. I'd strongly vote to change this to a collection id due to the following reasons:

• id and title are unambiguous, name is not. Throughout software industry name is used for both titles and identifiers. Just by changing name to id the documentation would be much clearer what is expected to be added there.
• Consistency. Features have an id field, which originates from the GeoJSON spec. Why shouldn't a feature collection also have an id? It would be consistent across WFS.

This was also shortly proposed in the comment by @cholmes here: #156 (comment)

This is also discussed in other projects like STAC (radiantearth/stac-spec#262) and openEO, which all tend to like id and title more and want to omit name because its ambiguous.

[cportele]

Yes, it will be {collectionId} throughout. That we still have {name} in the document is a leftover from earlier versions. The OpenAPI examples already use {collectionId}: https://cdn.rawgit.com/opengeospatial/WFS_FES/3.0.0-draft.1/docs/17-069.html#oas30_example.

[cholmes]

That's great it's going from {name} to {collectionId} throughout. But the issue we're having is actually in the response document, not in the URL template. In example 4 it's:

"collections": [
    {
      "name": "buildings",
      "title": "Buildings",
      "description": "Buildings in the city of Bonn.",
      "extent": {
        "spatial": [ 7.01, 50.63, 7.22, 50.78 ],
        "temporal": [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
      },
      "links": [
        { "href": "http://data.example.org/collections/buildings/items",
          "rel": "item", "type": "application/geo+json",
          "title": "Buildings" },
        { "href": "http://example.org/concepts/building.html",
          "rel": "describedBy", "type": "text/html",
          "title": "Feature catalogue for buildings" }
      ]
    }
  ]
}

That first 'name' there is what we'd like to be 'id'. That would also be consistent with the URL templates, etc. Are you planning to change that too? Would be really great, and would make sense for the response document to clearly identify that from {collectionId} you get a document that says the id.

[cportele]

@cholmes - Changing it to id would be fine for me and indeed be consistent with the path parameter. Any thoughts from others?

[m-mohr]

I support that. I actually thought changing the URL template would imply also changing the response, otherwise it would be even more inconsistent than before.

[pvretano]

"name", "id", "collectionId" ... all good with me!

[cholmes]

Awesome. id would be ideal for consistency throughout. And also gets us consistency with GeoJSON, as that's what it uses for its identifier.

[akuckartz]

It also is more obvious when a JSON-LD context declares that property to be the node identifier "@id" ;-) See https://www.w3.org/TR/json-ld/#node-identifiers

[hgs-msmith]

+1 for changing name to id.

[jvanulde]

+1 for changing name to id.

[royrathbun]

+2