Schema keys are all optional. I don’t understand what you’re trying to do.

Imagine I have an entity, for which I have a spec/schema with a set of keys that it can have. Now, I would like to spec the request parameters to modify the given entity. You can only modify half of the parameters of that entity, although each of them is still optional. How would I approach this case? Does it make sense?

a select is exactly the case of specifying a more constrained structure based on a schema, intended specifically for "in a context", like request parameters

if the keys are optional, then the existing schema suffices

I see, in terms of validation and instrumentation it makes sense, just use the “big schema” with all possible keys and select if there is any requirement. I guess what I was trying to achieve was more aligned with a “specification / documentation” use of schema, so I could tell which of the keys are supported by a specific function, rather tan required

Is there in spec any concept or would it make sense to have something to specify that a property is supported? with a meaning of The property will be used if it exists, but it's not required , or is it something that should be left to documentation / outside of the code specification?

nothing like that in spec, no

Thanks alex. Would it make sense in the context of spec? I think it could be something very close to the concept of select . As I imagine it, would be: • schema: All keys that travel together, outside of function context (all are optional, although wouldn’t optional also be contextual? optional meaning supported or used) • select: All keys that are used in a specific context (With the slight change that it would allow to select optional and required keys for the case mentioned above) Is this something that makes sense? Am I missing something in how I conceive spec?

schemas are all optional, select is all about what's required

I (think I) understand, what I am trying to achieve maybe fits more into the metadata space (saying what is used if specified, for auto generated doc or generative test) rather than in spec. I am trying to wrap my mind around the philosophy behind the schema/select approach, I already find it quite useful how it is now, although sometimes I find myself in a 3-concepts space rather than two (schema/select) when thinking about the information model: 1. What travels together (big schema with all related kw, e.g. domain entity) 2. What a context uses (subset of kw used by the fn. Not everything used is required, but it’s not ignored) 3. What a context requires to work properly (required set of kw for the fn to work) Maybe it makes sense to have smaller schemas in 2. with shared kw with 1. , or to have 2. just as metadata of the fn outisde spec. Any ideas on this ? Seems a good time to re-watch Maybe not , I might be missing something about the philosophy of the tool

On 2, you don't have to use a predefined schema, you can just restate specifically what attrs are allowed, which may be a smaller set

or you can just make a schema that is a smaller set

> or you can just make a schema that is a smaller set I’ll go for that. Which brings me to the beginning, create schema from subset of another schema, (or join schema’s together). Probably something that can be done as tooling outside spec2. Looking forward for a final release 🙌 cheers!

s/merge could merge smaller schemas to make a bigger schema, yes?

^ Indeed !

By <https://github.com/clojure/spec-alpha2/wiki/Schema-and-select> I think s/union would be the one to use on schemas

Thinking about my previous comment of generating schema from subset of schemas, it doesn’t make any sense :man-facepalming: Schema’s syntax is just the set of keys (when ns-kw at least)

We may actually re-purpose “union” for nonflowing s/and so don’t get too attached to that name :)

Usual caveat: Spec2 is a moving target whose function names may change and/or whose semantics may change, potentially several times 🙂

Yeah, luckily it is a personal project with a small codebase, refactors aren’t very painful (I do lots of them to try new approaches). Having that into account, I was avoiding to go much further than def’ing schemas, which it feels already useful to define my domain entities and properties (and understand them) as a common ground between a set of external services that all of them use similar entities but each one of them with different set of properties and property names and formats

I think the select linkage is not fully implemented yet, long story, wip