KhronosGroup / KhronosGroup/glTF-Validator
Design a public API for native apps
- Dominant language
- Dart
- Stars
- 470
- Forks
- 77
- PR merge metrics
- No merged PRs in 30d
Description
Just like `npm` and command-line version, the validator needs a convenient and well-documented public API for native apps. Open questions:
- [x] How to pass a list of ignored issues and a map of overridden severities? Could apps pass a YAML string?
- [x] Validation report is represented as JSON document. Could the validator just return it as a string?
- [ ] How should the validator get asset's data? Should it access files directly (like command-line version) or expect data from calling apps (like `npm` build)? How external resources should be accessed?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the existing npm and command-line interfaces and the checked API decisions in this issue. Resolve how calling apps provide asset data and how external resources are accessed, then define and document the public native-app API and its validation-report behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dart
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100