Introduce EC 3.3 JSON Schema

[hl662]

Introduce EC 3.3 JSON Schema, for now, changes involve only the Format object, inside of ecschema-item.schema.json:

• Add bearing, ratio, azimuth to formatType enums
• Add revolutionUnit, azimuthBase, azimuthBaseUnit, azimuthCounterClockwise properties to Format for bearing and azimuth types
• Add ratioType for ratio type
• Add stationBaseFactor property for station format types
• Updated staionOffsetSize to be an integer type, instead of number type. stationBaseFactor is using the same thing.
• Flesh out the precision pattern - it's now an integer, that's either from 0-12 for decimal precision, or powers of 2 for fractional precision. Utilized oneOf syntax to handle above

[Copilot]

Pull Request Overview

This PR introduces EC 3.3 JSON Schema support by creating new schema files for ECSchema validation. The main enhancement is the introduction of new format types (bearing, ratio, azimuth) and their associated properties in the Format object definition.

Key Changes:

• Add new JSON schema files for EC 3.3 support
• Introduce bearing, ratio, and azimuth format types with their specific properties
• Update precision definition to support both decimal (0-12) and fractional (powers of 2) precision patterns
• Convert station offset size from number to integer type

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
System/json_schema/ec33/ecschema.schema.json	New top-level EC 3.3 schema definition with core schema structure and references
System/json_schema/ec33/ecschema-item.schema.json	New comprehensive schema item definitions including enhanced Format object with new format types and properties

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[ColinKerr]

@rschili @diegoalexdiaz We are not yet ready to implement EC 3.3 but we should bring forwards the proposal so that we can define the spec and json/xml docs. @hl662 needs the format portion for FormatSets which use the latest formatting changes not yet part of EC spec

[rschili]

Reviewing the changes in this PR is tedious because it's all new files, so to see a diff, a manual comparison is needed.
I suggest we hold a "latest" version of those schemas somewhere in this repo, then for further edits we can actually tell what changed.

Nam's suggested changes look fine to me. I wonder if we should use this chance to make additional changes that we want to include here.

I guess all of the ECDb specific stuff is off the table (RequiresRuntimeVersion, ViewDefinition, CalculatedProperty??!?)

We could consider marking things as "Do not affect data model" so we can infer if a schema update may alter the database data and may thus require locking. (Like, mark all descriptions, alias, PropertyCategory things etc.)

[hl662]

This makes sense, I opened a PR that creates an initial jsons for ec 3.3 in draft mode: #591

And after that is merged I can update this PR to point to those drafts instead.

[ColinKerr]

This makes sense, I opened a PR that creates an initial jsons for ec 3.3 in draft mode: #591

And after that is merged I can update this PR to point to those drafts instead.

I don't think we can merge this as is. I think we need to extract the format portion and make it an independent spec that can then be referenced into the future EC 3.3 spec. The format spec will be locked down once it gets included in format sets but this will leave us room to make additional changes to the EC 3.3 spec up until it actually gets implemented.

@rschili I'm ok with having a WIP version of the schema committed to source but any comprehensive review of changes between two versions will require diffing the released versions of the schema because a WIP schema gets incremental changes committed to it as the spec is defined. This is one reason why I directly review BIS released schema versions instead of relying on the diff of the WIP.

[rschili]

@ColinKerr This is one reason why I directly review BIS released schema versions instead of relying on the diff of the WIP.

That means you have to download the files and use a diff tool on them rather than track the history of a single file in git, yet? I prefer the git way, it lets me see for each line/change who made it and when, while with the released versions, the entire file is flagged as new.
I think there's value in having both.