Schema reorg experiment #1

[pvretano]

• so when the schemas are published to https://schemas.opengis.net/ogcapi/records/part1/1.0, it will hold the contents of https://github.com/opengeospatial/ogcapi-records/tree/schema-reorg/openapi (this will allow for direct inclusion of the YAML schemas as building blocks/includes by downstream applications), confirm?

Yes, I believe that is the idea.

• for schemas which are based on features-core, can we directly reference the YAML schemas already available at https://schemas.opengis.net/ogcapi/features/part1/1.0/openapi instead?

No. The features-core schemas also include the changes the support link templates everywhere and the current published version of Features core does not include those changes.

[pvretano]

08-JAN-2024: We discussed at length whether we should adopt this approach to organizing the openapi directory OR whether we should stick with the approach that features uses and the conclusion was that, because records is intimately tied to features, we should stick with the feature apporach for now. This issue of reorganizing the openapi directory will be discussed in an upcoming Features SWG meeting and whatever Features decides to do is what Records will follow.

For now @pvretano will modify the existing openapi directory in master to reference the features schemas directly rather than copying them into the records repo.

[tomkralidis]

Thanks @pvretano. Given the next OGC API - Features SWG is Monday 15 January 2024, depending on the outcome, what is the likelyhood that we (OGC API - Records) can apply the changes quickly enough for OAB submission (especially if changes are needed upstream of us here, for example) shortly thereafter?

[pvretano]

@tomkralidis I may not have been clear in me previous comment. We have a choice of how to lay out the openapi directory.

• Choice 1 is to go with what a lot of other (but not all) OGC specification are doing and implement the changes I have made in this PR.
• Choice 2 is to stick with what we have now which matches what Features does.

Since Records is dependent of Features we have decided to go with Choice 2 (i.e. stick with what we have now). The Features SWG will discuss Choice 1 at an upcoming meeting. That may the upcoming meeting on the 15th but I doubt it since the Features SWG has work to do itself to get v1.1, Part 3 and CQL2 out the door. More likely that discussion will happing after the meeting on the 15th.

We (Records I mean) want to get the specification in the OAB at the end of the month (or before) so the Features timeline is way too long for us.

Long story short, even though I created this PR, we are going to table it and stick with what we have now. It works and it matches the current Features approach. Sound good?

[tomkralidis]

Thanks @pvretano that is clear now. I am assuming we can make such changes after an OAB submission anyway, if/as required. This fits inline with our timeline.

[pvretano]

@tomkralidis correct. If during the RFC process, Features decides to update its layout of the openapi directory, we can simply take that as a comment on Records and make the same changes before publication. These changes do not have a technical impact on the specification.

[pvretano]

Closing because PR #337 was merged instead.