Hi, something like this?

(require '[malli.generator :as mg])

(mg/sample
 [:map
  [:notification :string]
  [:notification24 :string]
  [::m/default [:map-of {:gen/max 2} :string [:map-of {:gen/max 4} :string :map]]]])
;({:notification "", :notification24 ""}
; {:notification "", :notification24 "2"}
; {:notification "8", :notification24 "5y", "" {}}
; {:notification "Q", :notification24 "DD", "" {"S8K" {}}}
; {:notification "5O38", :notification24 ""}
; {:notification "v4W2",
;  :notification24 "T",
;  "9J" {"8" {}, "4rLwM" {}, "" {}, "KoQZ" {}},
;  "0" {"kOro" {}, "Z" {}, "" {}}}
; {:notification "q6", :notification24 "", "2hxIz" {"e" {}}}
; {:notification "", :notification24 "", "0WVu" {}}
; {:notification "", :notification24 "egwdu"}
; {:notification "FBee", :notification24 "6UVm", "MjQ" {"M1Ig3" {}, "3O" {}, "a1t50QoD" {}}})

This was precisely what I was looking for. I did manage to validate the incomind data using a modified version of your example. I'm a bit embarrased that I managed to miss / not understand how the m/default and map-of syntax worked from the readme.md. Thank you kindly for the answer

so this works:

(m/schema
             [:and
              [:map
               [:foo {:optional true} number?]
               [:bar {:optional true} number?]]
              [:fn
               {:error/message "either use :foo or :bar"}
               (fn [m] (or (some? (get m  :foo)) (some? (get m :bar))))]]

             {:registry registry})

currently, there isn’t more idiomatic way to do that. See https://github.com/metosin/malli/issues/474

there is :multi that can be used, depending on the requirements.

if someone can cook a good and simple syntax for defining the key requirements/dependencies, I'm all ears

thanks for the reply. With my limited understanding so far, you can use :or either on the :map level

[:or 
  [:map [:foo number?]
  [:map [:bar number?]]

[:map [:foo [:or number? string?]]

[:map
 [:or 
  [:map [:foo number?]
  [:map [:bar number?]]
 [:baz number?]

The entry-parser doesn't understand the :or currently. How would you differentiate it from expected map key :or?

it could be ::m/or not to mix up with normal keys.

[:map
 [:or [:map [:x :int]]]

is that map with :or key with map as value, or :map key with :int value

[:map
 [::m/or [:map [:x :int]]]

I see your point. from that perspective it would perhaps have been nice to namespace all Malli keywords... What makes me wonder, in your last example

[:map
 [::m/or [:map [:x :int]]]

[:map
  [:house-number number?]
  [::m/or 
    [:zip-code string?]
    [::m/and
      [:city string?]
      [:street-name string?]]]]

Exactly. Didn’t notice that my schema had a bug in it. Correct pair would be:

[:map
 [:or [:map [:tuple :int]]]

[:map
 [::m/or [:map [:tuple :int]]]

"a map with EITHER a key :map key with :tuple of one :int OR nothing, e.g {:map [1]}" 

[:map
  [:house-number number?]
  [::m/or 
    [:zip-code string?]
    [::m/and
      [:city string?]
      [:street-name string?]]]]

implementation of this would require a change in the map parser + internal data structure, so some amount of work.

could you your example (with reasoning) to the issue?

Sure! Glad to be of help. Tomorrow I will have time

Hi Tommi I added what I hope was the gist of our discussion to the issue.

Hear you, just needs to implemented. Not sure if that would be even a big thing to do, but things like precedence should be thought.

Here are the schematized parse tests: https://github.com/metosin/malli/blob/master/test/malli/destructure_test.cljc#L171-L287 Would you be interested in writing a minimalistic but complete expectation and attach that into an new issue of this?

Related: https://clojurians.slack.com/archives/C1B1BB2Q3/p1694083268018519

revisited te parser code, kinda dense, but there is not much of it as it's using malli for parsing 😉 https://github.com/metosin/malli/blob/master/src/malli/destructure.cljc

Hmm. Interesting use case for :and! It works if as long as you don't close the maps.

Can't recall the code, but what happens if you set the maps explicitly open with :closed false property. Would that work?

How are you using "options for the composed schema"?

losing refs with Json schema, could you show an example?

The issue with :closed false is that I would like to use the strip-extra-keys-transformer to implement select-schema (like metosin.schema-tools/select-schema), and that wouldn't work if I leave the maps open. By "options on the composed schema" I mean documentation keys like :title, :description :json-schema/format etc. I'll write a better example in a bit. Update: I realize I've been using the wrong term options while I actually meant properties. Sorry for the confusion.

adding as snippet as well for syntax highlight

To repeat, the two issues are: 1. When using mallo.json-schema/transofrm, :merge also merges the options properties of the schemas that are being merged and doesn't retain the options properties for the root (e.g. with [:merge props a b c d], only the options properties of d will remain). 2. refs also get resolved in the process But even if both of these behaviours would be changed in :merge, I would still want to keep using :and, because in some cases it describes the intention and the purpose of the schema more accurately than :merge.