Beta.1 refinement #80
Conversation
…d ogcapi-features readmes
|
Up next: extensions.md |
|
Ok, I think this is ready for review. Should hopefully be the last major merge in. I was using it for a number of little improvements. I'll try to do another review tonight of everything, but may not get to it. But would be great to review what's here and get it merged. |
| contained within several YAML files in the various directories. These live in the same place as the markdown defining | ||
| various parts of the specification. Currently we expect developers to be up to speed with | ||
| OpenAPI and using their own tools to modify things. In the future we will provide tools to make it easier to work with. | ||
| We do publish full OpenAPI files online, at TODO: Matt to add final location. |
There was a problem hiding this comment.
Here's a ToDo. What sub-domain do we agree on? We also need to change all the Conformance URIs accordingly.
| sections below.The core STAC conformance classes communicate the conformance JSON only in the root (`/`) document, while OGC API | ||
| requires they also live at the `/conformance` endpoint. | ||
| sections below. The core STAC conformance classes communicate the conformance JSON only in the root (`/`) document, while OGC API | ||
| requires they also live at the `/conformance` endpoint. STAC's conformance structure is detailed in the [core](core/). | ||
|
|
||
| **NOTE:** *By 1.0.0 we aim to have requirements classes specified in detail, as testable assertions, | ||
| like OGC does, but for now the core reference is just this spec document and the OpenAPI yaml. We also desire to have the |
There was a problem hiding this comment.
Isn't Matt's PR #86 already publishing the OpenAPIs to the conformance class URIs? At least that's what I hope it does. It doesn't make sense to have them at two places.
There was a problem hiding this comment.
Oh, by 'conformance structure' I just meant the full description of STAC's conformsTo JSON construct. I'll reword here.
There was a problem hiding this comment.
I think this is a misunderstanding, I was referring to:
We also desire to have the URI's for conformance to actually resolve to machine-readable information clients can use.
I thought that is what Matt is working on?
There was a problem hiding this comment.
Ah, gotcha - I was looking at the green highlight.
We also desire to have the URI's for conformance to actually resolve to machine-readable information clients can use.
I thought that is what Matt is working on?
I thought he was just publishing html versions online. Not sure if he was trying to make them so they'd be the same location and resolve. I was considering that out of scope for this release, but I'm not opposed to it.
There was a problem hiding this comment.
I did not fully understood your conclusion yesterday (non-native speaker issues ;-) ), but I think we should publish the OpenAPIs and HTML versions... And for the HTML versions you usually need the OpenAPIs. But anyway, it doesn't matter here to what it resolves, it would resolve to something and give you the information anyway. cc @matthewhanson
There was a problem hiding this comment.
Ah. My conclusion was we should just have the OpenAPI's in github, and publish the HTML directly off of those. But I don't feel strongly.
There was a problem hiding this comment.
I'm publishing the yaml files to gh-pages in this repo.
Then we can use ReDoc to point to any of them to create an html version, like in here: https://github.com/radiantearth/stac-site/blob/master/STAC-api.html
Co-authored-by: Matthias Mohr <[email protected]>
Co-authored-by: Matthias Mohr <[email protected]>
Related Issue(s): #83 #76 #39
Proposed Changes:
PR Checklist:
npm run generate-allto update the generated OpenAPI files.