Ready for OGC-NA Review: OGC API – Features – Parts 4 and 5

[ghobona]

OGC-NA,

The following document(s) titled are now available for review by the OGC Naming Authority (OGC-NA) Subcommittee.

OGC API - Features - Part 4: Create, Replace, Update and Delete

https://docs.ogc.org/DRAFTS/20-002r1.html

OGC API - Features - Part 5: Schemas

https://docs.ogc.org/DRAFTS/23-058r1.html

Please review the documents by 22:00 UTC on May 4, 2024 focusing on its conformance to OGC-NA policies.

OGC-NA policies can be found at https://www.ogc.org/standards/na

The most relevant policies are:

• OGC-NA Name type specification - definitions (09-048r6)
• OGC-NA Name type specification - specification elements (10-103r1)

Let us know before then if there are any comments or objections to unanimous consent to its approval by the OGC-NA.

Regards,

OGC Staff

[ghobona]

Part 4: Both /req/create-replace-delete/post-op and /req/core/methods have been labelled as Requirement 1.

Part 4: Remove the ‘create-replace-delete’ segment from the Requirements Class URI http://www.opengis.net/spec/ogcapi-features-4/1.0/req/create-replace-delete/update in Clause 7.1

Part 4: Requirements 16 to 18 use the URI segment /req/patch-update but they should be using /req/update.

[ghobona]

Part 4: Formatting of the table of Requirement /req/optimistic-locking-etags/put-etag-response (currently Requirement 28) has the Condition row in the wrong place.

Part 4: Both Requirements /req/update/methods and /req/create-replace-delete/put-rid are labeled as Requirement 10.

Part 4: Permission
/per/optimistic-locking-etags/ifmatch-patch-op has been incorrectly given the number Permission 34.

Part 4: Because of ‘Permission 34’ the numbering from Requirement 35 onwards is off by one.

Part 4: There is no Abstract Test Suite in the document.

[ghobona]

@cportele Please see the comments above.

[cportele]

Thanks @ghobona, I will have a look and create a PR to address these issues.

Regarding the ATS, we create an ATS only once the requirements are stable, before advancing to the approval vote. This is to avoid the risk that the ATS is not in sync with the normative statements while these are still a work-in-progress and because keeping an ATS properly in sync is a lot of unnecessary work. This was also the approach with Part 3 and CQL2 as well as JSON-FG.

[ghobona]

@cportele

Ok, thanks. We'll re-open this GitHub issue during the Public Review stage as the documents will be stable at that point.