Skip to content

NEVER MERGE (EVER): Fix incorrect use of value slots in extra_slots examples.#244

Closed
matentzn wants to merge 6 commits intomainfrom
pr/243-test
Closed

NEVER MERGE (EVER): Fix incorrect use of value slots in extra_slots examples.#244
matentzn wants to merge 6 commits intomainfrom
pr/243-test

Conversation

@matentzn
Copy link
Copy Markdown
Contributor

@matentzn matentzn commented Apr 2, 2026

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

gouttegd and others added 5 commits March 26, 2026 12:41
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
@matentzn matentzn changed the title Fix incorrect use of value slots in extra_slots examples. NEVER MERGE (EVER): Fix incorrect use of value slots in extra_slots examples. Apr 2, 2026
@matentzn
Copy link
Copy Markdown
Contributor Author

matentzn commented Apr 7, 2026

@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:

  1. Create a proper release of linkml just yet
  2. Create a minor release with just that error fixed (we are not set up for minor releases in linkml the way we are in ODK)

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.

@gouttegd
Copy link
Copy Markdown
Contributor

gouttegd commented Apr 7, 2026

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 linkml-runtime-1.11.0 to be released and (b) merge #243. Why playing with a RC release of the runtime?

@matentzn
Copy link
Copy Markdown
Contributor Author

matentzn commented Apr 7, 2026

Why playing with a RC release of the runtime?

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

@gouttegd
Copy link
Copy Markdown
Contributor

gouttegd commented Apr 7, 2026

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 linkml-runtime-1.11.0 without before releasing linkml-model-1.11.0? That didn’t seem to be a problem before…

@matentzn
Copy link
Copy Markdown
Contributor Author

matentzn commented Apr 7, 2026

Do I understand correctly that you can’t release linkml-runtime-1.11.0 without before releasing linkml-model-1.11.0? That didn’t seem to be a problem before…

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:

  1. Release runtime once to create a model release
  2. Release the model
  3. Release the runtime AGAIN with the updated model

@gouttegd
Copy link
Copy Markdown
Contributor

gouttegd commented Apr 7, 2026

Ah, so what you want is for the fix to be present in the version of the model embedded in linkml-runtime-1.11.0, right? OK, now I get it, sorry.

Well, in that case, the approach here looks good to me, but personally I think I would favour replacing the use of linkml-normalize in the test suite of linkml-model by linkml validate. That command does not suffer from the same bug as linkml-normalize and can already be used with the latest released version of the runtime, without having to use a RC.

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:

  • linkml-normalize --schema <path-to-linkml-meta-schema.yaml> <path-to-schema-to-validate.yaml>
  • linkml validate --schema <path-to-linkml-meta-schema.yaml> <path-to-schema-to-validate.yaml>
  • linkml lint --validate --validate-only <path-to-schema-to-validate.yaml>

It’s unclear why or whether we need three different methods, and which one should be used in which circumstances.)

@sneakers-the-rat
Copy link
Copy Markdown
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants