Draft: SIP for JSONSchema version #24
Conversation
|
|
||
| - [x] Singer Specification - required capabilities and behaviors | ||
| - [ ] Singer Specification - optional capabilities and behaviors | ||
| - [ ] Singer best practices and other guidance |
There was a problem hiding this comment.
Is this a best practice or a required capability? Not clear to me
There was a problem hiding this comment.
After filling out the layered model proposal, I'd classify this as a standard I think (under that refactored model). Just because we all, as far as I know, have ascribed to it thus far. So I hope for opposition or sure acceptance of that statement :)
However, if this covers the use of the $schema keyword as per the previous comment. That would fall into a best practice under the layered proposal, which is non-required but recommended for targets to handle.
|
|
||
| ### What specific change do you propose to make? | ||
|
|
||
| We should document in the Singer Spec that Singer taps and targets expect **Draft 04** version of the JSON Schema spec. |
There was a problem hiding this comment.
To expand a bit on this, we could even go as far as saying something like
Targets default to expecting Draft04 to be sent. To use a different json schema version use the $schema keyword. (To date nothing uses anything past Draft04 to my knowledge but I'm probably wrong based on how many taps/targets there are)
Taps should default to sending Draft04 unless they have a reason to use a later version of Json schema.
There was a problem hiding this comment.
Should we also include a why here? ie Draft04 is widely used and works for the vast majority of use cases as of today.
There was a problem hiding this comment.
I like that statement in your first comment. No real need for a why in my opinion. The base Singer JSON Schema has been draft 4 and anything higher should be justified and proposed for its features. It seems okay to start there and move forward.
|
singer-io/getting-started#87 , added a PR to get this started. Mainly because I'm not clear if there should be anything in Best practices, or if the wording should be tweaked more |
|
|
||
| ### TL;DR Overview | ||
|
|
||
| We should provide guidance for recommended and supported JSON Schema versions to tap and target developers which |
There was a problem hiding this comment.
This sentence seems incomplete. Is there something missing from the overview statement?
|
|
||
| ### What specific change do you propose to make? | ||
|
|
||
| We should document in the Singer Spec that Singer taps and targets expect **Draft 04** version of the JSON Schema spec. |
There was a problem hiding this comment.
I like that statement in your first comment. No real need for a why in my opinion. The base Singer JSON Schema has been draft 4 and anything higher should be justified and proposed for its features. It seems okay to start there and move forward.
|
|
||
| - [x] Singer Specification - required capabilities and behaviors | ||
| - [ ] Singer Specification - optional capabilities and behaviors | ||
| - [ ] Singer best practices and other guidance |
There was a problem hiding this comment.
After filling out the layered model proposal, I'd classify this as a standard I think (under that refactored model). Just because we all, as far as I know, have ascribed to it thus far. So I hope for opposition or sure acceptance of that statement :)
However, if this covers the use of the $schema keyword as per the previous comment. That would fall into a best practice under the layered proposal, which is non-required but recommended for targets to handle.
|
|
||
| ### Are there any downsides to this change? | ||
|
|
||
| There are no downsides to this change. |
There was a problem hiding this comment.
I would say there are always potential downsides. All specs have tradeoffs in my opinion. This one, I think, may be accepting a lack of verbosity for increased simplicity since Singer generally uses the JSON Schema spec for very basic data type specification and prefers to limit the usage of the more advanced value validation features.
|
|
||
| ### Which users are affected by the change? | ||
|
|
||
| Users are not affected. |
There was a problem hiding this comment.
Users may be affected if they don't support Draft 4 at a minimum?
|
|
||
| ### Prototype Implementations | ||
|
|
||
| Not applicable. |
There was a problem hiding this comment.
I'd like to see more information here. I mean, I know that every singer-io tap has been held to the Draft 4 specification because that is what we use at Stitch to my knowledge.
|
|
||
| ### Excluded Alternatives | ||
|
|
||
| Not applicable. |
There was a problem hiding this comment.
Maybe good to include the reasoning for not proposing to just keep the latest spec here?
Provides guidance for supported and recommended version(s) of the JSON Schema Draft, as discussed in #17.
Rendered draft: https://github.com/MeltanoLabs/Singer-Working-Group/blob/10188791dec992d436d8d4a59e2c55b4790216a7/proposals/draft/Draft%20-%20JSONSchema%20Version%20Guidance.md