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> 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>:
>
>> 2015-04-28 13:53 GMT+02:00 Martin Grebac <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>:
>> >>>
>> >>> 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
>> >
>>
>
>