Skip to content
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

media type params #202

Merged
merged 15 commits into from
Nov 6, 2024
Merged

media type params #202

merged 15 commits into from
Nov 6, 2024

Conversation

catkins-miso
Copy link
Contributor

@catkins-miso catkins-miso commented Nov 1, 2024

closes #142

@catkins-miso catkins-miso linked an issue Nov 1, 2024 that may be closed by this pull request
18 tasks
@catkins-miso catkins-miso marked this pull request as ready for review November 5, 2024 01:31
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be expanded, and I will do so under #155, but this is already way too much for one PR.

<<: *forecast-limit-snapshot
description: |
A slim snapshot of the forecast for a monitoring set, including the inputs
that were used to determine the continuous limits.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@getorymckeag Please take particular note of this: continuous limits. The issue is that different providers can potentially set continuous versus emergency limits, so a single input for each period's rating set might be insufficient. Since this is about creating situational awareness in interop, I felt the compromise of only guarantee the input was associated with the continuous limit was worthwhile.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. I am having trouble imaging a scenario where the inputs are actually different. It would be kind of strange to have a weather measurement that is used to generate an emergency rating but NOT a continuous rating. While the inverse seems at least possible (maybe ignore some more "exotic" cooling factor?), the difference for emergency limits and continuous is really an internal of the TO's rating methodology, and I would think is something market monitors could work with the TO to simply rederive from the available continuous input + equipment characteristics if they really wanted to.

<<: *forecast-limit-snapshot
description: |
A slim snapshot of the forecast for a monitoring set, including the inputs
that were used to determine the continuous limits.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. I am having trouble imaging a scenario where the inputs are actually different. It would be kind of strange to have a weather measurement that is used to generate an emergency rating but NOT a continuous rating. While the inverse seems at least possible (maybe ignore some more "exotic" cooling factor?), the difference for emergency limits and continuous is really an internal of the TO's rating methodology, and I would think is something market monitors could work with the TO to simply rederive from the available continuous input + equipment characteristics if they really wanted to.

@getorymckeag getorymckeag merged commit b490e01 into 1.0.0-wip Nov 6, 2024
3 checks passed
@getorymckeag getorymckeag deleted the 142-media-type-params branch November 6, 2024 00:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

tighten up media type params
2 participants