-
-
Notifications
You must be signed in to change notification settings - Fork 288
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
Improve handling of profiles vs. sets #151
Comments
@handrews This is a natural follow-up to your Groups post about different uses of "additionalProperties" |
@awwright thanks! Did you look at #119 with I'm not 100% certain, but I think that anything that attempts to solve this problem will have the same complexities around negated schemas ( I am leery of option 1 as it gets into splicing bits of validation schemas from one place to another- the same problem I and others have with I'm not quite sure I understand option 2, could you walk through the algorithm in a bit more detail? I need to spend a bit more time with your set-vs-profile concept. I'm not entirely sure I'm grasping the difference, particularly in your description of profile usage (set seems straightforward). In the profile discussion are Q.X.json and Q.Y.json two instance documents describing the same resource but conforming to different schemas? Also, do you really mean |
See #214 for another approach to the reuse-with-additionalProperties aspect of the "profiles" use case. It is a relatively concise workaround using only current keywords, which could perhaps be a starting point for a more elegant solution. |
Re-reading this, I could probably phrase the issue to be a little clearer and straightforward. |
Assuming you really meant The schema is versioned, the resource itself is not. A representation would declare all of the schema versions against which it might validate. If a representation validates against a given schema version, then it may be interpreted according to that version's documented semantics. For this, I have not seen a need for any additional keywords. Either the server ensures that it only connects the instance to schemas against which it validates (so the client can just look and see if it works with a version it understands), or the client is expected to validate against a specific schema version to determine whether that particular instance is usable. Does any of this sound at all relevant here? |
VOTE-A-RAMA!!! It's time to gauge community support for all re-use/extension/additionalProperties proposals and actually make some decisions for the next draft. Please use emoji reactions ON THIS COMMENT to indicate your support.
This is not a binding majority-rule vote, but it will be a very significant input into discussions. Here are the meanings for the emojis:
If you want to explain in more detail, feel free to add another comment, but please also vote on this comment. The vote should stay open for several weeks- I'll update this comment with specifics once we see how much feedback we are getting and whether any really obvious patterns emerge. |
I am not sure what the proposal is here. |
I'm hoping @awwright will expand on his earlier comment about clarifying :-) |
I'm not actually sure which tangent this is going towards... But if the distinction I made in the original post (the difference between being an instance of a set and being an instance of a profile) makes sense, let's move it to a wiki page. Then we can figure out some ways to implement or honor it, like write some detailed use cases. Close this out? |
@awwright yes all of that sounds like a good plan. It's a good distinction to explore, but a wiki page sounds like a better home while figuring it out. |
JSON Schema is conflating two mutually exclusive ideas of class membership, and it's causing a handful of problems around "additionalProperties", especially when you have
"additionalProperties": false
Types of taxonomy relationships
Associating an instance as a member of a group is done one of two ways:
These forms of association exhibit different behaviors.
Sets
Sets are motivated by the mathematical concept of a set and members of a set.
An instance in a set is uniquely identified by its contents.
JSON Schema can be used to create subsets - in which every member of a subset is by definition also a member of the superset.
If X and Y are sets described by schemas, where Y is a subset of X, then any instance of Y will also be an instance of X.
Profiles
Profiles are similar in function to media types. A media type is a short, standardized string that associates with a string of octets to form a document. Profiles are somewhat more abstract as a concept.
Profiles are often used to tell people they can treat the document a certain way, that they couldn't otherwise, even if it happened to otherwise look like a valid document. For example, a media type or profile lets people know if the document is executable or not -- an important security measure to ensure that plain text documents can't get executed as a program! (See also "polyglot programming" where a program is valid in two different languages, possibly one benign and one malicious)
An instance of a profile can determine how it is uniquely identified; frequently a URI is used as an identifier, and there can be multiple instances with identical data.
A resource can be described my multiple profiles. Rules can be applied to profiles and implications made about their membership. If X and Y are profiles, where Y is a subclass of X, any instance of Y is also an instance of X.
Sometimes we want to use JSON to describe properties only when they're an instance of a profile, using this subclass logic. For example, instances of X have property A, and A is only found in instances of X; instances of Y have property B, and property B is only found in instances of Y.
How do we describe data like this? There's a few options:
Use one JSON document per profile per resource. If I have a resource Q that is an instance of Y, then have two JSON documents <Q.X.json> and <Q.Y.json>.
Allow additionalItems on a document, and ignore unknown properties. List the document having every profile, including superclasses (though it might sometimes be possible to omit superclasses or any profiles implied from other profiles). Properties across profiles must not overlap.
Prohibit additionalItems on a document. List the document as having only one media-type profile. Duplicate properties from superclasses, and optionally specify each property as copied/inherited from that superclass.
Solutions
How do we solve this?
Option for additional keywords
Create a keyword that explicitly creates a subclass/superclass relationship. "properties" and some other keywords would get imported to the current document according to a well-defined behavior.
Create a keyword that specifies a property matches (was inherited from) a property in another schema.
Keyword to the current instance against another schema, with special instructions to ignore all properties not from a certain list - side-stepping
additionalProperties: false
if it exists.The text was updated successfully, but these errors were encountered: