test that format-assertions are valid with non-string types #512
Conversation
|
These belong in non-optional (they're required no matter what the implementation of format looks like). And I believe are present already? Though I see you saying resolving some inconsistencies -- which ones? |
The point is to test the evaluation result when formats are treated as an assertion, as well as just an annotation.
They are in their own commit: 809a114?diff=split&w=1 |
I suspect the thing I don't follow is the same thing that was just opened as #513, I don't really understand what differentiates one from the other in what's here (which isn't new in this PR, but yeah seems quite confusing at the minute). |
|
format-annotation and format-assertion are two totally separate vocabularies. Non-string types are valid in both vocabularies. We had tests for one but not the other (as observed by @gregdennis on slack a few days back). This PR corrects that. |
karenetheridge
force-pushed
the
ether/formats-and-non-strings
branch
from
097e6ff to
494676a
Compare
|
That said, I don't understand why are these in Currently, I don't see the logic for duplicating these in optional. |
|
The intent is to ensure that the format-assertion vocabulary also pass these tests.
Yes, but that is not actually clear right now -- as was raised by a core contributor whose implementation was not passing these tests (and therefore he was not testing in that configuration). I would rather err on the side of redundant/overlapping tests, than missing some test coverage. This will all be more clear when we add custom metaschemas -- that is, add a "$schema" keyword to the format-assertion tests. |
- whitespace - a bad RFC uri - omitted tests
karenetheridge
force-pushed
the
ether/formats-and-non-strings
branch
from
494676a to
b349b87
Compare
Also resolves some inconsistencies between draft versions.