Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

[Ulysse Carion <[e-mail]>]

This seems like another example of a call I'd rather not have to make,
nor insert into the core spec.

Again -- nothing stops folks who have specific limitations to add
specific extensions. And just because something isn't validated in
JDDF itself doesn't mean it can't be validated at all.

On Sun, Sep 1, 2019 at 4:38 PM John Cowan <[e-mail]> wrote:
>
> I agree that that is somewhat arbitrary, but I'd say the length of a string is its length in bytes in UTF-8 encoding, given that UTF-8 is the standard encoding of JSON.
>
> On Sun, Sep 1, 2019 at 7:24 PM Ulysse Carion <[e-mail]> wrote:
>>
>> How is such a thing supposed to work portably? What is the "length" of
>> a JSON string, and does this have any correspondence to the memory
>> representation of that string, post-parsing?
>>
>> On Sun, Sep 1, 2019 at 4:14 PM John Cowan <[e-mail]> wrote:
>> >
>> > The argument for it is precisely in situations where static allocation is required along with static typing.  If you know the (maximum) length, you can safely allocate a fixed amount of memory for your internal representation, which you cannot do otherwise.   Languages with static types and garbage collection (allowing dynamic allocation) are just one particular kind of languages, and I think you need to accommodate all widely used kinds of languages.  I wouldn't object to skipping bounded arrays and strings in favor of just fixed-length ones.
>> >
>> > See < http://www.catb.org/esr/microjson/>, a JSON-subset parser written in C that imposes exactly this restriction so that it can run safely on embedded systems with only small amounts of RAM.
>> >
>> >
>> > On Sun, Sep 1, 2019 at 7:03 PM Ulysse Carion <[e-mail]> wrote:
>> >>
>> >> Sure -- but you could use the length validation as a hint to code
>> >> generators, and a warning to data producers that the application will,
>> >> post JDDF-level validation, do additional length checks.
>> >>
>> >> I'm not sure the need for length validation is strong enough to merit
>> >> its inclusion in this version of the spec.
>> >>
>> >> On Sun, Sep 1, 2019 at 3:42 PM John Cowan <[e-mail]> wrote:
>> >> >
>> >> > Section 2.3 says that extensions can't be validation-related, so a length limitation would most certainly be a matter of validation.
>> >> >
>> >> > On Sun, Sep 1, 2019 at 6:28 PM Ulysse Carion <[e-mail]> wrote:
>> >> >>
>> >> >> Fixed-length strings and arrays both sound like things one could
>> >> >> implement with extensions, no?
>> >> >>
>> >> >> Tuples are a very sensible suggestion. But I wonder if we can live
>> >> >> without them? I very much want to keep JDDF as small as possible.