From f00f9ea5cfde562c34f2bd06754125004f5ad094 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 17 Aug 2022 13:37:52 -0700 Subject: [PATCH 01/11] Add ADR for decoupling from IETF --- adr/2022-08-decouple-from-ietf.md | 82 +++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 adr/2022-08-decouple-from-ietf.md diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md new file mode 100644 index 00000000..334b7eb6 --- /dev/null +++ b/adr/2022-08-decouple-from-ietf.md @@ -0,0 +1,82 @@ +# Decoupling from IETF + +* Status: accepted +* Deciders: @jdesrosiers @relequestual @awwright +* Date: 2022-08-17 + +Related Issues: +* https://github.com/orgs/json-schema-org/discussions/69 - This issue is about + dropping the "draft" prefix from our releases. This ADR doesn't cover that, + but much of the discussion about whether or not to decouple from IETF is in + that discussion. +* This topic has been discussed in many other places as well that are difficult + to link to here including Slack, Twitter, OCWMs, and conference discussions. + +## Context and Problem Statement + +Currently JSON Schema follows the IETF Internet-Draft (I-D) process for spec +development and releases but aren't associated with IETF in any way. Our +perceived involvement with IETF causes confusion and misunderstanding within our +community in the cases were our needs and the realities of our situation deviate +from the IETF process. + +## Decision Drivers + +* IETF's draft versioning system doesn't work for JSON Schema and we stopped + using it to version our releases a while ago. We now use a date based version + and even have more than one draft submission per release (the initial release + and the patch release). +* The IETF process is optimized for working on a draft until it's done and then + disbanding. In some cases, the RFC may be revisited and revised in the future, + but this is rare and generally contains little more than clarifications and + reference updates. JSON Schema is not like that. JSON Schema is more like a + programming language. When it stops evolving, it will loose it's relevance. + When we finish a release of JSON Schema, we don't disband, we start work on + the next release. +* Every one of our releases is expected to be used in production and will be + depended on for many years forward. This is not consistent with normal IETF + drafts. Even if we don't publicly use the term "draft", we're still using the + IETF I-D system in a way that's not intended. +* Under IETF, JSON Schema fits under the category of "draft". The community has + repeatedly told us that they perceive this to meant that JSON Schema + "incomplete" and not "not ready for production use". This is the wrong message + for us to be sending as all of our releases are intended to be used in + production. This ADR doesn't decide whether or not to drop the "draft" from + our releases, but decoupling from IETF gives us that option. +* Several members of the JSON Schema team have had poor interactions with IETF + and don't feel that working with them would be productive. This is a + relatively minor consideration. If we thought IETF was right for JSON Schema, + we could find ways to make those relationships work. + +## Considered Options + +1. Continue to submit I-Ds, while using our customized process with no intention + of pursing standards track RFC status. +2. Get JSON Schema to a stable place and pursue a standards track RFC with the + IETF. +3. Decouple from IETF completely and come up with our own governance model. + +## Decision Outcome + +Our decision is to go with Option 3 and decouple from IETF completely and come +up with our own governance model. The idea of having the come up with our own +governance model is daunting, but when the alternatives are to continue to abuse +the I-D process or to conform to the IETF process that doesn't fit our needs, +going our own way seems the bast option. + +### Positive Consequences + +* Decoupling from IETF allows us to distance ourselves from the assumptions that + people make about JSON Schema because they assume it works like a typical I-D. +* Decoupling from IETF allows us to customize our governance model to what works + best for JSON Schema. + +### Negative Consequences + +* Choosing our own governance model means we aren't associated with a recognized + standard body which could reduce to credibility of JSON Schema in the eyes of + some. +* If we don't go the standardization route with IETF, we lose access to their + expert review process. +* Defining our own process will be a lot of work and none of use have expertise + in defining such a process. From 6062b8f893fdc973a728f5a79ee347a9e29c7a86 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:57:12 -0700 Subject: [PATCH 02/11] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 334b7eb6..f6c616bf 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -30,7 +30,7 @@ from the IETF process. disbanding. In some cases, the RFC may be revisited and revised in the future, but this is rare and generally contains little more than clarifications and reference updates. JSON Schema is not like that. JSON Schema is more like a - programming language. When it stops evolving, it will loose it's relevance. + programming language. When it stops evolving, it will lose its relevance. When we finish a release of JSON Schema, we don't disband, we start work on the next release. * Every one of our releases is expected to be used in production and will be From d5befa56527342e6a7081f453b9167d248c82cc8 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:57:59 -0700 Subject: [PATCH 03/11] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index f6c616bf..dfef110a 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -59,7 +59,7 @@ from the IETF process. ## Decision Outcome Our decision is to go with Option 3 and decouple from IETF completely and come -up with our own governance model. The idea of having the come up with our own +up with our own governance model. The idea of having to come up with our own governance model is daunting, but when the alternatives are to continue to abuse the I-D process or to conform to the IETF process that doesn't fit our needs, going our own way seems the bast option. From 006483116f91c1ee6e4d4853a301fda086eef404 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 10:58:30 -0700 Subject: [PATCH 04/11] Update adr/2022-08-decouple-from-ietf.md Co-authored-by: Ethan <133719+notEthan@users.noreply.github.com> --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index dfef110a..52934d5f 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -62,7 +62,7 @@ Our decision is to go with Option 3 and decouple from IETF completely and come up with our own governance model. The idea of having to come up with our own governance model is daunting, but when the alternatives are to continue to abuse the I-D process or to conform to the IETF process that doesn't fit our needs, -going our own way seems the bast option. +going our own way seems the best option. ### Positive Consequences From 789ae608f9057c3376e375de32956a7922661c4f Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 18 Aug 2022 13:52:59 -0700 Subject: [PATCH 05/11] ADR decouple from IETF draft 2 --- adr/2022-08-decouple-from-ietf.md | 49 +++++++++++++++++-------------- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 52934d5f..3ab9eebe 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -14,16 +14,16 @@ Related Issues: ## Context and Problem Statement -Currently JSON Schema follows the IETF Internet-Draft (I-D) process for spec -development and releases but aren't associated with IETF in any way. Our +Currently JSON Schema loosely follows the IETF Internet-Draft (I-D) process for +spec development and releases but isn't associated with IETF in any way. Our perceived involvement with IETF causes confusion and misunderstanding within our -community in the cases were our needs and the realities of our situation deviate -from the IETF process. +community in the cases were our practices and the realities of our situation +deviate from the typical IETF I-D process. ## Decision Drivers * IETF's draft versioning system doesn't work for JSON Schema and we stopped - using it to version our releases a while ago. We now use a date based version + using it to version our releases a while ago. We now use date based versioning and even have more than one draft submission per release (the initial release and the patch release). * The IETF process is optimized for working on a draft until it's done and then @@ -52,31 +52,36 @@ from the IETF process. 1. Continue to submit I-Ds, while using our customized process with no intention of pursing standards track RFC status. -2. Get JSON Schema to a stable place and pursue a standards track RFC with the - IETF. -3. Decouple from IETF completely and come up with our own governance model. +2. Go all-in with IETF and pursue a standards track RFC with the IETF. +3. Join W3C and pursue a standards track with them using their process. +4. Decouple completely from any standards organization and come up with our own + specification development lifecycle (SDLC) model inspired by well established + projects with an SDLC that more closely meets or needs. ## Decision Outcome -Our decision is to go with Option 3 and decouple from IETF completely and come -up with our own governance model. The idea of having to come up with our own -governance model is daunting, but when the alternatives are to continue to abuse -the I-D process or to conform to the IETF process that doesn't fit our needs, -going our own way seems the best option. +Our decision is to go with Option 4 and decouple from standards organizations +that don't fit our needs. We don't currently have a plan for what to replace +IETF with. We are currently investigating how other established projects do +their SDLC and will likely choose one to emulate and adapt to our needs. +Although we don't have a replacement solution in place yet, we are confident +that continuing to abuse the IETF I-D process or conforming to a standards +organization process that doesn't fit our needs is not the way to go. ### Positive Consequences * Decoupling from IETF allows us to distance ourselves from the assumptions that people make about JSON Schema because they assume it works like a typical I-D. -* Decoupling from IETF allows us to customize our governance model to what works - best for JSON Schema. +* Decoupling from IETF allows us to customize our SDLC model to what works best + for JSON Schema. ### Negative Consequences -* Choosing our own governance model means we aren't associated with a recognized - standard body which could reduce to credibility of JSON Schema in the eyes of - some. -* If we don't go the standardization route with IETF, we lose access to their - expert review process. -* Defining our own process will be a lot of work and none of use have expertise - in defining such a process. +* Not being associated with a recognized standards organization such as IETF, + W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. +* If we don't go the standardization route with IETF or W3C, we lose access to + their expert review process. +* Defining our own SLDC process will be a lot of work and none of us have + expertise in defining such a process. However, we can take inspiration from + existing well established projects and we would have the freedom to update our + process as we learn what works and what doesn't. From dd3c6407db4cdf3e4ac56ff66e8c5f5ff54db089 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 23 Aug 2022 14:11:36 -0700 Subject: [PATCH 06/11] ADR decouping from IETF draft 3 Incorporating feedback from Henry and Austin. --- adr/2022-08-decouple-from-ietf.md | 65 +++++++++++++++++++++++++++---- 1 file changed, 57 insertions(+), 8 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 3ab9eebe..48499d39 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -15,10 +15,14 @@ Related Issues: ## Context and Problem Statement Currently JSON Schema loosely follows the IETF Internet-Draft (I-D) process for -spec development and releases but isn't associated with IETF in any way. Our -perceived involvement with IETF causes confusion and misunderstanding within our -community in the cases were our practices and the realities of our situation -deviate from the typical IETF I-D process. +spec development and releases but isn't associated with any IETF working group. +JSON Schema is an individual draft. That means it isn't on a standards track +with IETF and IETF is not involved nor supports the spec in any way other than +hosting the canonical version of our I-Ds. Our perceived involvement with IETF +causes confusion and misunderstanding within our community in the cases were our +practices and the realities of our situation deviate from a typical IETF I-D +lifecycle. The thing that makes our situation different than a typical I-D is +that our "drafts" are intended for use in production. ## Decision Drivers @@ -46,13 +50,19 @@ deviate from the typical IETF I-D process. * Several members of the JSON Schema team have had poor interactions with IETF and don't feel that working with them would be productive. This is a relatively minor consideration. If we thought IETF was right for JSON Schema, - we could find ways to make those relationships work. + we could find ways to make those relationships work. We have a good + relationship with the relatively new HTTPAPIs working group and working with + them would be far more likely to be productive than the people/WG we were + previously in communication with. ## Considered Options 1. Continue to submit I-Ds, while using our customized process with no intention - of pursing standards track RFC status. -2. Go all-in with IETF and pursue a standards track RFC with the IETF. + of pursing standards track RFC status. +2. Go all-in with IETF and pursue a standards track RFC with the IETF. The + approach would be to describe the essential characteristics of evaluating a + JSON Schema: the keywords that everybody is guaranteed to support, and any + extension mechanisms. 3. Join W3C and pursue a standards track with them using their process. 4. Decouple completely from any standards organization and come up with our own specification development lifecycle (SDLC) model inspired by well established @@ -62,12 +72,45 @@ deviate from the typical IETF I-D process. Our decision is to go with Option 4 and decouple from standards organizations that don't fit our needs. We don't currently have a plan for what to replace -IETF with. We are currently investigating how other established projects do +IETF with, but we are currently investigating how other established projects do their SDLC and will likely choose one to emulate and adapt to our needs. Although we don't have a replacement solution in place yet, we are confident that continuing to abuse the IETF I-D process or conforming to a standards organization process that doesn't fit our needs is not the way to go. +Option 2 and 3 are still on the table if we feel it makes sense when we get to a +more stable place in the future. The main concern is the pain this process is +causing while we are in this unusual phase of simultaneous unstable growth and +production use. Standardization isn't out of the question, it's just not +productive for us to be developing JSON Schema within the constraints of a +standards organizations procedures. + +Option 1 was rejected because it ignores the problems we've been facing and +provides no solution. No one wants this. + +Option 2 was rejected for several reasons. If we go all in with IETF, we would +have to join a working group and treat JSON Schema like a normal I-D. That means +we would have to start treating drafts as drafts, which means not recommending +production use until we are ready for RFC and not releasing a new +production-ready version of JSON Schema until we've reached RFC status. Most of +the core contributors don't believe that we are close enough to an RFC-ready +release that we want to commit to not being able to issue another release until +that happens. + +There are other concerns including skepticism that even with an extension +mechanism that the RFC wouldn't need regular updates, which is not normal +practice for an RFC and would require significant effort to issue a replacing +RFC. Without a concrete proposal on the scope of the RFC and the extension +mechanisms, it's hard to commit to this path. + +Additionally, many of the core contributors have found working with the IETF +unproductive and have concerns about JSON Schema getting deeper involved without +compelling enough reason. Most agree that the reasons are not sufficiently +compelling at this point. + +Option 3 was rejected because it has the same problems as Option 2 accept that +we don't have the same unpleasant history with W3C than we do with IETF. + ### Positive Consequences * Decoupling from IETF allows us to distance ourselves from the assumptions that @@ -79,8 +122,14 @@ organization process that doesn't fit our needs is not the way to go. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. + However, people seem comfortable adopting OpenAPI without it being associated + with a standards organization, so we don't expect this to be a significant + issue for JSON Schema either. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. +* One of the benefits of an RFC is other standards can normatively reference it, + and use JSON Schema to define their JSON-based syntaxes. Independently + publishing a specification does not permit this. * Defining our own SLDC process will be a lot of work and none of us have expertise in defining such a process. However, we can take inspiration from existing well established projects and we would have the freedom to update our From f96af8a134d92bc046a5a11bac46a91cedbe4e22 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Tue, 6 Sep 2022 09:48:41 -0700 Subject: [PATCH 07/11] ADR decouping from IETF draft 4 Include feedback about referencing JSON Schema in other standards without the backing of a recognized standards body. --- adr/2022-08-decouple-from-ietf.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 48499d39..cdbe2503 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -122,9 +122,10 @@ we don't have the same unpleasant history with W3C than we do with IETF. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. - However, people seem comfortable adopting OpenAPI without it being associated - with a standards organization, so we don't expect this to be a significant - issue for JSON Schema either. + However, we have received feedback from people involved in standards + development that say they are comfortable adopting OpenAPI without it being + associated with a standards organization, so we don't expect this to be a + significant issue for JSON Schema either. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. * One of the benefits of an RFC is other standards can normatively reference it, From 610a388cf62aaa8cbe2d4a28daab9e8117ab92ea Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Wed, 7 Sep 2022 11:46:38 -0700 Subject: [PATCH 08/11] ADR decoupling from IETF draft 5 Mention OpenJS / Linux Foundation and add Henry as a decider --- adr/2022-08-decouple-from-ietf.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index cdbe2503..c9f6dcca 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -1,7 +1,7 @@ # Decoupling from IETF * Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright +* Deciders: @jdesrosiers @relequestual @awwright @handrews * Date: 2022-08-17 Related Issues: @@ -123,9 +123,12 @@ we don't have the same unpleasant history with W3C than we do with IETF. * Not being associated with a recognized standards organization such as IETF, W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. However, we have received feedback from people involved in standards - development that say they are comfortable adopting OpenAPI without it being - associated with a standards organization, so we don't expect this to be a - significant issue for JSON Schema either. + development that told us that they were comfortable referencing OpenAPI's self + published specification in their standards and that OpenAPI's membership with + the Linux Foundation was an important aspect of what makes them comfortable + doing so. JSON Schema is a member of the OpenJS Foundation, which is a + sub-group of the Linux Foundation, so we expect standards developers to be + just as comfortable referencing JSON Schema as they are referencing OpenAPI. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. * One of the benefits of an RFC is other standards can normatively reference it, From 9bbde03dcf628d6825bd5c9d740067ef256445e9 Mon Sep 17 00:00:00 2001 From: Jason Desrosiers Date: Thu, 8 Sep 2022 10:02:43 -0700 Subject: [PATCH 09/11] ADR decoupling from IETF draft 6 Feedback from Henry. The main changes are updating the section on our prior experience with IETF and clarifying that our descision not to use IETF doesn't apply to media type registration or supporting components such as Relative JSON Pointer. --- adr/2022-08-decouple-from-ietf.md | 65 ++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 23 deletions(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index c9f6dcca..4b2430a9 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -37,23 +37,30 @@ that our "drafts" are intended for use in production. programming language. When it stops evolving, it will lose its relevance. When we finish a release of JSON Schema, we don't disband, we start work on the next release. -* Every one of our releases is expected to be used in production and will be - depended on for many years forward. This is not consistent with normal IETF - drafts. Even if we don't publicly use the term "draft", we're still using the - IETF I-D system in a way that's not intended. +* Since the project resumed activity after the gap following draft-04, every one + of our releases is expected to be used in production and will be depended on + for many years forward. This is not consistent with normal IETF drafts. Even + if we don't publicly use the term "draft", we're still using the IETF I-D + system in a way that's not intended. * Under IETF, JSON Schema fits under the category of "draft". The community has repeatedly told us that they perceive this to meant that JSON Schema "incomplete" and not "not ready for production use". This is the wrong message for us to be sending as all of our releases are intended to be used in production. This ADR doesn't decide whether or not to drop the "draft" from our releases, but decoupling from IETF gives us that option. -* Several members of the JSON Schema team have had poor interactions with IETF - and don't feel that working with them would be productive. This is a - relatively minor consideration. If we thought IETF was right for JSON Schema, - we could find ways to make those relationships work. We have a good - relationship with the relatively new HTTPAPIs working group and working with - them would be far more likely to be productive than the people/WG we were - previously in communication with. +* Several members of the JSON Schema team have interacted with JSON-related IETF + working groups. Some of these interactions demonstrated an indifference or + hostility to JSON Schema, and a preference for projects taking a different + approach. Equally important was a lack of any active interest or constructive + engagement. Finally, we were informed that any schema project for JSON would + not necessarily start from JSON Schema as a base, indicating that a "JSON + Schema" working group would quite likely not involve JSON Schema itself. This + impression has been reinforced by observing the amount of change introduced to + JSON Path as a consequence of its adoption by an IETF working group. While we + have a good relationship with the relatively new HTTPAPIs working group, the + combination of these other experiences with other mismatches between our + project and the IETF process contributes to our reluctance to move forward + through the iETF. ## Considered Options @@ -78,6 +85,17 @@ Although we don't have a replacement solution in place yet, we are confident that continuing to abuse the IETF I-D process or conforming to a standards organization process that doesn't fit our needs is not the way to go. +However, we still plan to use the IETF process to register the media types +defined by JSON Schema with IANA. This effort is currently in progress with the +HTTPAPIs working group. + +The decision to not use IETF applies only to the main specification documents +and not necessarily supporting components we have defined or will define in the +future. Currently our only such component is Relative JSON Pointer, but there +could be others in the future. These components will be examined on a case by +case basis and we may choose an IETF standards path for those components if it +makes sense. + Option 2 and 3 are still on the table if we feel it makes sense when we get to a more stable place in the future. The main concern is the pain this process is causing while we are in this unusual phase of simultaneous unstable growth and @@ -108,7 +126,7 @@ unproductive and have concerns about JSON Schema getting deeper involved without compelling enough reason. Most agree that the reasons are not sufficiently compelling at this point. -Option 3 was rejected because it has the same problems as Option 2 accept that +Option 3 was rejected because it has the same problems as Option 2 except that we don't have the same unpleasant history with W3C than we do with IETF. ### Positive Consequences @@ -120,20 +138,21 @@ we don't have the same unpleasant history with W3C than we do with IETF. ### Negative Consequences -* Not being associated with a recognized standards organization such as IETF, - W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. - However, we have received feedback from people involved in standards - development that told us that they were comfortable referencing OpenAPI's self - published specification in their standards and that OpenAPI's membership with - the Linux Foundation was an important aspect of what makes them comfortable - doing so. JSON Schema is a member of the OpenJS Foundation, which is a - sub-group of the Linux Foundation, so we expect standards developers to be - just as comfortable referencing JSON Schema as they are referencing OpenAPI. * If we don't go the standardization route with IETF or W3C, we lose access to their expert review process. +* Not being associated with a recognized standards organization such as IETF, + W3C, or IEEE reduces the credibility of JSON Schema in the eyes of some. + However, we have received feedback that our membership with OpenJS/Linux + Foundation provides the credibility that we need. * One of the benefits of an RFC is other standards can normatively reference it, - and use JSON Schema to define their JSON-based syntaxes. Independently - publishing a specification does not permit this. + and use JSON Schema to define their JSON-based syntaxes. However, we have + received feedback from people involved in standards development that told us + that they were comfortable referencing OpenAPI's self published specification + in their standards and that OpenAPI's membership with the Linux Foundation was + an important aspect of what makes them comfortable doing so. JSON Schema is a + member of the OpenJS Foundation, which is a sub-group of the Linux Foundation, + so we expect standards developers to be just as comfortable referencing JSON + Schema as they are referencing OpenAPI. * Defining our own SLDC process will be a lot of work and none of us have expertise in defining such a process. However, we can take inspiration from existing well established projects and we would have the freedom to update our From 2eaf95a02cc11f35039d829c47e4b25d30470f7d Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Mon, 26 Sep 2022 16:24:05 +0100 Subject: [PATCH 10/11] Add comments about W3C being a pay to play standards org --- adr/2022-08-decouple-from-ietf.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 4b2430a9..7096d276 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -128,6 +128,15 @@ compelling at this point. Option 3 was rejected because it has the same problems as Option 2 except that we don't have the same unpleasant history with W3C than we do with IETF. +Additionally, the W3C is a "pay to play" standards organization. Organizations +must pay to contribute to specifications the W3C publish, which doesn't match +the JSON Schema Org's open ethos. + +Ben Hutton has had multiple calls with various individuals at different levels +within the W3C, and has a friendly contact should we wish to investigate again +at a later point. The W3C does have an "invited expert" solution for when +a persons employer doesn't want to be a paying member, however this is supposed +to be an exception to the rule, and not frequently used. ### Positive Consequences From 9da7e23b25ae6bac729b10f27fb3273a9a5ad5bb Mon Sep 17 00:00:00 2001 From: Ben Hutton Date: Tue, 27 Sep 2022 10:22:24 +0100 Subject: [PATCH 11/11] Add Greg to IETF decouple ADR --- adr/2022-08-decouple-from-ietf.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/2022-08-decouple-from-ietf.md b/adr/2022-08-decouple-from-ietf.md index 7096d276..821591c0 100644 --- a/adr/2022-08-decouple-from-ietf.md +++ b/adr/2022-08-decouple-from-ietf.md @@ -1,7 +1,7 @@ # Decoupling from IETF * Status: accepted -* Deciders: @jdesrosiers @relequestual @awwright @handrews +* Deciders: @jdesrosiers @relequestual @awwright @handrews @gregsdennis * Date: 2022-08-17 Related Issues: