OPTIONAL field MAY be null

[coolljt0725]

This field MAY be null is duplicate with the OPTIONAL

Signed-off-by: Lei Jitang [email protected]

[jonboulle]

I think this was talked about in a previous issue somewhere - it's not quite redundant - the field being optional means it might not be present, but that's different to it being present but having an empty/null value.

[jonboulle]

Could probably do with a once-over of the spec to make sure we're consistent about this for all fields.

[coolljt0725]

Could probably do with a once-over of the spec to make sure we're consistent about this for all fields.

+1 for this to make it more clear.

[coolljt0725]

@jonboulle add a sentence to clarify this

[jonboulle]

@coolljt0725 how is this clearer than what was originally there? it's no longer in context

[coolljt0725]

@jonboulle maybe I just misunderstood your point. I think all the OPTIONAL field could be null

[jonboulle]

That makes sense, but if so, I'd rather move it to the top of the
PROPERTIES section, and tweak the wording a bit -

Any OPTIONAL field MAY also be set to null, which is equivalent to being
unspecified.

On 30 September 2016 at 11:44, Lei Jitang [email protected] wrote:

@jonboulle https://github.com/jonboulle add a sentence to clarify this

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#351 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACewN4PCFQsY_7yZJBlg6dP3cVkW05yHks5qvNnvgaJpZM4KK3yA
.

[duglin]

To be be really anal:

Any OPTIONAL field MAY also be set to null, which is equivalent to being absent.

[wking]

On Fri, Sep 30, 2016 at 07:39:34AM -0700, Jonathan Boulle wrote:

That makes sense, but if so, I'd rather move it to the top of the
PROPERTIES section, and tweak the wording a bit -

If we can make a general rule of this (and that sounds good to me), I
think that rule belongs in the README or some other file to cover all
of our JSON, instead of making a rule that applies only to
application/vnd.oci.image.config.v1+json.

Any OPTIONAL field MAY also be set to null, which is equivalent to
being unspecified.

I like this wording^ [edit: @duglin's wording 0 is better]. I've floated using ‘null’ (vs. leaving the
property off) as a way to explicitly set a property unlimited 1, but
that could be tedious to handle in Go and the idea hasn't caught on
yet. @crosbymichael has also pushed for a distinction between ‘null’
and Go's default value 2; I'm not clear on why, but it may impact
this as well.

[vbatts]

LGTM

[philips]

LGTM