NEVER MERGE (EVER): Fix incorrect use of value slots in extra_slots examples.#244
NEVER MERGE (EVER): Fix incorrect use of value slots in extra_slots examples.#244
value slots in extra_slots examples.#244Conversation
The examples provided in the meta-schema for the `extra_slots` slot
incorrectly use the `value` slot of the `Example` class, as in:
```yaml
extra_slots:
examples:
- value:
allowed: true
```
This is incorrect because the `value` slot is string-typed: it cannot
contain an _object_ such as `{allowed: true}`.
This is bad because (1) it is not a good sign that LinkML's own
meta-schema is invalid according to its own rules, and (2) this prevent
the schema from being loaded when using an implementation that actually
cares about typing issues.
The `Example` class defines another slot, `value_object` (aliased to
simply `object`), that is specifically intended to represent values that
are not simple strings. This commit updates the examples on the
`extra_slots` definition to use `object` rather than `value`.
closes linkml/linkml#3245
value slots in extra_slots examples.value slots in extra_slots examples.
|
@gouttegd can you take a look? also mentally reason over the approach of using an rc to generate model files. What I do not want to do:
My sense is that while there is a minor risk of something going wrong when I update linkml to the updated link-model because of something wrong with linkml, its so minor that I would prefer to squint hard and move on. |
|
Err, I am not sure I understand what you are trying to do here, or rather why you are doing it? The most direct way of fixing linkml/linkml#3245 is to (a) wait for |
Ah, because I promised to @sneakers-the-rat that I would get this feature here IN 1.11. I cant "simply" create a new runtime release as its coupled with the entire linkml release infrastructure :P |
Do I understand correctly that you can’t release |
No that I can w/o a problem, but then I would have to do the MODEL update in linkml (the promise) as a second runtime release. So:
|
|
Ah, so what you want is for the fix to be present in the version of the model embedded in Well, in that case, the approach here looks good to me, but personally I think I would favour replacing the use of Up to you. (Related: I mentioned that before, but: LinkML needs to clarify what is the intended method to validate a schema. Unless I am mistaken, there are not one, not two, but three different methods:
It’s unclear why or whether we need three different methods, and which one should be used in which circumstances.) |
|
I am not really following the complications but if it makes anything easier, as far as im concerned you can add the updated metamodel to whatever version is easiest! |
This PR tests #243 together with an rc1 release of linkml runtime.
In case you did not see the name of this PR:
DO NOT MERGE THIS