Replies: 3 comments 2 replies
|
I also think option 1 would be good and we would find it useful! Maybe with some caution about the original purpose of |
|
I personally see this as an opportunity to improve the specification of We can enrich the description of |
|
I see zod has support for Are there other schema languages that support this besides zod? Zod references: |
|
JSON-Schema (which is my use-case and the reason for #3811) accepts |
|
from what you are saying here I gather that
LinkML has historically treated them as the same thing (absent == null), which is exactly why I like your option 1: I would avoid redefining Honestly this is a textbook candidate for @cmungall's formal-spec effort - I hope you read this Chris! |
Uh oh!
There was an error while loading. Please reload this page.
Trying to create a LinkML schema that helps me create a JSON-Schema that was previously created otherwise I've stumbled upon some unclarity between specification and implementation. The pre-existing JSON-Schema declares a property in the
requiredlist, but it also statesnullable: true.What the meta model
requiredentry says isIt doesn't say anything about the value! So according that text one could expect that having the slot with a
nullvalue would be fine (there is no native way to express it in LinkML, but that's a different story).Unfortunately
nullseems to be equivalent to missing, thereforelinkml generate ...is assuming thatrequiredslots cannot have a null value and generates accordingly JSON-Schemas or Python code.Now I wonder if making
requiredapplicable for both a key (slot) and its value is part of the specification or something nobody ever thought of.As a consequence I'd like to propose different possible solutions that come to my mind (more are surely possible and should be also considered):
requiredspecification that by default it enforces both the presence of the key and the value. Make use of thevalue_presenceattribute to enable a slot to be nullable by specifyingvalue_presence: UNCOMMITTED. Of course, that should be also documented in the meta-model and the implementation would need adaption. PR JSON-Schema: nullable, required slots #3811 is investigating this possibility for the JSON-Schema Generator.requiredspecification that by default it enforces both the presence of the key and the value. Use some other pre-existing mechanism (I haven't found any) to enable a deviation from that default so that the presence of a value is optional.requiredonly enforces the presence of the slot, but not the presence of a value other thannull.I would personally go for 1, that's why I've started investigating that path 😄
All reactions