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

consider joining the WG #526

Closed
dret opened this issue Dec 31, 2017 · 18 comments
Closed

consider joining the WG #526

dret opened this issue Dec 31, 2017 · 18 comments

Comments

@dret
Copy link
Contributor

dret commented Dec 31, 2017

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
Copy link

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

@handrews
Copy link
Contributor

handrews commented Jan 1, 2018

@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
Copy link
Contributor

handrews commented Jan 1, 2018

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
Copy link
Member

dlax commented Jan 1, 2018

@akuckartz

Which WG?

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

@dlax
Copy link
Member

dlax commented Jan 1, 2018

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
Copy link
Contributor

handrews commented Jan 1, 2018

@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
Copy link
Contributor

handrews commented Jan 24, 2018

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
Copy link
Contributor Author

dret commented Jan 25, 2018 via email

@davidgtonge
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

@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
Copy link

@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

@Relequestual
Copy link
Member

@davidgtonge Thanks for reaching out.
I appreciate that not being an adopted standard prohibits some others from referencing it. Even if it were an adopted standard, it wouldn't be finalised (aka referenceable under IEFT rules), and probably won't be for at least another 1-2 (+) years. We have work to do, and I'm trying to be realistic about the pace.

Are there any comparable technical standards that are part of ISO? I'd be open to hearing what's involved, but I'm skeptical about it being the right place.

@handrews
Copy link
Contributor

handrews commented May 28, 2018

@davidgtonge another option if ISO is not really the right home for JSON Schema is for your group to lobby the appropriate people at IETF to adopt us into a working group. We regularly get requests such as yours to make the spec referenceable, but we don't actually have much ability to make that happen (aside from maybe publishing it as an informational RFC, but JSON Schema really should be standards-track somewhere).

@epicfaace
Copy link

@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.

While it was good to reach out to the JSONbis group, I'm not sure if we can take the responses of four people to representative of the entire IETF community. Besides, it seems like the consensus was that it will be a long process. But if it is a long process, and even if it ends up making significant changes, the benefits of standardization through a standards body might be worth it.

According to the process at https://www.ietf.org/standards/process/new-work/, forming a WG for JSON Schema involves talking to the area director (which would be art in our case) and requesting the formation of a mailing list. It seems that then people on the mailing list start the process of creating a charter and then forming the WG (according to this document).

I think it's worth reaching out to see what the area directors think. If you don't mind, I'll give it a shot.

@handrews
Copy link
Contributor

@Relequestual could you coordinate with @epicfaace on whether to do this now?

@epicfaace I'm trying to wrap up the current draft and then step back a bit. I'm not abandoning the project by any means but I have to rebalance some stuff.

@Relequestual
Copy link
Member

As a note, for now, w3c/strategy#108 is the issue to track on this discussion =]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants