consider joining the WG

[dret]

https://mailarchive.ietf.org/arch/msg/json/Ec78QgZqpvcqPd97fvGV3Nt2tVA makes the point that a JSON schema spec probably would be a worthwhile contribution to the JSON community as a whole. i am not in a position to make the call whether the spec developed here should make this step, but i pretty confident that this would help the spec development in terms of community support, and getting more momentum behind it.

[akuckartz]

@dret Which WG? Currently there does not seem to exist a JSON WG within the IETF: https://datatracker.ietf.org/wg/

[handrews]

@dret draft-08 is still dealing with some fairly fundamental issues that need to get resolved, as they are the same ones that essentially killed the project for three years or so after draft-04.

Once that is done, the main remaining question for core and validation is $data. My intention was to work through that in draft-09 while getting feedback on draft-08, and then try to move to a working group.

I do want to get to a working group status, but previously when it's come up the consensus was that we weren't ready yet.

I will also admit that I am dreading working over listserv, which is a huge reason that I'm reluctant to pursue it. As I understand it, that's an absolute requirement for going through a working group (corrections welcome if I'm wrong).

It's about to be 2018. We have much better collaboration tools, and we can use them as we wish while we are doing I-Ds. The volume and pace of discussions on this project are a challenge to keep up with when they're organized in github issues. I cannot image dealing with this over email.

I have considered trying to get the core and validation specs to a decent point and then hoping that I can hand them off to someone who will be more comfortable with the IETF's technology choices and working style (unless they've modernized since the last time I checked, I suppose). I could then stick with Hyper-Schema which will be in I-D territory for a while yet as it doesn't even have proper implementations at this point.

[handrews]

I cannot image dealing with this over email.

Or rather, I can, from other projects back when email was the best option, and I'd prefer to never repeat the experience.

[dlax]

@akuckartz

Which WG?

The jsonbis one https://datatracker.ietf.org/wg/jsonbis/about/, I guess.

[dlax]

I will also admit that I am dreading working over listserv, which is a huge reason that I'm reluctant to pursue it. As I understand it, that's an absolute requirement for going through a working group (corrections welcome if I'm wrong).

I had the impression that the "requirement" was not that strong. For instance, core-wg or http-wg advise for a combined usage of github and their mailing list. This does not seem so different from what we have here with the google group and github. So just replacing the google group with an IETF mailing list (the one of the JSON WG?) would just broaden our community without necessarily changing our current workflow.

[handrews]

@dlax regarding mailing list vs GitHub, that's good to know. Of course I would be fine with using an IETF mailing list instead of Google groups. And for that matter, I would never hold up the process over my own concerns over communication technology. I'm grumpy, not evil :-P

Regarding which working group, the JSONbis WG has concluded. We would fit somewhere under the Applications and Real-Time (art) are for working groups, but there is no obvious home among existing groups. So I suppose we'll need to get one chartered?

I have no idea what the requirements are and right now I'll just be happy if we can get through draft-08 without #515 fracturing the community entirely.

[handrews]

Contacted the working group in this thread.

It seems clear that we would not gain anything by moving to a working group in the near future and would likely lose quite a bit. There was significant skepticism over even using our drafts as a starting point, often based on extremely outdated information but without notable interest in catching up on recent developments.

The I-D to working group transition seems designed for proposals that are one person's private project, while we are widely implemented with an active community. We can better serve that community by continuing to address the known limitations frustrating that community. When we are satisfied with our own proposal we can re-evaluate the working group idea.

In the meantime, if a working group for this area is created and someone wants to try to advocate for JSON Schema they are welcome to, but the current project admins/editors will not be taking this up anytime soon.

[dret]

On 2018-01-24 22:47, Henry Andrews wrote: Contacted the working group in this thread <https://mailarchive.ietf.org/arch/search/?email_list=json&gbt=1&index=w--4QtcF9remEI3FfGM6ghBFkEQ>.

thanks for your initiative!

[davidgtonge]

I'd like to re-open this thread.

Thank you @handrews and others for your work on this spec, it is gaining in adoption. There is a problem at the moment however because there are lots of links to outdated versions of the spec. Because these are all linked to personal IETF drafts and the versioning has changed it is difficult to know what is the latest draft.

In addition, the specs use IETF language, IETF headings and make many references to the IETF. If there is no plan to transition to an IETF WG then these should be dropped as it is misleading.

This spec is core to many API specs, including high value financial APIs such as UK Open Banking . It is also key to the OpenAPI specs, which also gaining wide adoption.

I believe it needs a home either within an IETF WG or another standards body such as W3C or even the OpenAPIs Initiative. It would be better to move to such a body as soon as possible. These bodies don't just publish existing specs, they have processes for developing and iterating specs. While such processes are far from perfect, they have many benefits.

At the moment I'm working with ISO on standards for financial APIs are I can't recommend linking to a personal IETF draft. While this is not the case with JSON Schema, the fact is that anyone can publish a personal IETF draft, just because it is on the IETF website has no bearing on its quality.

What are the future plans for taking this spec to a standards body?

Thanks

Dave

[Relequestual]

Hi @davidgtonge Thanks for getting in touch.

We're currently evaluating our options, but we're not in any rush to push for adoption by IETF or W3C right now; we're focusing most of our efforts on the specification.

We've opened lines of communication with the W3C, who are receptive, but we may have issues in joining.

We've also talked very briefly about having our own industry standards body, much like OAPI does.

The personal drafts are how it's going to be for the foreseeable future. Sorry.
While it's true that anyone can make a personal draft, the official JSON Schema drafts are linked from the website, which we also maintain control of through this github org. http://json-schema.org/specification.html

Sorry if that offers little solace to your current issues.

We're very aware that JSON Schema is being used in the wild by all sorts of people for all sorts of things, even offline. Drafts are, officially, not supposed to be used in production, but it's been used by many major tech companies for years already.

Feel free to come and join our slack to help keep an eye on things, if you like.

[davidgtonge]

Thanks @Relequestual for the prompt response.

From the homepage:

The JSON Schema project intends to shepherd the Core, Validation, and Hyper-Schema specifications to RFC status. Currently, we are continuing to improve our self-published Internet-Drafts. The next step will be to get the drafts adopted by an IETF Working Group.

It sounds like this is not the plan and should perhaps be updated.

While I understand the temptation to just focus on getting the spec as good as it can be, the reality is that most standards group wont take the finished spec and just publish it.

I'll definitely follow along, and thanks again for the reply and work on the specs.

[handrews]

@davidgtonge It's not so much that any of us disagree with you, it's a question of having someone willing and able to do the work of coordinating with a standards body that (as you can see in the linked thread) is less than enthusiastic. For a variety of reasons, I'm not the person to do that, at least not right now. Most of those reasons have nothing to do with JSON Schema or even the IETF or the specific people or responses on that thread.

For now the plan of record is still the IETF, with another option being to publish an informational rather than standards-track RFC based on what people are actually using. RFC 2083 PNG (Portable Network Graphics) Specification is an example of this.

The W3C is another option, which @Relequestual has been exploring (thanks for that!)

None of us expect a standards body to just take what we have, but some people we have talked to are interested in at least respecting the fact that the spec is in broad use as-is and has been for years, and others seem inclined to disregard that and start from scratch. I do not speak for anyone else when I say this, but from my point of view, any standards group that wants to start from scratch is welcome to use anything from this effort that they find worthwhile, and does not need my input to do so.

The other members of the project here may have different views- I'm just pointing this out to emphasize that even though I've been the most prolific contributor of PRs recently, I'm not standing in the way of someone taking this over the standardization finish line. On the contrary, I'd applaud such a thing vigorously even if some of my work gets dumped or changed along the way. JSON Schema doesn't belong to any one contributor.

In particular, if anyone involved in the IETF working group process wants to be a champion for getting to a standards-track RFC, I'd be thrilled to support them in whatever way I can.

[davidgtonge]

@handrews @Relequestual I'm reaching out on behalf of a working group at ISO. There is a desire to reference this spec in an international standard and as mentioned before it would be great if there was a migration plan towards a standard body.

Interestingly ISO themselves have a process whereby existing widely used standards can be fast tracked to publication. While ISO may not be the typical home of a spec such as this, I think it is an option worth considering?

Would you like me to pursue this further or find out more details?

Thanks again for all the work with the spec.

Dave