Looking for a new maintainer for json-schema-validator

[Francis Galiegue]

Hello,

Unfortunately, I believe I do not have the time anymore, nor the
incentive (and that's worse) to give this project the attention it now
requires.

I am looking for a volunteer to take the project over; project page:

https://github.com/fge/json-schema-validator

As a proof of the lack of incentive, I do know that many, many people
use it in their applications; what I haven't done is collect the
entities which did and compile a list, for instance.

I do know of a few of them and have already sent mails to parties who
I believe have a potential interest -- not only in the project itself,
of course, but also in JSON Schema proper.

And this is another probe.

Please contact me personally if you are interested.

Thank you for your attention,
--
Francis Galiegue, fgal...@gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

[sha p]

Hi Francis,

  Its really painful to hear such words, I can understand how much hard work and time you invested in making this API to bring this stage and make successful.

I am very new to JSON and API stuff , otherwise I would have done my best in this regard. :( ....

Let me know if I can be of any useful to you in anyway.

Thank you for all your efforts, hope your legacy would be taken forward farther....

Regards,

~Sha

[xmlbuddy]

Any news in this regard? I hope JSON schema doesn't become an orphaned specification now... :(

Regards

Clemens

[Francis Galiegue]

On Tue, Mar 17, 2015 at 2:30 PM, xmlbuddy <off...@xml-buddy.com> wrote:
> Any news in this regard? I hope JSON schema doesn't become an orphaned
> specification now... :(
>

And why would it be?

OK, I'll make things clear: I am no longer the man to maintain the
specs in 2015.

The landscape has changed. Usage of JSON Schema has clearly grown. My
initial goals for JSON Schema are, for some of them, no longer valid.
I keep pestering about backwards compatibility in some aspects where
breaking it would actually be beneficial. I don't know. I don't know
anymore.

I do believe I have done a pretty fine job for draft v4, but I no
longer have the energy or, as I've said, the incentive, to keep going.
In particular, the addressing problem is a plague which MUST be
resolved, and I do wish that someone stood up and pushed JSON
Reference to the IETF, for instance; and I do also wish that JSON
Schema used what is there and defined, that is, JSON Patch, JSON
Pointer and JSON Merge Patch.

But JSON Schema is by no means an orphan if I "let go"; not at all.
What is needed is a more formal entity to drive it; I wasn't able to
create such an entity previously, and I am still not able to do it. I
just take the opportunity that my library is sufficiently well known
and used to push things forward.

JSON Schema is not mine. It has never been mine. I _am_ proud of what
I have done, for sure; but to take it to the next level, I am not the
person you're looking for. Should I stick to it for sentimental
reasons, sclerosis would await. I don't want that. You don't.

Regards,

[joan...@gmail.com]

Hi,

It is really a pity to hear this. First let me just say that you did a good job on the specification that is needed and has proved useful as it is today.

I'm supporting the activities of the Open Geospatial Consortium (a geospatial standardization body) and wonder if we could help. We are now in the process of considering JSON as an alternative to XML encodings. To have a validation mechanism is very important for us since it is an important part of what you need for creating conformance testing for the standards you produce. OGC is collaborating with W3C and we had collaborated with IETF also.

If this is seen as a possibility we could present it in the next OGC meeting in June and look for the right formula for collaboration. The key factor here is have people that are ready to get involved and do the work.

Joan

[xmlbuddy]

Hi Joan,

nice to hear from you also on this group.

I would love to continue to provide Windows desktop tools that also support the JSON schema specification as I'm doing right now (a graphical JSON schema editor is definitely on my list). However, someone has to "work" on the specification and I guess there are also a lot of administrative tasks to do. For sure I'm not the guy to work on the standard itself but I'm open if I can support the schema standardization in any additional way from my "tools oriented" approach.

Kind regards

Clemens

[Schmidty]

Hey.

I've just finished an initial release of a new validation library in Node.js (likeness) which includes a novel "transform" concept. I have every intention to explore this concept further, to finally realize the LIMS to End All LIMS that I never got to make for my last cash-strapped university lab position. I'm interested in the JSON Patch concept, but could you explain to me what you mean by "the reference problem?"  Likeness precompiles schemata until only recursive references to direct parents remain and I wasn't able to detect any reference problem.