-
Notifications
You must be signed in to change notification settings - Fork 47
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
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
@@ -324,22 +305,10 @@ allows the client to suggest to the server which Item attributes should be inclu | |||
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
@@ -46,8 +46,8 @@ for data in a different projection. | |||
|
|||
- **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.
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!
@@ -46,8 +46,8 @@ for data in a different projection. | |||
|
|||
- **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.
core
link relations and endpoints in each other conformance class, and instead just reference core.PR Checklist:
stac-spec
directory (these are included as a subtree and should be updated directly in radiantearth/stac-spec)