Comments (10)
@naught101 it's part of this project, just not part of this repo :-)
from json-schema-spec.
This has been discussed before, I've even written up a draft and a vocabulary for how you could implement such a thing (JSON Transform, I believe I called it).
But the problem is most upgrade operations aren't simple things like renaming, but more frequently things like pre-computing indexes or splitting apart a string. I've sort of resigned to using a full scripting language for doing this sort of stuff, otherwise we're just re-inventing XSLT.
I'm not opposed to this as such, but this is outside the scope of JSON Schema validation, which by definition is strictly structural, meaning a validation doesn't depend on the state of any other documents -- you need only the schema and the instance to determine valid or invalid.
There's been proposals for keywords that would depend on external values, like "ensure this integer refers to a valid user id", but that would be better suited for a separate meta-schema (like how we have JSON Hyper-Schema, in addition to JSON Schema validation). I don't know what we would call it... verification, referential consistency, ...?
from json-schema-spec.
As far as the JSON syntax, it's pretty funny--I actually have been working on an "XSLT for JSON" (very alpha and--at least for now--with JavaScript-based templates rather than JSON ones). I even thought about retrieving IndexedDB databases and stores (like XSLT's document()
) but was tunnel-visioned to only thinking of template usage, and it didn't occur to me to use for versioning, so thank you for the aha moment. I see how it would be necessary to overcome limitations otherwise requiring a programmatic approach (including other nuanced behaviors like copying from within one store into another store).
As far as proposals for keywords depending on external values, a separate meta-schema would be fine with me. "Referential consistency" sounds like a very good name choice to me.
(Incidentally, the readOnly
instance property from Hyper Schema (which oddly shows in the changelog as having been removed despite having its own section in the "latest" version) seemed to me like one that might be better placed in a more general meta-schema. Although IndexedDB only has readonly transactions, and not readonly stores, it does seem to fit along with the types of suggestions raised in issue #17 , at least in the sense of its exact manner of enforcement being out of scope of the spec.)
from json-schema-spec.
@brettz9 it sounds like this is a good idea that is, as noted, a bit outside the scope of JSON Schema proper.
Is there any action we need to take here within the project? If not could you please close this?
from json-schema-spec.
Well, is there any place for tracking suggestions to be added to different meta-schemas?
from json-schema-spec.
The validation and hyper-schema meta-schemas (schema.json and hyper-schema.json in this repo) would be tracked here. Any other meta-schemas would be tracked wherever those meta-schemas live.
from json-schema-spec.
I think this is outside the scope of JSON Schema right now, so I'll close this out. However, it's certainly something of interest.
If you have a particular solution for doing this that uses JSON Schema, I'd love to see it.
from json-schema-spec.
I understand why this is out of scope, but I wonder if it might be something worth addressing in the docs. For example, a "recommended versioning/upgrade pathway methodology" or similar.
I'm trying to implement something like this in a private project, and thinking of using something along the lines of:
- A single repository of schemas and upgrade code that can be used stand-alone or as a library in multiple languages
- Schema versions for each object type in subdirectories named after the version.
- A
current_version
file that keeps track of the current stable version of the schema. - A
previousVersion
tag in each version of the schema (e.g.v1.1.0
might havepreviousVersion: 1.0.7
) - A requirement in each schema that all objects have a
schemaVersion
property. - Upgrade function for each version change that can be imported into my apps, with a wrapper script for stand alone operation, in each language I care about (e.g.
upgrade_v1.1.0_from_v.1.0.7.py
,upgrade_v1.1.0_from_v.1.0.7.js
), which handle the upgrade, and which can be chained (with pre-and post-validation). - Some master scripts which detect the current stable schema version, object schema version, and get and run the upgrade function chain.
This feels like a sensible idea, because it keeps all of the validation and upgrade logic in the same place, and allows each part to be used as-needed in each app (in particular we have a large object store that will have objects with various different versions that need upgrading as they are accessed and used by other apps in the system).
I thought I'd chuck this up here because it might be useful as a basis for a more sensible methodology recommendation, and for the possibility that I might get some feedback on it :)
from json-schema-spec.
There's a difference between a specification and "docs." The spec should really be pretty minimalist. This sort of idea should go on the web site or maybe the "understanding JSON Schema" book (although it's not entirely clear what we're doing with the book right now). Both of them have their own repos.
If you just want to discuss things, the slack is a better option (click "Join our Slack" in the upper right on json-schema.org).
from json-schema-spec.
Yeah, OK. I thought the "understanding JSON Schema" book was part of this project, I'll see if there's a relevant issue there.
from json-schema-spec.
Related Issues (20)
- OneOf property is failing during OAS Schema Validation HOT 4
- Intended interplay between "type" and "enum" HOT 2
- Validation Regex Description (section 7.3.8) should follow format of other string validation types
- Enum : Clarification HOT 2
- Build failure due to Relative JSON Pointer specification HOT 1
- Pattern: clarification on whether leading and trailing delimiters are allowed or required HOT 2
- Omitted `prefixItems` vs empty HOT 1
- Evaluation path: relative to $ref resolved schema or resource/document root? HOT 4
- JSON
- Feature Request: Constraint for single occurrence of a property structure in JSON Schema HOT 1
- Use JSON Pointers instead of 'properties' or 'prefixItems' keywords HOT 16
- Json-schema HOT 1
- How do I get the use Json to get the "about" and "mention" property to work with several subjects? HOT 4
- Statement on annotation values is unclear
- To validate CRUD of table information with a single Json-Schema, we propose an attribute for PrimaryKey. HOT 3
- Futuristic
- owner
- Typo in section 8.2.3 of draft 7 leading to wrong information HOT 4
- String format validation for IP addresses with network mask
- File extension in $id HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from json-schema-spec.