JSON Schema Validation, section 7.3.1 - clarification needed

[hkosova]

https://json-schema.org/draft/2019-09/json-schema-validation.html#rfc.section.7.3.1
(emphasis mine)

Date and time format names are derived from RFC 3339, section 5.6. The duration format is from the ISO 8601 ABNF as given in Appendix A of RFC 3339.
...
Implementations MAY support additional attributes using the other production names defined in that section.

In the last paragraph, which of the previously mentioned sections of RFC 3339 does "that section" refer to - section 5.6 or Appendix A? I guess it refers to section 5.6 but would appreciate an official confirmation.

[handrews]

@hkosova I think we meant 5.6 at the time, but given how amorphous the concept of "support" for format is, I wouldn't consider it a problem to use things from Appendix A. As of draft 2019-09, validation for format is off by default, and even when on is only a best-effort thing (unless you do some configuration in a custom meta-schema, which most people will not do). So really it's just about what the application (e.g. a code generator or documentation generator) recognizes and understands.

[karenetheridge]

related: #947

[Relequestual]

I think @handrews raises a good point. Support for format is super flakey.

The spec is vaguely gesturing at format becuase ideally we'd like to define some sort of REAL vocabulary for format so it's reliable, as opposed to the current hobbling by formally making it an annotation by default (which we felt was better than "It may work, good luck" to schema authors).

@hkosova What are your concerns here?
What is your situation and use case with format?

[karenetheridge]

Implementations MAY support additional attributes using the other production names defined in that section.

I would recommend just dropping this line from the spec altogether. It's already implicit that implementations can add additional format attributes; we don't have to explicitly say so. (Plus, it's better to push implementors to using separate vocabularies rather than continue to overload 'format'.)

[hkosova]

@Relequestual

What are your concerns here?

As a technical writer I find the "that section" phrase a bit unclear purely from a reader's perspective - the previous paragraph mentions two different sections so it's unclear which one "that section" refers to.

[Relequestual]

Sorry, I meant, what are your concerns as in what do you do with this paragraph that this is a question you've raised?

What would you like to happen here?

I'm not sure what we should do, and as such I want to try and understand how you arrived here, why you care (beyond the fact that it's ambiguous as you rightly point out), and what you'd like. =]

[Relequestual]

Implementations MAY support additional attributes using the other production names defined in that section.

I would recommend just dropping this line from the spec altogether. It's already implicit that implementations can add additional format attributes; we don't have to explicitly say so. (Plus, it's better to push implementors to using separate vocabularies rather than continue to overload 'format'.)

Mmm. I'm afk. Mind finding out who originally added this paragraph / phrasing? May impact how easily we change it.

[karenetheridge]

added in commit 3551097

[handrews]

@Relequestual the point of that statement is to strongly discourage anyone from defining any formats that conflict with RFC 3339. It was a compromise between those who wanted to import the whole set and those who didn't want to do anything about it at all. I would prefer to leave it in.

[Relequestual]

Ok. So how about replacing "that section" with "rfc3339"?

Would that work for you @hkosova too?

[hkosova]

@Relequestual

Ok. So how about replacing "that section" with "rfc3339"?
Would that work for you @hkosova too?

Yes, I think this resolves the ambiguity.