search

iptc / newsinjson

Home of the IPTC ninjs standard
https://iptc.org/standards/ninjs/
Other
35 stars 9 forks source link

fix(oxygen-compatibility): fix to location of unevaluatedProperties based on oxygen feedback #149

Closed iyoung closed 1 year ago

iyoung commented 1 year ago

Small change which is semantically identical to the original but will already validate in oxygen

bquinn commented 1 year ago

I can confirm that this works for me. Tests pass in Python, Javascript (ajv) and Oxygen on my machine!

jolla56 commented 1 year ago

In my oxygen it does not behave correct when I insert a non-existing property inside an associations object.

jolla56 commented 1 year ago

I just noticed, why do we declare name as an array of string? "name": { "title": "Name (of associated object)", "description": "Human-readable name of the associated object.", "type": [ "string" ] }

bquinn commented 1 year ago

that's strange, it seems correct for me. I took your example tt_text_image_2.json and added a bad property into the first association:

    { "name": "a001",
      "by": "Karl Melander/TT",
      "descriptions": [{"value": "En stor internationell försvarsövning

planeras 2023 med fokus på södra Sverige och Gotland. Arkivbild från militärövningen Aurora 17."}], "representationtype": "partial", "type": "picture", "bad": "property", "uri": "http://tt.se/media/image/sdlk2sirkPaauM",

Then I used Oxygen to validate against the new 2.1 schema, and got the expected error:

System ID: /Users/brendan/dev/iptc/newsinjson/examples/2.1/tt_text_image_2.json Main validation file: /Users/brendan/dev/iptc/newsinjson/examples/2.1/tt_text_image_2.json Schema: /Users/brendan/dev/iptc/newsinjson/specification/ninjs-schema_2.1.json Engine name: JSON Validator Severity: error Description: #/associations/0/bad: extraneous key [bad] is not permitted Start location: 65:11 End location: 65:16

On Thu, Apr 20, 2023 at 12:28 PM Johan Lindgren @.***> wrote:

In my oxygen it does not behave correct when I insert a non-existing property inside an associations object.

— Reply to this email directly, view it on GitHub https://github.com/iptc/newsinjson/pull/149#issuecomment-1516011801, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLVWF4M4KQLRXLRJLRGMDXCD6SRANCNFSM6AAAAAAXEIP3CM . You are receiving this because you commented.Message ID: @.***>

bquinn commented 1 year ago

you're right, that's a bug left from when I was playing with different ways of making it work.

It doesn't seem to affect the test outcomes though. Even if I leave it in and do "name": false or "name": 1234 validation fails the way we would expect (expected type String, found boolean / found integer)

But either way it shouldn't be there, so I'll fix it and commit to this branch.

On Thu, Apr 20, 2023 at 12:33 PM Johan Lindgren @.***> wrote:

I just noticed, why do we declare name as an array of string? "name": { "title": "Name (of associated object)", "description": "Human-readable name of the associated object.", "type": [ "string" ] }

— Reply to this email directly, view it on GitHub https://github.com/iptc/newsinjson/pull/149#issuecomment-1516018686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACLVWDJE7DZW2LEK3DOVJDXCD7F7ANCNFSM6AAAAAAXEIP3CM . You are receiving this because you commented.Message ID: @.***>