spec: Define the property-specification syntax #747
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wking
force-pushed
the
mark-platform-specific-settings
branch
3 times, most recently
from
cd05128 to
cfd9af0
Compare
And add platform annotations.
By formally defining our syntax, we do a better job of making that
syntax enforcable. We can also make platform-scoping very obvious,
and no longer need to rely on "For Linux-based systems the process
supports..." guards.
The only intentional semantic change is that we now allow,
platform-named properties that don't match platform.os. For example:
{
"platform": {
"os": "linux",
...
},
"windows": {
...
}
}
and even:
{
"platform": {
"os": "linux",
...
},
"windows": "foo",
}
are both legal now. This rolls back the "MUST NOT be set otherwise"
requirement which had landed in 718f9f3 (minor narrative cleanup
regarding config compatibility, 2017-01-30, opencontainers#673) to make those
properties consistent with our general:
Implementations that are reading/processing this configuration file
MUST NOT generate an error if they encounter an unknown property.
and:
The state MAY include additional properties.
extensibility policies. The alternative would be cross-platform
specification of those properties which then forbid the properties on
non-matching platforms, but then the cross-platform definition would
not match the platform-specific Go type. For example:
Linux *Linux `json:"linux,omitempty" platform:"linux"`
Blocking the non-matching-platform properties didn't seem to be worth
the potential confusion of the Go platform tag not matching the
Markdown platforms tag.
The ABNF highlighting comes from [1,2].
[1]: https://help.github.com/articles/creating-and-highlighting-code-blocks/#syntax-highlighting
[2]: https://github.com/github/linguist/blob/v5.0.8/lib/linguist/languages.yml#L50-L56
Signed-off-by: W. Trevor King <[email protected]>
wking
force-pushed
the
mark-platform-specific-settings
branch
from
cfd9af0 to
05da00b
Compare
Contributor
Author
|
On Wed, May 10, 2017 at 02:14:28PM -0700, Mrunal Patel wrote:
Closed #747.
Without the ABNF and associated docs [1], there's nothing connecting
(for example) to unpack:
foo (object, REQUIRED) Something about foo…
into:
foo values MUST be objects. Configurations MUST include the foo
property. Something about foo…
I think we want *something* to help with that unpacking, even if it
doesn't use an ABNF (although I think ABNF is a nice, compact way to
clarify the syntax). Do we have any alternative plans for clarifying
the syntax?
[1]: https://github.com/wking/opencontainer-runtime-spec/blob/05da00bc76e1746276e977ab45957ab39c31c73a/spec.md#property-specification
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
And add platform annotations.
By formally defining our syntax, we do a better job of making that syntax enforcable. We can also make platform-scoping very obvious, and no longer need to rely on “For Linux-based systems the process supports…” guards and similar.
The only intentional semantic change is that we now allow, platform-named properties that don't match platform.os. For example:
and even:
are both legal now. This rolls back the “MUST NOT be set otherwise” requirements which had landed in #673 to make those properties consistent with our general:
and:
extensibility policies. The alternative would be cross-platform specification of those properties which then forbid the properties on non-matching platforms, but then the cross-platform definition would not match the platform-specific Go type. For example:
Blocking the non-matching-platform properties didn't seem to be worth the potential confusion of the Go
platformtag not matching the Markdownplatformstag.