JSON3.Object and Symbol keys

[DatName]

I think there is a bit of inconsistency in how JSONSchema handles Symbol keys:

my_schema = Schema(
    Dict(
        "properties" => Dict(
            "foo" => Dict(),
            "bar" => Dict()
        ),
        "required" => ["foo"]
    )
)

# works as expected
data = Dict{String, Any}("foo" => 1)
isvalid(my_schema, data) # true

# works despite having Symbol keys
data_json3 = JSON3.read("""{"foo": 1}""")
isvalid(my_schema, data_json3) # true

# fails unexpectedly
data_symbol = Dict{Symbol, Any}(:foo => 1)
isvalid(my_schema, data_symbol) # false, type of keys do not match (String vs Symbol).

data_json3 has Symbol keys, but passes validation because JSONSchema automatically converts it to Dict with String keys.

However, from a user's perspective, data_symbol and data_json3 are semantically equivalent - both represent the same data structure and can be used interchangeably. One would reasonably expect both of them two work, I guess.

My particular issue is that it's way more convenient (and still correct for my use case) to create a Dict with Symbols instead of a JSON3.Object. I would need to repeat _to_base_julia() in my code. Which is not a big deal, but still.

[odow]

# works despite having Symbol keys
data_json3 = JSON3.read("""{"foo": 1}""")
isvalid(my_schema, data_json3) # true

This was unintentional.

We could make a much larger change to allow any Symbol and AbstractString keys?

[DatName]

That would be great

[odow]

I started to look into this, and I don't like it. While semantically similar, Dict{Symbol} and Dict{String} are not the same thing.

In my opinion, the key accessing behavior of JSON3 is a mistake:

julia> data_json3 = JSON3.read("""{"foo": 1}""")
JSON3.Object{Base.CodeUnits{UInt8, String}, Vector{UInt64}} with 1 entry:
  :foo => 1

julia> data_json3["foo"]
1

julia> data_json3[:foo]
1

julia> data_json3.foo
1

It should have followed Base:

julia> x = Dict("foo" => 1)
Dict{String, Int64} with 1 entry:
  "foo" => 1

julia> x["foo"]
1

julia> x[:foo]
ERROR: KeyError: key :foo not found
Stacktrace:
 [1] getindex(h::Dict{String, Int64}, key::Symbol)
   @ Base ./dict.jl:498
 [2] top-level scope
   @ REPL[15]:1

julia> x.foo
ERROR: type Dict has no field foo
Stacktrace:
 [1] getproperty(x::Dict{String, Int64}, f::Symbol)
   @ Base ./Base.jl:37
 [2] top-level scope
   @ REPL[16]:1

I've moved JSON3 support to a package extension in #63 to make it clearer that the JSON3 support is not really the main part of the package. I added it only because someone asked a few years ago. I don't think I want to change JSONSchema to have the same String/Symbol confusion as JSON3.

[odow]

When reading with JSON3, you can do:

julia> data_json3 = JSON3.read("""{"foo": 1}""", Dict{String,Any})
Dict{String, Any} with 1 entry:
  "foo" => 1

[DatName]

Makes sense.
Another approach, I guess, could be to define a JSONSchema-specific interface for any input x that JSONSchema could use (with default values from Base's Dict, e.g. js_keys(x) = keys(x), etc) and which can be overwritten safely, without type piracy. This way it would be easy to support any container (including structs), not just AbstractDict or JSON3.

But that's a lot of work, I guess. And not sure if anyone really needs this.

[odow]

I guess, could be to define a JSONSchema-specific interface for any input x that JSONSchema could use

This is what I started doing, but then it got a bit complicated and I was like. Stop. Why am I doing this 😆

But that's a lot of work, I guess. And not sure if anyone really needs this.

Dear future readers, if you would also like this feature, please comment below. If there is sufficient interest, I will consider re-opening this issue.