2015-04-19 19:44 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com>:
> Hi Martin
>
> for me it makes sense to support it by default with a flag like the
> one you proposed to switch it off (a bit off topic but do we have
> constants for these flags, something like Jsonb.I_JSON_COMPLIANCE?).
>
> UTF8 by default is quite mandatory IMO, must-ignore as well (already
> discussed IIRC). ISO8601 is the standard for dates of most of
> frameworks, big numbers need to be string whatever we do so finally
> open points from my window are:
>
> - byte data as base64: on johnzon we discussed it and I didn't want it
> cause it was far from Java - that said it is not a super common type
> so not sure it is that important
> - top level construct: don't recall the spec but I think primitives
> (string, numbers) can be supported as well. Jackson does it at least
> so +1 to not support this fail fast behavior
>
I don't think there is much value in being too restrictive, +1 for it.
I don't remember any discussion about accepting to deser. numbers as
strings, strings as numbers etc when possible, but it would be nice.
> - no members with duplicate name: the only point I don't know.
>
This one is painful as it has an impact on performances (esp. if we want to
prevent user custom code to generate such output)... at the moment I don't
support it in Genson for this reason.
> Intellij Idea makes this kind of JON invalid. This is something we
> would need to be able to switch off but I think it makes sense to have
> it by default to detect wrong models.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-04-18 19:53 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> > Hi Experts,
> >
> >
> > JSON-B should provide support or some level of compliance with I-JSON
> > specification.
> >
> > https://tools.ietf.org/html/rfc7493
> >
> > There are several things to discuss.
> >
> > Should JSON-B support I-JSON by default? My proposal is to not support
> all
> > the recommendations of I-JSON by default.
> >
> > If we agree on that, what specific parts of I-JSON should JSON-B provide
> by
> > default?
> >
> >
> > Proposal of parts (of I-JSON) to support by JSON-B by default:
> >
> > Should be supported by default:
> > - Encoding and Characters (UTF-8 by default)
> > - Object constraints (no members with duplicate name)
> > - MUST-IGNORE policy - partial mapping
> > - Time and Date Handling - serialize accoring to I-JSON
> >
> > Should not be supported by default:
> > - Numbers - serialize big number(s) into string (and deser given strings
> > into number)
> > - Top-Level Constructs - fail fast when ser/deser something different
> than
> > object/array as top-level JSON
> > - binary data encoded as a string in base64url
> >
> >
> > To support I-JSON fully in some case, I propose to provide I-JSON
> > compatibility mode available via config property.
> >
> > JsonbConfig config = new
> > JsonbConfig().setProperty("jsonb.i-json.compliance", true);
> > Jsonb jsonb = JsonbBuilder.create(config);
> >
> > Looking forward to your feedback.
> >
> > MartinV
>