-
Notifications
You must be signed in to change notification settings - Fork 53
Reorg conformance uris, endpoints, links, and maturity classification #240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reorg conformance uris, endpoints, links, and maturity classification #240
Conversation
merge to master for 1.0.0-beta.4 release
| will require the spec to go to 2.0.0. | ||
| will require the spec to go to 2.0.0. | ||
|
|
||
| ## Maturity Classification |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was moved from Extensions, since it applies to both the regular conformance classes and extensions
| through the use of a `fields` parameter. The full description of how this extension works can be found in the | ||
| [fields fragment](../fragments/fields/). | ||
|
|
||
| ### Filter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved Filter and Query to be next to each other
|
|
||
| - **Working code required.** Proposed changes should be accompanied by working code | ||
| (ideally with a link to an online service running the code). A reference implementation should be available | ||
| online to power the interactive documentation. Fully accepted specifications should have at least 3 implementations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what "fully accepted" means here, since 3 impls is what we call Candidate in the Maturity Classification model. Rewording to just not be inconsistent with the MC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this predates extensions, and I think fully accepted was meant to mean like 1.0.0? Change looks good.
cholmes
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
|
|
||
| - **Working code required.** Proposed changes should be accompanied by working code | ||
| (ideally with a link to an online service running the code). A reference implementation should be available | ||
| online to power the interactive documentation. Fully accepted specifications should have at least 3 implementations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this predates extensions, and I think fully accepted was meant to mean like 1.0.0? Change looks good.
Related Issue(s): #232
Proposed Changes:
There are no effective changes in this PR, it simply reorganizes the content that was already there.
corelink relations and endpoints in each other conformance class, and instead just reference core.PR Checklist:
stac-specdirectory (these are included as a subtree and should be updated directly in radiantearth/stac-spec)