Could be, more interesting I think it would be in the profile definition
for unmarshalling, where there should be a possibility to reject non
I-JSON messages soonest in the stack - that I think would fall to JSON-P
category, too.
MartiNG
On 29.04.15 14:42, Martin Vojtek wrote:
> Actually I think JSON-P can help at least with unique names of
> properties. I can imagine that JSON-P could provide option to enforce
> uniqueness of names of properties (in terms of key/value - keys).
>
> MartinV
>
> On Tue, Apr 28, 2015 at 2:21 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com
> <mailto:cepoi.eugen_at_gmail.com>> wrote:
>
> +JSON-P EG
>
> I don't remember seeing I-JSON being discussed on the jsonp ML.
> But perhaps this spec is more at the databinding level and doesn't
> need to be implemented in jsonp.
>
>
> 2015-04-28 14:01 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com
> <mailto:rmannibucau_at_tomitribe.com>>:
>
> 2015-04-28 13:53 GMT+02:00 Martin Grebac
> <martin.grebac_at_oracle.com <mailto:martin.grebac_at_oracle.com>>:
> > On 27.04.15 19:26, Romain MB wrote:
> >>
> >> 2015-04-27 18:38 GMT+02:00 Martin Grebac
> <martin.grebac_at_oracle.com <mailto:martin.grebac_at_oracle.com>>:
> >>>
> >>> On 24.04.15 20:54, Martin Vojtek wrote:
> >>>>
> >>>> I think that the result of the discussion is as follows:
> >>>>
> >>>> 1. support of string values for big numbers by default
> >>>> 2. support the override of properties by default
> >>>> 3. fail fast when non-unique property (after override and
> rename) is
> >>>> found
> >>>> 4. define default algorithm for override (based on java
> mechanism) and
> >>>> check uniqueness of properties (not affecting performance)
> >>>> 5. Do not enable I-JSON by default due to the following
> recommendations
> >>>> - support only root objects/arrays by default
> >>>> - serialize binary data to base64 by default
> >>>
> >>> To me, none of the 2 reasons above seem strong enough to
> not support
> >>> I-JSON
> >>> by default. Binary data is a specific usecase which is
> most often going
> >>> to
> >>> be configured based on specific needs, and root objects
> are limitation of
> >>> current version of JSON-P as well (and I assume of some
> other parsers,
> >>> too,
> >>> otherwise the requirement would not be in I-JSON), so
> clients using
> >>> JSON-P
> >>> would have hard time parsing the default JSON Binding output.
> >>
> >> Not sure I fully get you. Ok about root objects point -
> this one is
> >> not that important I agree. That said from my understanding
> I-JSON
> >> recommands to use base64url by default (did I
> misunderstand?). If so I
> >> would prefer we don't follow this point as already explained in
> >> another mail.
> >
> > Thanks, I'm looking for the reasons why not to. The reasons
> for following
> > the recommendation is that base64url has its advantages,
> such as it is
> > leveraged within JSON security (encryption/signature)
> standards, and for
> > similar reasons it is a recommendation within I-JSON.
> Against, I found this
> > (let me know if I missed some other reasons, the thread is
> rather long):
> >
> > - 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
> >
> > I'm not sure what does it mean far from Java. SE8 gives
> options to
> > encode/decode to base64 or base64url:
> > https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html
> >
>
> Was more in term of design. If I use byte[] then I don't
> expect the
> serializer to *automatically* create a String. If i want a base64
> string then I would have used a String directly IMO. Moreover
> if then
> I use a byte[][], does it serialize it as String[] or really
> byte[][]?
> In first case it will not match much cases IMO (and break default
> expectations) and in second case it is not consistent with byte[]
> serialization. So globally I would prefer to provide out of
> the box a
> converter/serializer (whatever name we use) to allow to
> convert it to
> base64url instead of having it implicitly.
>
> > You are right this is not a requirement, but recommendation,
> so there is an
> > option to opt out of this specific item (and/or some other
> ones within
> > I-JSON). Definition of recommendation is 'there may exist
> valid reasons in
> > particular circumstances to ignore a particular item, but
> the full
> > implications must be understood and carefully weighed before
> choosing a
> > different course'.In my view, I don't see the reasons for
> opting out (at
> > least not yet).
> >
> > MartiNG
> >
>
>
>
--
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague