What to do with Jackson JSON Schema support?

[Tatu Saloranta]

I am not a big of JSON Schema myself -- I find it too focused on validation of JSON as format, and being under-powered for describing mapping to/from progland Objects -- but others make use of it. And this usage is increasing.

Jackson supports JSON Schema through 2 mechanisms: one, in-built generation from jackson-databind, is being deprecated. The replacement, stand-alone module (https://github.com/FasterXML/jackson-module-jsonSchema) exists, but is not actively maintained.

The immediate challenge with JSON Schema module is that it seems to support v3 of schema spec; the latest one out is v4. Fixing this might not be too difficult to do, given developers who are interested in doing that.

But a more fundamental problem is that I think the implementation's control flow is a big mess. I do not fully understand the logic to various pieces or their function; and naming does not necessarily support intuitive understanding. I have tried simplifying some aspects, but without grokking the intent this won't help too much.

So, I think we have two problems wrt supporting JSON Schema as part of Jackson project:

1. There is imbalance between external interest in having this support (growing), and developers who are supporting implementation

2. I am not sure that the current foundation that JSON Schema Module has is solid thing to build on.

If (1) was solved, I think we could solve (2) either by figuring out "intent behind extent" (why does it work the way it does), or, perhaps, only keeping API there is, but reworking inner logics.

One further twist for (2) is, however, that the callbacks that were added in jackson-databind were based on needs of schema module. So either there'd be more work for jackson-databind, or -- perhaps more likely -- schema module should switch away from visitor model, and into accessing data type/structure information via (Basic)BeanDescription. That would be easier to use anyway (visitors' upside is ability to extend; but they are really intuitive to use).

I don't expect quick solution for any of above, but wanted to voice my concerns.

-+ Tatu +-

[Francis Galiegue]

Hello,

As the author of the JSON Schema specs (except for hyper schema) I
feel obliged to chime in ;)

On Fri, May 23, 2014 at 9:41 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:
> I am not a big of JSON Schema myself -- I find it too focused on validation
> of JSON as format, and being under-powered for describing mapping to/from
> progland Objects -- but others make use of it. And this usage is increasing.
>

The goal of JSON Schema is not, and has never been, to "describe
mapping to/from progland Objects"; it is to describe JSON texts,
whatever those texts are, and said texts may, or may not, be used as
objects. Or in Java, or by Jackson, for that matter.

Projects do exist which do a fine job of:

* generating JSON Schemas from Java classes: JJSchema;
* generating Java classes from JSON Schemas: jsonschema2pojo (draft v3
only though).

And there is of course JSON Schema validation which my project does.
It so happens that all of them use Jackson! (jsonschema2pojo still
uses 1.9.x though)

None of these projects have needed any modification to Jackson
whatsoever to work and be used ;)

My 2 cents,
--
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/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)

[Tatu Saloranta]

On Fri, May 23, 2014 at 3:52 PM, Francis Galiegue <fgal...@gmail.com> wrote:

Hello,

As the author of the JSON Schema specs (except for hyper schema) I
feel obliged to chime in ;)

On Fri, May 23, 2014 at 9:41 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:
> I am not a big of JSON Schema myself -- I find it too focused on validation
> of JSON as format, and being under-powered for describing mapping to/from
> progland Objects -- but others make use of it. And this usage is increasing.
>

The goal of JSON Schema is not, and has never been, to "describe
mapping to/from progland Objects"; it is to describe JSON texts,
whatever those texts are, and said texts may, or may not, be used as
objects. Or in Java, or by Jackson, for that matter.

Right. I understand that its goals are not aligned with mine; and that is all that this was to say. I feel same way about most if not all data format schema
languages; some (XML Schema) try to bridge the gap more than others. And others think that trying to support OO concepts is itself a problem (many XML Schema critics think that is cause of many of its issues).

The only real corollary is that since Jackson is focused on Java side of things, JSON Schema functionality is in an area that is bit outside of core focus of Jackson. It is not outside area of interest, just not core part that absolutely requires support from core components. The fact that JSON Schema module is an external module of course establishes this -- while jackson-databind offers hooks for POJO introspection, it does not know or care how this is used.

 

Projects do exist which do a fine job of:

* generating JSON Schemas from Java classes: JJSchema;
* generating Java classes from JSON Schemas: jsonschema2pojo (draft v3
only though).

And there is of course JSON Schema validation which my project does.
It so happens that all of them use Jackson! (jsonschema2pojo still
uses 1.9.x though)

None of these projects have needed any modification to Jackson
whatsoever to work and be used ;)

Good point, yes. And I would strongly recommend anyone who is interested in JSON Schema functionality to investigate these tools; they do good job on helping interoperability.

So one way to approach this is, also, to emphasize modularity: not everything within JSON space has to be handled by Jackson components. There are great tools that may use Jackson under the hood, but this is more an implementation detail.

-+ Tatu +-

 

My 2 cents,
--
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/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)

--
You received this message because you are subscribed to the Google Groups "jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chuck C]

On Friday, May 23, 2014 3:52:47 PM UTC-7, Francis Galiegue wrote:

Hello,

As the author of the JSON Schema specs (except for hyper schema) I
feel obliged to chime in ;)

As author, you have the ability to fix the wrongs (IMHO) in the JSON Schema purpose as you define below...
 

On Fri, May 23, 2014 at 9:41 PM, Tatu Saloranta <ta...@fasterxml.com> wrote:
> I am not a big of JSON Schema myself -- I find it too focused on validation
> of JSON as format, and being under-powered for describing mapping to/from
> progland Objects -- but others make use of it. And this usage is increasing.
>

The goal of JSON Schema is not, and has never been, to "describe
mapping to/from progland Objects"; it is to describe JSON texts,
whatever those texts are, and said texts may, or may not, be used as
objects. Or in Java, or by Jackson, for that matter.

But, isn't JSON - the JavaScript Object Notation? It is not another document markup language and treating it as such in the schema, IMHO, breaks the original purpose of JSON. The schema should only be used as a way to define Objects that are supported by the JavaScript language and to possible validate inputs into the construction of said Objects.

If people want a lighter-weight document markup language, then choose from one of the many that exist or have a large specifications body come up with another in the few years it takes a specifications body to write a spec.

 

Projects do exist which do a fine job of:

* generating JSON Schemas from Java classes: JJSchema;
* generating Java classes from JSON Schemas: jsonschema2pojo (draft v3
only though).  

This does not do a fine job - it creates too many Java classes and most of them have a single get/set for "type" and equals etc. This project is completely broken IMHO (though potentially a good start.

And there is of course JSON Schema validation which my project does.
It so happens that all of them use Jackson! (jsonschema2pojo still
uses 1.9.x though)

None of these projects have needed any modification to Jackson
whatsoever to work and be used ;)

Any modification to jackson would mean that JSON Schema didn't use valid JSON :)
 

[Francis Galiegue]

On Thu, Sep 4, 2014 at 4:30 AM, Chuck C <ccan...@gmail.com> wrote:
[...]

>>
>> The goal of JSON Schema is not, and has never been, to "describe
>> mapping to/from progland Objects"; it is to describe JSON texts,
>> whatever those texts are, and said texts may, or may not, be used as
>> objects. Or in Java, or by Jackson, for that matter.
>>
>
> But, isn't JSON - the JavaScript Object Notation? It is not another document
> markup language and treating it as such in the schema, IMHO, breaks the
> original purpose of JSON. The schema should only be used as a way to define
> Objects that are supported by the JavaScript language and to possible
> validate inputs into the construction of said Objects.
>

That is a misleading view of things. JSON has evolved far beyond
JavaScript. Linking JSON and JavaScript in 2014 is an outright
mistake.

Note that by "JSON text" I refer to the JSON spec (RFC 7159); a JSON
text can be any JSON value.

Regards,