Would also love to have something like that. But at the very least, since it's all data, you can easily create your own wrapper function that produces that vector.

I would use [:map [:k {:optional true} [:maybe string?]]].

It's fine for a one-off (or "few-off"), but doesn't feel great when it's repeated tens of times.

We have it in a few places. You can of course make code that returns [:k {:optional true} [:maybe string?]], but the current design is nice because optional is a property of the key, and maybe is a property of the value

Thanks for the replies, all makes sense.

Unrelated but in janet you cannot have nil as a value in a map for this reason!

This way to “dissoc” a key, you can “assoc” the key with a nil value. 🎉

(they call assoc put) https://janetdocs.com/put

(put  @{:a 4 :b 5}  :b nil)  
# => @{:a 4}

Not sure what you mean by "this reason", but it's rather practical to be able to distinguish between "there's no key" and "there's no value for this key". At the very least for easy communication with other entities that support nil-like things, e.g. relational databases.

“this reason” => it is often not a useful distinction (:a {}) vs (:a {:a nil}).

I meant it as a response to: > For my purposes, if a key is absent that is the same as if it is present with the value nil .

1. Is it intentional that https://github.com/metosin/malli/blob/master/src/malli/experimental/time/json_schema.cljc doesn’t have implementations for some of the specs like :time/instant? It seems like I’d need to implement malli.json-schema/accept for the missing specs to make them work properly for JSON schema. 2. I’m a bit surprised at the generated JSON schema for the new time specs; it uses references and is different than the corresponding predicate functions. I was hoping the new time keywords would generate a JSON schema similar to or the same as the corresponding predicate functions. I think this difference might be because of https://github.com/metosin/malli/blob/1a735fe5550b7dccf0832433f2f6d68ce9355edc/src/malli/core.cljc#L172 for these? Example:

(require '[malli.json-schema :as json-schema])

(json-schema/transform [:map [:t inst?]])
=> {:type "object", :properties {:t {:type "string", :format "date-time"}}, :required [:t]}

(json-schema/transform [:map [:t :time/instant]])
=> {:type "object", :properties {:t {:$ref "#/definitions/time~1instant"}}, :required [:t], :definitions #:time{:instant {}}}

I'm partially to blame for your troubles, because I authored this implementation - I only implemented what's in the json schema spec, so maybe you should use a offset-date-time instead of an instant?

That wouldn’t have the same JSON representation or clojure/java type. We use java.time.Instant with ISO-8601 in JSON such as "2023-05-22T14:45:26.345322Z"

Isn't the Z representing zone offset?

I think so, but with no offset since Instant is always UTC time zone? Using OffsetDateTime would be a different type than Instant which adds some inconvenience.

AFAIK instance has no zone, not a default zone,evident by it having no method to get an offset or zone from it, only adding them to it, getting a different time. To make things more annoying, there is no equivalent in Json schema, only offset date time.

https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html

Using inst? in a malli schema gives {:type "string", :format "date-time"} . I’m thinking :time/instant and inst? should preferably produce the same JSON schema.

https://datatracker.ietf.org/doc/html/rfc3339#section-5.6 full-time = partial-time time-offset date-time = full-date "T" full-time

It's wrong

I’m confused what’s wrong specifically, can you clarify? The way inst? is serialized is wrong? The JSON schema that malli produces for inst? makes sense to me, since it’s an ISO-8601 string with an optional offset or just Z when there is no offset (e.g. UTC). The date-time format also matches how java.time.Instant is serialized to JSON by clojure and java libraries, as ISO-8601 strings. It also still seems to me like there’s a pain point and confusion if :time/instant and inst? generate different JSON schema representations even though they both are java.time.Instant and have the same JSON string representation.