-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension schemas #119
Extension schemas #119
Conversation
@@ -0,0 +1,28 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a submodule instead of copying all of these here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These files are output from the importSchema.js
script. Certain values have changed, for example "$ref" : "glTFid.schema.json"
has been given a working relative path, and other automated changes have been made to improve VSCode's handling of glTF schema files (see util/README.md
for details).
Might be interesting to submodule the main repo for import purposes, but most developers don't need this. I expect most people who work on this project just want to build directly from source without re-importing the schemas, and so wouldn't have use for the submodule.
util/README.md
Outdated
|
||
# Extensions | ||
|
||
The files in the `schemas/glTF-2.0/extensions` folder itself (but not parent or child folders) are hand-edited, not from import. They each take the form of `{schemaName}.extensions.schema.json`. When the `importSchema.js --extensions` flag is used, the import script will look for files of `{schemaName}.schema.json` in the main schema folder that have a matching `*.extensions.schema.json` file in the `extensions` folder, and where found, will override the `schema.properties.extensions` object to point to the schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh the hand-editing makes me sad... oh well.
@@ -131,12 +143,59 @@ function upgradeDescriptions(data) { | |||
} | |||
} | |||
|
|||
function transformFile(inputFile, outputFile) { | |||
function transformSharedFolder(data, options) { | |||
for (var key in data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the 'var's below could be const
Work-in-progress: The hand-edits were making me sad too, so I'm migrating them to a legit lookup table.
|
OK. No new hand-edited schemas are being submitted with this PR. A new look-up table extensionMap2.0.json has taken the role of helping |
This PR introduces a new means to wire up known glTF extension schemas to VSCode's JSON validation service. Initially this is just hookup for
KHR
extensions, but in the future this is expected to expand to also cover some well-documented vendor extensions. (Once this is merged, please open a new issue to request any vendor extension you would like to see covered here).The new extension schemas are all imported via the
util/importSchema.js
script, the same way the core glTF schemas are, that automates a few key modifications needed for best handling of the schemas in VSCode's JSON validation. A new lookup table,util/extensionMap2.0.json
offers the wire-up instructions for connecting particular core glTF schema extension objects to particular extensions that target those objects. A new scriptutil/importAll.sh
will re-run the import for all supported schemas at once.Unknown extensions are still permitted by the editor (although the glTF Validator will still complain about unknown extension prefixes and the like, as expected). Known extensions will now have complete JSON schema validation, with hover tooltips, auto-complete (CTRL-space), and document problems called out for missing properties and unknown values.
Thanks to @lexaknyazev for a key piece of schema advice that allowed this effort to move forward.
TODO: