Hi Przemyslaw,
thanks a lot for your interest in the JSR and sorry for the late
response. As the JSON-B JSR is now in JSR Review Ballot stage (ending
today, actually), you may want to express your interest in joining the
EG by clicking the Join this Expert Group
(
https://jcp.org/en/jsr/egnom?id=367) button within the JSR's JCP page
(
https://jcp.org/en/jsr/detail?id=367).
Please see also my further response below. Regards,
MartiNG
On 17.07.14 9:06, Przemyslaw Bielicki wrote:
> *Generic object-to-any-message-format-mapping.*
> As we've seen with JAXB, most of it's annotations make sense for JSON
> and for any other message format, except that these annotations start
> with @Xml which suggests that it is devoted to XML format. If this JSR
> is to provide only JSON-specific annotations it might be an overkill
> for developers wanting to use both of the formats (XML and JSON) or
> even more if needed. If the output of this JSR will be API with
> annotations starting with @Json I can see some philosophical issues :)
>
> What I suggest is to provide a generic (as much as possible) API that
> will be useful for any message format used to serialize Java objects
> (and the other way). Then we can come up with some format-specific
> stuff (I don't know if there something specific for JSON) like
> namespaces (for XML) or inheritance (for possible future message
> formats). Of course, we would allow API extensions for message formats
> that don't exist at the moment but will be in 20 years.
> Then we could basically alias JAXB annotations (to make existing
> annotated code compatible with the new annotations)
I'd expect large portion of users to use default mapping format, which
would not require extensive use of annotations, and also hope the api
would be designed wisely to not require extensive Json annotation usage
if one needs to bind different mappings. I'm also having some trouble to
understand the exact proposals here - I can see the reuse for some
number of annotations (transient is usually mentioned in this context
most often), but not for a lot of them - and with future, non-existing
format, I can see the api to only provide even worse match. On the other
hand, if one wants to expose the same set of classes in somewhat
different way via Json and Xml formats (which is usual), it is IMO
cumbersome to do so using generic annotations.Not mentioning that
maintaining and syncing more specs is more complex and more work, of
course. I'm open to discussions on this topic, but I think it needs
detailed proposal or two to be able to drill into the details.
> *JSON Schema & Schema Validation*
> For most people this is not an issue but for enterprise applications
> schema and schema validation is needed. At the moment JSON messages
> don't have any schema so API can change without any notice and affect
> customers not knowing what has changed.
> In my opinion JSON schema and schema validation could be worth
> considering.
>
> The question is which format use to describe the schema? JSON? XSD?
I think it may be hard to reach consensus on XSD here. Following up
other JSON schema initiatives, such as
http://json-schema.org/latest/json-schema-validation.html, I'm not
seeing those to be in final stages of the specification yet, so building
on them is problematic. As for json-schema, the draft has expired more
than a year ago, so the spec status is unclear. In my view, in future
once the status is clear, JSON-P alike JAX-P in XML world could provide
the capabilities to work with / validate against JSON schema, and JSON-B
specification could build on top of them.