Skip to content

Conversation

@andrewelamb
Copy link
Contributor

@andrewelamb andrewelamb commented Feb 11, 2026

Problem:

The Curator extensioncan change property names and enum values to a verison thats more friendly to being annotation keys and column headers for Curator. This includes stripping whitespace and special characters. The problem is these were two separate parameters, so a user could do this for only property names, but leave enum values the same. This could cause issues if the data model were doing conditionals:

{
  "$id": "http://example.com/Cell",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "allOf": [
    {
      "if": {
        "properties": {
          "CellType": {
            "enum": [
              "TCell"
            ]
          }
        }
      },
      "then": {
        "properties": {
          "TCellType": {
            "not": {
              "type": "null"
            }
          }
        },
        "required": [
          "TCellType"
        ]
      }
    }
  ],
  "description": "TBD",
  "properties": {
    "CellType": {
      "description": "TBD",
      "enum": [
        "bCell",
        "tCell"
      ],
      "title": "cellType"
    },
    "TCellType": {
      "description": "TBD",
      "title": "tCellType"
    }
  },
  "required": [
    "CellType"
  ],
  "title": "Cell",
  "type": "object"
}

Solution:

create_json_schema and all its helper functions now only have one parameter: use_display_names. When this is True both properties and enum values aren't modifed, and vice-versa. This ensures that enum values and properties will be consistent in the JSON Schema.

@andrewelamb andrewelamb requested a review from a team as a code owner February 11, 2026 16:46
@andrewelamb andrewelamb marked this pull request as draft February 11, 2026 16:56
@andrewelamb andrewelamb marked this pull request as ready for review February 11, 2026 17:06
Copy link
Contributor

@linglp linglp left a comment

Choose a reason for hiding this comment

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

The changes look good to me overall. I like that now we have a single parameter to control if display names are used! One thing that I still think is a little bit confusing is for generating JSON schema, we have either class_label or display_label when generating a JSON schema, but here the option is called use_display_names. Should we make the naming more consistent in a future PR? (use_display_names -> use_display_label)

)

# Create JSON Schema in using display names for both properties names and valid values
schemas, file_paths = generate_jsonschema(
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm is this correct for generating json schema? The function of generate_jsonschema looks like this:

def generate_jsonschema(
    data_model_source: str,
    synapse_client: Synapse,
    data_types: Optional[list[str]] = None,
    output: Optional[str] = None,
    data_model_labels: DisplayLabelType = "class_label",
) -> tuple[list[dict[str, Any]], list[str]]:

There's only data_model_labels option, not use_display_names

Copy link
Contributor

Choose a reason for hiding this comment

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

use__display_names should also be use_display_names

{!docs/tutorials/python/tutorial_scripts/schema_operations.py!lines=56-62}
```

You can have Curator format the property names and/or valid values in the JSON Schema. This will remove whitespace and special characters.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is confusing. With the change to a single use_display_names parameter, you can no longer control property names and valid values independently.


If you don't set `output` parameter the JSON Schema file will be created in the current working directory.

## 8. Create a JSON Schema using display names
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: this should be #9

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