Gregsdennis/admin updates

.gitignore

@@ -1 +1,3 @@
-*.DS_Store
+*.DS_Store
+
+notes/

README.md

@@ -7,7 +7,7 @@
 [![Financial Contributors on Open Collective](https://opencollective.com/json-schema/all/badge.svg?label=financial+contributors)](https://opencollective.com/json-schema) 
 
 <p align="center">
-  <em>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</em>
+  <em>Help and clarify how data definition and JSON Schema's validation rules can interact. This includes how those validation rules can represent code in any programming language.</em>
 </p>
 
 <!-- ALL-CONTRIBUTORS-BADGE:START - Do not remove or modify this section -->
@@ -17,16 +17,20 @@
 ## Status
 
 While the project is only first getting started, the initial agenda is:
-1. Define a processing model for interpreting JSON Schema to data definitions.
-    * Define code generation vocabulary as needed, while the processing model is being defined
+1. Identify programming language paradigms and determine how they might interact with JSON Schema.
+2. Identify areas where JSON Schema is insufficiently expressive to handle these language paradigms and define a new vocabulary to fill the gaps.
+3. Define a processing model for translating between data definition and JSON Schema.
 
 ## 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).
 
 ## Code of Conduct
-Respect each other. Choose empathy over judgement. Act according to the [Code of Conduct](./CODE_OF_CONDUCT.md).
+
+Respect each other. Choose empathy over judgement. Act according to the [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md).
 
 ## Getting involved
+
 If you want to review changes, creating documentation, help form suggestions or take charge in figuring out a specific task, we welcome any way you want to get involved.
 
 If you find an issue you would like to work on you can drop a comment, ask questions or discuss the approaches. Or if you see we are missing specific things feel free to create new issues.
@@ -36,9 +40,11 @@ We have a dedicated slack channel `#vocab-idl`- in the JSON Schema slack, join t
 You can use this channel if you don't know where to get started, discuss specifics of issues, get updates, or in general hang out.
 
 ## Contributing
+
 In case contributions are for changing content on git, please refer to [git workflow](./git_workflow.md).
 
 Any contributions that changes the content of this repository MUST go through pull requests.
+
 ## Contributors ✨
 
 Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):

charter.md

@@ -1,13 +1,14 @@
 # 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.
 
 ## 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 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.
+Because of the nature of JSON Schema (constraints, not data definition), trying to interpret these rules definitions is a pain point for many. Providing a clear description of how this can be achieved would standardize the behavior improving the user experience and thus help any developers working with JSON Schema.
 
 ## 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.
+Help and clarify how data definition and JSON Schema's validation rules can interact. This includes how those validation rules can represent code in any programming language. To accommodate the JSON Schema spec and the interpretation process, a code generation vocabulary will be created.
 
 Implementations are neither in nor out of scope for the project, but it is not a high prioritization.
 
@@ -21,23 +22,23 @@ The JSON Schema organization will force this project to comply with the organiza
 
 ## Section 3: The Special interest group
 
-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. 
-
-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 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.
 
+The community can get involved by jumping into discussions in issues, pull requests, etc, as long as the [Code of Conduct](https://github.com/json-schema-org/.github/blob/main/CODE_OF_CONDUCT.md) and [git workflow](./git_workflow.md) is adhered to.
 
 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.
 
 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 group is currently made up of the following individuals. Feel free to submit an issue requested to be added. 
 
-- Jonas Lagoni ([Senior Software Engineer at Postman, working on AsyncAPI](https://www.linkedin.com/in/jonaslagoni/))
+- [Greg Dennis](https://github.com/gregsdennis)
+- [Jonas Lagoni](https://github.com/jviotti)
 - [Jason Desrosiers](https://github.com/jdesrosiers)
 
 ## 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 with more complex ones it becomes apparent. 
-- **Data definition**, i.e. it defines the exact structure of the data.
+- **Validation rules**, i.e. a JSON Schema as such `{ "type": "string" }` defines that data, as represented in the JSON data model, should be a string; it does not define that the data must be a string in programming languages.  For example,`"2023-10-31"` is a string in JSON; however, this value represents a date, for which there will likely be a dedicated type separate from a string in many programming languages. 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.  This is often how programming languages build types.  These type systems are generally considerably more extensive than the JSON data model.