How can I force spec to not validate a namespaced key against an optional spec in a map? I have a multispec with two clauses where the only difference is in the inclusion of a namespaced key, but because the key matches a spec the library will simply go ahead and validate that key against the spec even though it should not for that specific clause.

keys will always validate namespaced keys

That’s kind of central to the whole design of spec

It just feels inconsistent to how un-namespaced maps are treated - though I guess one could technically argue that if I'm saying a namespaced key should have a particular shape then it should have it whether or not it is required in a map. I have since tweaked it so that this is indeed the case, though given how namespacing is a particularly burdensome thing in our service (I have stripped it from everywhere except for one namespace, and even there it feels a bit redundant) this was quite the surprise in behaviour.

if you think about them (kinda sorta) like Types it makes sense. a :animal/lion is always the same thing.

Rich has a philosophical position that maps should be a bag of keys, and type information comes primarily from keys not from the bag

https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only

I think is inaccurate to characterise it as philosophical. Having consistent meaning associated with names in a program makes your program easier to reason about.

I found that in our specific use case, where we have lots of things that look the same up to a certain level and can diverge in some specifics, namespacing became a burden both during testing and during main program flow. Our use case might just be a special scenario, though I suspect I would probably do it the same way again if I was facing largely similar scenario - i.e., internal entities with roughly similar shapes, as I really don't like the idea of mixing different namespaces in a single map.

I hate working on programs where the thing I'm looking at shares a name with something else but is different. E.g. if "products" in one place referred to the ids of products you're allowed to see, but elsewhere referred to a list of product entities from the database.

Mixed namespaces don't create any bother for me, I believe that exists so you can have separate pieces of code which operates on the same entity as long as it fulfils the data contract. E.g. It's easier to understand code which operates on "Twitter account" which is a limited number of details, rather than "user" which is much larger and requires more juggling in your head.

Yeah - and I'd imagine that would work well if the maps truly mixed contexts. In our case, they mostly mix different datatypes that tend to look similar to one another, with a common "envelope" map around them. Given the benefits we gain out of being able to shove everything into a common processing pathway stripping the namespacing ended up making things a lot less unwieldy than it was.

Sounds like stamp coupling

When taken to an extreme, these ideas are still coupling. Functional connections are the only kind that's free from this, but that's a lot of typing and not much abstraction.

I don’t disagree it’s nice when keys = types and they are well namespaced and shared across entire application. I think Dominic took “philosophical” as a slur which I absolutely do not mean

However, keys in fact do not always have the same type, e.g. a map key in a DSL vs a map key in data

e.g. datomic pull expression map vs the value of the pull

the “bag” sometimes imparts meaning to the keys, IOW

not to mention having to deal with other systems which don’t share your “maps are only keysets” philosophy, but I think the spec2 select machinery is an acknowledgement of that problem

spec 2 select just says that the notion of required/optional keys is contextual

it still maintains strong semantics for attributes across aggregates

but it also has contextual key renaming, no?

no, it doesn't

it has the ability to do binding of un-qualified keys to specs, but un-qualified keys only

that’s all I meant

{:first :my.app.name-part/first-name} for example

I think schema is what I am talking about, as being able to impart some meaning to the aggregate

instead of being “merely” a keyset

the intent here is not that attributes can be assigned many different meanings, but that unqualified keys are missing the link to attribute semantics

it's still just a collection of attributes though

yes it does not solve that problem