Skip to content

HotFix bug schema version#1927

Merged
JoshuaSBrown merged 32 commits intostagingfrom
devel
Apr 1, 2026
Merged

HotFix bug schema version#1927
JoshuaSBrown merged 32 commits intostagingfrom
devel

Conversation

@JoshuaSBrown
Copy link
Copy Markdown
Collaborator

@JoshuaSBrown JoshuaSBrown commented Apr 1, 2026

Summary by Sourcery

Add LinkML schema engine support across web UI, core server, CLI, and clients, including external schema API integration, while tightening schema ID/version handling and bumping component versions.

New Features:

  • Introduce selectable schema engine type (JSON Schema or LinkML) in the web schema dialog with appropriate templates, editor modes, and schema format metadata.
  • Add LinkML schema engine wiring in the core server using an external schema API for storage and validation, configurable via new LinkML schema API URL/token settings.
  • Extend Python client library and CLI to support schema type/format parameters when creating, revising, and updating schemas, enabling LinkML workflows.

Bug Fixes:

  • Ensure schema IDs created via the web API always include the :0 version suffix to match backend expectations.
  • Correct metadata schema selection in the web data dialog to avoid duplicating version suffixes when choosing schemas.
  • Handle optional system flag safely during schema rollback in the core server to avoid missing-field errors.
  • Normalize error handling from the external schema API and relax YAML syntax gating so non-JSON schemas are not incorrectly blocked.

Enhancements:

  • Persist schema type and format fields in the database and propagate them through server handlers for correct validator selection.
  • Adjust schema validation logic so JSON validation is only applied to json-schema definitions, preserving backward compatibility for existing schemas.
  • Refine metadata validation plumbing to pass user context into schema handler validation and use consistent metadata format selection.
  • Improve integration tests by splitting SchemaHandler tests into JSON and LinkML suites and expanding coverage of full schema lifecycles and validation behavior.
  • Update external schema validator and storage interfaces to support caching no-ops and external content management for non-JSON schemas.

Build:

  • Update integration test CMake configuration to run separate SchemaHandlerJson and SchemaHandlerLinkML tests against ArangoDB and a mock schema API, and refresh Docker image and port settings for the test stack.
  • Expose new environment variables and config generation in shell scripts for wiring LinkML schema API URL and token into core and deployment configs.
  • Bump project, protocol, web, core, repo, and Python client version numbers to the next minor release series.

CI:

  • Adjust integration test harness scripts (including mock schema service startup) to use the new mock port and readiness checks compatible with the updated schema API.

Deployment:

  • Propagate LinkML schema API environment variables through generated deployment configs so external schema services can be enabled or disabled per environment.

Documentation:

  • Update code-level docstrings for schema commands in the Python client and CLI to describe the new schema type/format parameters and revised return types.

Tests:

  • Add new integration test suites for SchemaHandler using both JSON Schema and LinkML engines to cover create, view, update, revise, delete, search, and metadata validation flows.
  • Enhance SchemaAPIClient integration tests with updated default ports and improved error detail handling for LinkML validation failures.

JoshuaSBrown and others added 30 commits February 19, 2026 14:59
#1861)

* fix: prevent defaults being set to undefined, and interpret numbers and enums as strings.

* chore: Auto-format JavaScript files with Prettier
…nance, metricThread and task_worker (#1885)

Co-authored-by: Joshua S Brown <joshbro42867@yahoo.com>
Co-authored-by: Joshua S Brown <brownjs@ornl.gov>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
…e and default to different database for tests (#1917)
… cmake (#1918)

Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Apr 1, 2026

Reviewer's Guide

Adds first-class support for both JSON Schema and LinkML schema types across the web UI, Python client, core server, and integration tests, including type/format propagation, external LinkML schema API wiring, metadata validation, and version bumping.

Sequence diagram for LinkML schema creation and storage

sequenceDiagram
    actor User
    participant WebUI as Web_UI_dlg_schema
    participant WebAPI as Web_API_datafed_ws
    participant Core as Core_Server_SchemaHandler
    participant DB as DatabaseAPI
    participant ExtStore as ExternalSchemaStorage
    participant ExtAPI as External_Schema_API

    User->>WebUI: Open schema dialog (mode_new)
    WebUI->>WebUI: curType = "linkml"
    WebUI->>WebUI: jsoned.setMode(ace/mode/yaml)
    User->>WebUI: Enter id, description, type=linkml
    User->>WebUI: Submit

    WebUI->>WebAPI: POST /api/sch/create
    activate WebAPI
    WebAPI->>WebAPI: if id has no colon: id = id+":0"
    WebAPI->>Core: SchemaCreateRequest(id, def, type=linkml, format=yaml,...)
    deactivate WebAPI

    activate Core
    Core->>DB: schemaCreate(arango_req with def="{}")
    activate DB
    DB->>DB: Persist stub schema (type=linkml, format=yaml, def="{}")
    DB-->>Core: SchemaDataReply
    deactivate DB

    Core->>ExtStore: storeContent(schema_id, format=yaml, def)
    activate ExtStore
    ExtStore->>ExtAPI: POST /schemas (LinkML definition)
    ExtAPI-->>ExtStore: 201 Created
    ExtStore-->>Core: true
    deactivate ExtStore

    Core-->>WebAPI: SchemaDataReply
    WebAPI-->>WebUI: JSON reply
    WebUI-->>User: Schema created (type=LinkML)
Loading

Sequence diagram for LinkML metadata validation

sequenceDiagram
    actor Client
    participant CLI as Python_CLI
    participant CoreClient as Python_CommandLib
    participant Core as Core_Server_ClientWorker
    participant Handler as SchemaHandler
    participant DB as DatabaseAPI
    participant Validator as ExternalSchemaValidator
    participant ExtAPI as External_Schema_API

    Client->>CLI: data create/update with metadata and sch_id
    CLI->>CoreClient: _capi.recordCreate/recordUpdate(...)
    CoreClient-->>Core: RecordCreate/RecordUpdateRequest

    activate Core
    Core->>Handler: validateMetadataContent(a_uid, sch_id, metadata)

    activate Handler
    Handler->>DB: setClient(a_uid)
    Handler->>DB: schemaGet(sch_id)
    DB-->>Handler: SchemaData(type=linkml, format=yaml or json)
    Handler->>Handler: schema_type = linkml
    Handler->>Handler: schema_format from record (yaml/json)
    Handler->>Handler: metadata_format = json

    Handler->>Validator: validateMetadata(sch_id, metadata_format, metadata)
    activate Validator
    Validator->>ExtAPI: POST /validate?engine=linkml
    ExtAPI-->>Validator: 200 OK or 422 with errors
    Validator-->>Handler: ValidationResult(valid, errors)
    deactivate Validator

    Handler-->>Core: errors string
    deactivate Handler

    alt errors not empty
        Core-->>CoreClient: Error reply (validation failed)
        CoreClient-->>CLI: Raise exception / print errors
        CLI-->>Client: Show validation errors
    else
        Core-->>CoreClient: Success reply
        CoreClient-->>CLI: Success
        CLI-->>Client: Operation completed
    end
    deactivate Core
Loading

Sequence diagram for schema creation from Python CLI with type and format

sequenceDiagram
    actor User
    participant CLI as datafed_CLI
    participant Cmd as CommandLib
    participant Core as Core_Server

    User->>CLI: datafed schema create SID --definition-file sch.yaml -t linkml --format yaml
    CLI->>CLI: Validate options (definition xor definition_file)
    CLI->>Cmd: schemaCreate(schema_id, definition_file, description, public, system, schema_type=linkml, schema_format=yaml)

    activate Cmd
    Cmd->>Cmd: _load_schema_file(sch.yaml) -> definition
    Cmd->>Cmd: if schema_type=="json-schema" then _validate_json(definition)
    Cmd->>Core: SchemaCreateRequest(id="SID:0", def=definition, type=linkml, format=yaml,...)
    deactivate Cmd

    Core-->>Cmd: SchemaDataReply
    Cmd-->>CLI: Reply
    CLI-->>User: Print created schema info (type=linkml, format=yaml)
Loading

Class diagram for extended schema handling (JSON Schema and LinkML)

classDiagram
    class Config {
        +unordered_map~string,SchemaAPIConfig~ schemas
        +static Config& getInstance()
    }

    class SchemaAPIConfig {
        +string base_url
        +string bearer_token
        +bool isConfigured()
    }

    class SchemaHandler {
        -DatabaseAPI& m_db_client
        -SchemaFactory m_schema_factory
        +SchemaHandler(DatabaseAPI a_db_client)
        +handleCreate(string a_uid, SchemaCreateRequest a_request, AckReply a_reply, LogContext log_context)
        +handleRevise(string a_uid, SchemaReviseRequest a_request, AckReply a_reply, LogContext log_context)
        +handleUpdate(string a_uid, SchemaUpdateRequest a_request, AckReply a_reply, LogContext log_context)
        +validateMetadataContent(string a_uid, string a_sch_id, string a_metadata, LogContext log_context) string
    }

    class SchemaFactory {
        +registerStorage(string type, ISchemaStorage storage)
        +registerValidator(string type, ISchemaValidator validator)
        +setDefaultSchemaType(string type)
        +getStorage(string type) ISchemaStorage
        +getValidator(string type) ISchemaValidator
    }

    class ISchemaStorage {
        <<interface>>
        +storeContent(string id, string format, string content, LogContext log_context) bool
        +updateContent(string id, string format, string content, LogContext log_context) bool
    }

    class ArangoSchemaStorage {
        +storeContent(string id, string format, string content, LogContext log_context) bool
        +updateContent(string id, string format, string content, LogContext log_context) bool
    }

    class ExternalSchemaStorage {
        -unique_ptr~SchemaAPIClient~ m_client
        +ExternalSchemaStorage(unique_ptr~SchemaAPIClient~ a_client)
        +storeContent(string id, string format, string content, LogContext log_context) bool
        +updateContent(string id, string format, string content, LogContext log_context) bool
    }

    class ISchemaValidator {
        <<interface>>
        +validateMetadata(string schema_id, string schema_format, string metadata, LogContext log_context) ValidationResult
        +hasValidationCapability() bool
        +cacheSchema(string schema_id, string schema_format, string schema_def, LogContext log_context) bool
    }

    class JsonSchemaValidator {
        +JsonSchemaValidator(shared_ptr~ISchemaStorage~ storage)
        +validateMetadata(string schema_id, string schema_format, string metadata, LogContext log_context) ValidationResult
        +hasValidationCapability() bool
        +cacheSchema(string schema_id, string schema_format, string schema_def, LogContext log_context) bool
    }

    class ExternalSchemaValidator {
        -unique_ptr~SchemaAPIClient~ m_client
        -string m_engine
        +ExternalSchemaValidator(unique_ptr~SchemaAPIClient~ a_client, string engine)
        +validateMetadata(string schema_id, string schema_format, string metadata, LogContext log_context) ValidationResult
        +hasValidationCapability() bool
        +cacheSchema(string schema_id, string schema_format, string schema_def, LogContext log_context) bool
    }

    class SchemaAPIClient {
        -string m_base_url
        -string m_bearer_token
        +SchemaAPIClient(SchemaAPIConfig config)
        +validateMetadata(string schema_id, string engine, string schema_format, string metadata, string errors, string warnings, LogContext log_context) bool
    }

    class DatabaseAPI {
        +schemaCreate(SchemaCreateRequest a_request, SchemaDataReply a_reply, LogContext log_context)
        +schemaRevise(SchemaReviseRequest a_request, SchemaDataReply a_reply, LogContext log_context)
        +schemaUpdate(SchemaUpdateRequest a_request, LogContext log_context)
        +setSchemaData(SchemaData a_schema, Value a_obj)
        +setClient(string uid)
    }

    class SchemaCreateRequest {
        +string id
        +string def
        +string type
        +string format
        +bool pub
        +bool sys
    }

    class SchemaData {
        +string id
        +uint32 ver
        +string def
        +string type
        +string format
        +uint64 cnt
        +string own_id
        +string own_nm
        +string desc
        +bool pub
        +bool depr
        +bool ref
    }

    Config "1" o-- "*" SchemaAPIConfig : schemas
    SchemaHandler --> DatabaseAPI
    SchemaHandler --> SchemaFactory
    SchemaHandler --> ISchemaStorage
    SchemaHandler --> ISchemaValidator
    SchemaFactory --> ISchemaStorage
    SchemaFactory --> ISchemaValidator
    ArangoSchemaStorage ..|> ISchemaStorage
    ExternalSchemaStorage ..|> ISchemaStorage
    JsonSchemaValidator ..|> ISchemaValidator
    ExternalSchemaValidator ..|> ISchemaValidator
    ExternalSchemaValidator --> SchemaAPIClient
    ExternalSchemaStorage --> SchemaAPIClient
    SchemaAPIClient --> SchemaAPIConfig
    DatabaseAPI --> SchemaData
    DatabaseAPI --> SchemaCreateRequest
Loading

File-Level Changes

Change Details Files
Extend schema dialog and web API to handle JSON Schema vs LinkML types, formats, and definitions correctly.
  • Introduce helper functions to choose Ace editor mode, tab label, schema format string, and default templates per schema type.
  • Add a Type selector to the schema dialog, initialize it from existing schema.type and lock it for non-new modes.
  • Switch Ace editor mode and default template when type changes, and render/stash definitions as YAML for LinkML and pretty-printed JSON for JSON Schema.
  • Include schema type and format on new schema create requests, and relax syntax checking to only enforce JSON validation for JSON Schema.
  • Normalize schema IDs for data dialogs to use base-name plus version and ensure web /api/sch/create appends :0 when client omits a version.
web/static/dlg_schema.js
web/static/dlg_data_new_edit.js
web/datafed-ws.js
Propagate schema type/format through Python client and CLI, and adjust validation semantics for non-JSON schema engines.
  • Extend CommandLib.schemaCreate/schemaRevise/schemaUpdate to accept schema_type and schema_format, only enforcing JSON validation when schema_type is json-schema or unspecified for backwards compatibility.
  • Attach type/format fields to SchemaCreate/Revise/Update protobuf messages.
  • Update CLI schema subcommands to surface --type and --format options and forward them into CommandLib.
python/datafed_pkg/datafed/CommandLib.py
python/datafed_pkg/datafed/CLI.py
Wire LinkML external schema engine into the core server, including storage, validation, configuration, and tests.
  • Extend Config to hold per-schema-engine SchemaAPIConfig instances and plumb LinkML schema API configuration via command-line flags and generated config scripts.
  • In SchemaHandler, register ExternalSchemaStorage and ExternalSchemaValidator for the linkml engine when configured, stub out definitions persisted to Arango for external types, and ensure rollback logic tolerates missing sys fields.
  • Adjust validateMetadataContent to set the client from the calling user, track schema/metadata formats, and call validators with the correct metadata format.
  • Normalize SchemaAPIClient error handling for LinkML metadata validation by parsing error details and turning semicolon-delimited error strings into newline-separated messages.
  • Make ExternalSchemaValidator trivially accept cacheSchema calls and ensure ExternalSchemaStorage is non-copyable but still movable.
core/server/client_handlers/SchemaHandler.cpp
core/server/client_handlers/SchemaHandler.hpp
core/server/SchemaAPIClient.cpp
core/server/schema_validators/ExternalSchemaValidator.hpp
core/server/schema_storage/ExternalSchemaStorage.hpp
core/server/Config.hpp
core/server/main.cpp
Persist schema type/format in Arango and expose them via SchemaData, plus test and tooling updates for LinkML integration.
  • Include type and format fields in DatabaseAPI::schemaCreate payload and hydrate them into SchemaData in setSchemaData.
  • Split existing SchemaHandler integration tests into JSON and LinkML suites, add extensive LinkML lifecycle and validation coverage, and adjust CMake integration test wiring and Docker-based fixtures (mock schema and Arango images, ports, and env vars).
  • Adjust mock schema startup script and SchemaAPIClient integration tests for new default port and readiness check, and add environment-driven configuration for LinkML schema API in deployment scripts.
  • Bump version numbers across components to 3.1/5.1 and update Foxx/API minor versions to reflect the new schema capabilities.
core/server/DatabaseAPI.cpp
core/server/tests/integration/CMakeLists.txt
core/server/tests/integration/test_SchemaAPIClient.cpp
core/server/tests/integration/start_mock_schema.sh
core/server/tests/integration/test_SchemaHandlerJson.cpp
core/server/tests/integration/test_SchemaHandlerLinkML.cpp
scripts/generate_datafed.sh
scripts/generate_core_config.sh
cmake/Version.cmake

Possibly linked issues

  • #: PR fixes missing version in web schema IDs (API append :0, picker includes version), matching issue.
  • #: PR fixes schema ID/version concatenation in web (create and picker), resolving the :0:0 display/revision bug

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@JoshuaSBrown JoshuaSBrown changed the base branch from staging to master April 1, 2026 15:26
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 3 issues, and left some high level feedback:

  • In the Python CLI, schema_type defaults to json-schema while schema_format defaults to json even when --type linkml is selected, which can lead to LinkML schemas being created with a format of json; consider either coupling the defaults (e.g., default schema_format=yaml when schema_type=linkml) or validating/enforcing that linkml is only used with yaml.
  • For schemaRevise and schemaUpdate in CommandLib, the new schema_type parameter is only used to gate JSON validation and is not propagated to the request message, while the CLI exposes --type; if the schema engine type is immutable, it may be clearer to omit the flag or explicitly reject attempts to change type rather than silently ignoring it.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- In the Python CLI, `schema_type` defaults to `json-schema` while `schema_format` defaults to `json` even when `--type linkml` is selected, which can lead to LinkML schemas being created with a `format` of `json`; consider either coupling the defaults (e.g., default `schema_format=yaml` when `schema_type=linkml`) or validating/enforcing that `linkml` is only used with `yaml`.
- For `schemaRevise` and `schemaUpdate` in `CommandLib`, the new `schema_type` parameter is only used to gate JSON validation and is not propagated to the request message, while the CLI exposes `--type`; if the schema engine type is immutable, it may be clearer to omit the flag or explicitly reject attempts to change type rather than silently ignoring it.

## Individual Comments

### Comment 1
<location path="python/datafed_pkg/datafed/CommandLib.py" line_range="412-421" />
<code_context>
+                     schema_type=None):
</code_context>
<issue_to_address>
**question:** Schema type for revise/update only affects local validation and is not sent to the server, which can be confusing.

In `schemaRevise` and `schemaUpdate`, `schema_type` only controls whether `_validate_json` runs and is not included in the outgoing request (no `msg.type` set). With `-t/--type` now exposed in the CLI, users may expect this to change the stored schema type, not just validation behavior. If the engine type should be immutable (as in the web UI), either rename this parameter to reflect its validation-only role or propagate it to the request so behavior matches user expectations.
</issue_to_address>

### Comment 2
<location path="core/server/client_handlers/SchemaHandler.cpp" line_range="79-82" />
<code_context>

   // Persist to Arango — exception propagates naturally on failure
-  m_db_client.schemaCreate(a_request, a_reply, log_context);
+  // For external schema types, store a stub in Arango —
+  // the real content lives in external storage.
+  SchemaCreateRequest arango_req(a_request);
+  if (!a_request.type().empty() && a_request.type() != "json-schema") {
+    arango_req.set_def("{}");
+  }
</code_context>
<issue_to_address>
**issue (bug_risk):** Storing `{}` as the schema definition for non-JSON engines may break consumers that rely on the DB’s `def` field.

Non-`json-schema` types now persist a stub (`"{}"`) in `def`, with the actual content stored elsewhere. This preserves validation but changes the meaning of `def` for any code or tooling that reads `SchemaData.def` expecting the full schema. If such consumers exist, they will now see `{}` instead of the real definition. Consider either not setting `def` at all for external types (so clients can detect this) or defining a clear mechanism for clients to retrieve the full definition via the storage/validator layer rather than directly from the DB field.
</issue_to_address>

### Comment 3
<location path="python/datafed_pkg/datafed/CLI.py" line_range="2065" />
<code_context>
 def _schemaCreate(schema_id, definition, definition_file, description, public, system, schema_type, schema_format):
</code_context>
<issue_to_address>
**issue:** CLI help text still claims a JSON schema definition is required despite new LinkML/yaml support.

The `_schemaCreate` help text still states “A JSON schema definition is required” and only mentions JSON, even though we now support `schema_type` (e.g. `linkml`) and `schema_format` (e.g. `yaml`). Please update the wording to reflect all supported schema types and formats so users aren’t misled into thinking only JSON is allowed.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +412 to +421
schema_type=None):
"""
Create a new revision of an existing schema

Creates a new version of the specified schema. Any fields not provided
are carried forward from the current revision. The definition may be
provided directly as a string or read from a local file.

Parameters
----------
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Schema type for revise/update only affects local validation and is not sent to the server, which can be confusing.

In schemaRevise and schemaUpdate, schema_type only controls whether _validate_json runs and is not included in the outgoing request (no msg.type set). With -t/--type now exposed in the CLI, users may expect this to change the stored schema type, not just validation behavior. If the engine type should be immutable (as in the web UI), either rename this parameter to reflect its validation-only role or propagate it to the request so behavior matches user expectations.

Comment on lines +79 to +82
// For external schema types, store a stub in Arango —
// the real content lives in external storage.
SchemaCreateRequest arango_req(a_request);
if (!a_request.type().empty() && a_request.type() != "json-schema") {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): Storing {} as the schema definition for non-JSON engines may break consumers that rely on the DB’s def field.

Non-json-schema types now persist a stub ("{}") in def, with the actual content stored elsewhere. This preserves validation but changes the meaning of def for any code or tooling that reads SchemaData.def expecting the full schema. If such consumers exist, they will now see {} instead of the real definition. Consider either not setting def at all for external types (so clients can detect this) or defining a clear mechanism for clients to retrieve the full definition via the storage/validator layer rather than directly from the DB field.

def _schemaCreate(schema_id, definition, definition_file, description,
public, system, schema_type, schema_format):
"""
Create a new metadata schema. A JSON schema definition is required and
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: CLI help text still claims a JSON schema definition is required despite new LinkML/yaml support.

The _schemaCreate help text still states “A JSON schema definition is required” and only mentions JSON, even though we now support schema_type (e.g. linkml) and schema_format (e.g. yaml). Please update the wording to reflect all supported schema types and formats so users aren’t misled into thinking only JSON is allowed.

@JoshuaSBrown JoshuaSBrown changed the base branch from master to staging April 1, 2026 15:34
@JoshuaSBrown JoshuaSBrown merged commit 07477a4 into staging Apr 1, 2026
5 of 6 checks passed
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.

2 participants