Skip to content
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

docs: initial documents #1

Merged
merged 10 commits into from
Jul 23, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Updated docs
jonaslagoni committed Jul 6, 2021
commit 6e2590d2fad1f946970eca6ed3108861dc461ca9
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -6,7 +6,7 @@
</p>

## Charter
To help explain the process, the project, the SIG and the community, in terms of how they all relate please refer to the [charter](./charter.md).
To help explain the process, the project, the SIG and the community, in terms of how they all relate, please refer to the [charter](./charter.md).

## Code of Conduct
Respect each other. Choose empathy over judgement. Act according to the [Code of Conduct](./CODE_OF_CONDUCT.md).
27 changes: 13 additions & 14 deletions charter.md
Original file line number Diff line number Diff line change
@@ -1,40 +1,39 @@
# JSON Schema IDL charter
The purpose of this charter is to give a brief introduction to the project, the SIG and the community how they all relate.
The purpose of this charter is to give a brief introduction to the project, the SIG, and the community how they all relate.

## Section 0: Guiding Principles

Because of the nature of JSON Schema you don't define the data structure but the validation rules that data should comply with, trying to interpret these rules definitions are a pain-point for many. Providing a clear description of how this can be achieved would help not only the developer that uses JSON Schema in this area, but also help standardize the behavior improving the user experience.
Because of the nature of JSON Schema, you don't define the data structure but the validation rules that data should comply with, trying to interpret these rules definitions is a pain point for many. Providing a clear description of how this can be achieved would help not only the developer that uses JSON Schema in this area, but also helps standardize the behavior improving the user experience.

## Section 1: Scope

Help and clarify how JSON Schema can be interpreted from validation rules to data definition. This extends to how those data definitions can be represented in any programming language. To accommodate the JSON Schema spec and the interpretation process a code generation vocabulary will be created.

Implementations is neither in or out of scope for the SIG, but it is not a high prioritization.
Implementations are neither in nor out of scope for the project, but it is not a high prioritization.

## Section 2: Relationship with JSON Schema organization.

The SIG is not involve with the actual JSON Schema specification, they are nothing more then a user of it. The JSON Schema organization may force this SIG group to comply with organization level code of conducts, workflow changes, etc.
The project is not involved with the actual JSON Schema specification, they are nothing more than a user of it. The JSON Schema organization may force this project to comply with the organization-level code of conduct, workflow changes, etc.

## Section 3: The Special interest group

SIG memberships are not time-limited. There is no maximum size of the SIG. It is expected that the SIG members actively participate in discussions and maintain the repository, otherwise they will remain a contributor.
The SIG members are no different from the regular community besides it is their responsibility to understand all points of view of the community and push the project forward.

Any SIG members that does not actively participate in discussions and maintain the repository within 30 days will be removed from the SIG list and be contributors.
The community can get involved by jumping into discussions in issues, pull requests, etc, as long as the [Code of Conduct](./CODE_OF_CONDUCT.md) and [git workflow](./git_workflow.md) is adhered to.

The working group is currently made up of the following individuals, and feel free to submit issue requested to be added.

- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/))
- Jason?
SIG memberships are not time-limited. There is no maximum size of the SIG. It is expected that the SIG members actively participate in discussions and maintain the repository, otherwise they will remain a contributor.

## Section 4: Roles & Responsibilities
Any SIG members that do not actively participate in discussions or maintain the repository within 30 days will be removed from the SIG list and return to being contributors.

The SIG members are no different from the regular community beside it is their responsibility to understand all points of view of the community and push the project forward.
The SIG group is currently made up of the following individuals. Feel free to submit an issue requested to be added.

The community can get involved by jumping into discussions in issues, pull requests, etc, as long as the [Code of Conduct](./CODE_OF_CONDUCT.md) and [git workflow](./git_workflow.md) is adhered to.
- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/))
- Jason?

## Section 5: Definitions
## Section 4: Definitions

Definitions that should be clarified to align meaning.

- **Validation rules**, i.e. a JSON Schema as such `{type: string}` define that data should validate against a string, it does not define that the data is a string. For small validation rules there is almost no difference, but more complex ones it become apparent.
- **Validation rules**, i.e. a JSON Schema as such `{type: string}` define that data should validate against a string, it does not define that the data is a string. For small validation rules, there is almost no difference, but with more complex ones it becomes apparent.
- **Data definition**, i.e. it defines the exact structure of the data.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add any more definitions?