Repository navigation
1.12: structured patterns in an imported schema are no longer interpolated with the importing schema's settings #4135
Description
In 1.12.1, linkml generate json-schema leaves {setting} placeholders as literal text when the structured_pattern is in an imported schema and settings: is in the importing one. 1.11.1 interpolates both. There's no warning. In nmdc-schema, SchemaView on src/schema/nmdc.yaml leaves 20 of 57 classes with {id_nmdc_prefix} in their id pattern (1.12.0 and 1.12.1).
main.yaml:
id: https://example.org/main
name: main
prefixes:
linkml: https://w3id.org/linkml/
default_range: string
imports:
- linkml:types
- mod
settings:
pfx: "ex"
classes:
Local:
attributes:
id:
identifier: true
structured_pattern:
syntax: "^{pfx}:local-[0-9]+$"
interpolated: truemod.yaml has the same shape with no settings:, class Imported, and syntax "^{pfx}:imp-[0-9]+$".
id pattern per class, measured 2026-10-14 with matching linkml and linkml-runtime versions:
| linkml | Local | Imported |
|---|---|---|
| 1.11.1 | ^ex:local-[0-9]+$ |
^ex:imp-[0-9]+$ |
| 1.12.1 | ^(?:^ex:local-[0-9]+$)$ |
^(?:^{pfx}:imp-[0-9]+$)$ |
I reported the ^(?:...)$ wrapping separately: #4134.
SchemaView.resolve_pattern says it uses "settings from the schema that defined the supplied definition", so this looks deliberate (#3832). @pkalita-lbl, could an imported schema fall back to the importing schema's settings? If not, could an unresolved placeholder at least raise a warning?
Activity
turbomam commentedon Oct 14, 2026
Update from today's dev call: @pkalita-lbl explained that
^(?:...)$wrapping is the intendedpartial_matchfix (so I closed #4134), and thatmaterialize_patternsis deprecated becauseinduced_slotandinduced_typenow do the materialization.That doesn't change this issue. A
structured_patternin an imported schema with nosettings:of its own still comes out with literal{pfx}placeholders on 1.12.1, where 1.11.1 used the importing schema's settings. The open questions are the same: should an imported schema fall back to the importing schema's settings, and if not, could an unresolved placeholder at least warn?turbomam commentedon Oct 14, 2026
Where
settings:has to live for a pattern to resolve on linkml-runtime 1.12.1, tested 2026-10-14. The root schema hassettings: {pfx: ex}and imports three modules; each class has anidwithstructured_pattern: {syntax: "^{pfx}:x-[0-9]+$", interpolated: true}.induced_slot("id", ...).pattern^(?:^ex:d-[0-9]+$)$^(?:^{pfx}:a-[0-9]+$)$settings:^(?:^ex:b-[0-9]+$)$^(?:^{pfx}:c-[0-9]+$)$So settings come only from the defining module's own
settings:(PatternResolverreadsschema_view.schema.settingsof that one schema), not from what it imports or what imports it. Putting all settings in the root module, which is how nmdc-schema and MIxS-derived schemas are laid out, is the case that breaks. Generating from a merged single-file schema works.Until there's a decision here, I'm planning to give each module its own
settings:in nmdc-schema.