JSON, quoted integers, and lasso

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

JSON, quoted integers, and lasso

Robert Carpenter
Seems like JSON is the only thing I post about lately...

Here's something a bit more weird that I've found in working with  
vimeo's JSON output, not sure if it will be as easy a fix as the  
forward slash bit:

The data I'm getting from them has members for "width" and "height",  
both of which are sent as quoted integers, i.e.:

{...
"width":"400",
"height":"240"
...}

Okay, so that's probably wrong on their part, but what's driving me a  
bit nutty is that decode_json is returning them as date types, i.e.:

map(...
(width)=(01/01/0400 00:00:00),
(height)=(01/01/0240 00:00:00),
...)

And I'm all like "huh?"

As a side note, in an earlier project, I had noticed this behavior  
when receiving ISO formatted date strings, like this:
{...
"showDate": "2025-01-01T00:00:00"
...}

And I remember being pretty happy that Lasso was doing to the "right  
thing" when decoding them. I thought "gee, that's pretty slick, I  
don't have to write code to coerce them into dates..."

I'm guessing the problem resides in lines 209-213, but a solution that  
allows for the desirable behavior above while excluding the undesired  
behavior isn't jumping out to me - thoughts?

-Robert-



--
This list is a free service of LassoSoft: http://www.LassoSoft.com/
Search the list archives: http://www.ListSearch.com/Lasso/Browse/
Manage your subscription: http://www.ListSearch.com/Lasso/


Reply | Threaded
Open this post in threaded view
|

Re: JSON, quoted integers, and lasso

Steve Upton
At 12:48 PM -0700 4/8/09, Robert Carpenter wrote:

>Seems like JSON is the only thing I post about lately...
>
>Here's something a bit more weird that I've found in working with vimeo's JSON output, not sure if it will be as easy a fix as the forward slash bit:
>
>The data I'm getting from them has members for "width" and "height", both of which are sent as quoted integers, i.e.:
>
>{...
>"width":"400",
>"height":"240"
>...}
>
>Okay, so that's probably wrong on their part, but what's driving me a bit nutty is that decode_json is returning them as date types, i.e.:
>
>map(...
>(width)=(01/01/0400 00:00:00),
>(height)=(01/01/0240 00:00:00),
>...)
>
>And I'm all like "huh?"
>
>As a side note, in an earlier project, I had noticed this behavior when receiving ISO formatted date strings, like this:
>{...
>"showDate": "2025-01-01T00:00:00"
>...}
>
>And I remember being pretty happy that Lasso was doing to the "right thing" when decoding them. I thought "gee, that's pretty slick, I don't have to write code to coerce them into dates..."
>
>I'm guessing the problem resides in lines 209-213, but a solution that allows for the desirable behavior above while excluding the undesired behavior isn't jumping out to me - thoughts?

thoughts, yes. Useful conclusions, no.

I came across this same problem some time back. Luckily I have control over both ends so it was more of a learning experience for me rather than an encoding / decoding nightmare.

As far as I could determine, quotes around integers is simply bad JSON encoding. From what I read on JSON.org, integers are not supposed to be quoted. In theory that removes the potential confusion with a date object.

Of course, sometimes, in the real world, we do have strings that are composed of only numeric characters. Does this mean that they should be encoded into JSON as integers? It makes sense on the way out of Lasso and in other systems that are weakly typed but decode it into another system (like REALbasic) and suddenly you might be handed an integer data type when you expected a string... painful.

I really like JSON but I think that its sparseness raises the potential for machine confusion / ambiguous data handing situations.

It's like the encoding of forward slashes. Who's to say that what appears to be an encoded character isn't actually supposed to be a normal string of bytes.

As JSON is supposed to originate from Javascript I tend to look at how JS encodes & decodes JSON as a guide. How does a string composed only of numeric characters encode into JSON from Javascript? How does quoted text in JSON get treated? Another way of asking is, can Javascript deal with vimeo's JSON? FireFox and FireBug are your friends with this stuff.

It sounds to me like the vimeo JSON might need some tuning. JSON is fairly new, perhaps their testing isn't up to snuff...

regards,

Steve





--


--
This list is a free service of LassoSoft: http://www.LassoSoft.com/
Search the list archives: http://www.ListSearch.com/Lasso/Browse/
Manage your subscription: http://www.ListSearch.com/Lasso/


Reply | Threaded
Open this post in threaded view
|

Re: JSON, quoted integers, and lasso

Robert Carpenter

On Apr 8, 2009, at 2:21 PM, Steve Upton wrote:

> At 12:48 PM -0700 4/8/09, Robert Carpenter wrote:
>> Seems like JSON is the only thing I post about lately...

> thoughts, yes. Useful conclusions, no.

Thanks for those thoughts. I'm starting to think the main issue here  
is that lasso is perhaps over-reaching in it's decoding - again, I was  
pleasantly surprised that it "did the right thing" with my ISO dates,  
but I'm now feeling that the "correct" approach is probably to just  
let strings be strings and leave it up to the app logic to decide if  
they need typing. As you point out, sometimes ITRW strings are  
comprised of integers, but they're still strings, damnit.

I should point out that I really appreciate the work Fletcher, et al,  
have done to add this functionality. I'm not attacking here, just  
offering my perspective.

> It sounds to me like the vimeo JSON might need some tuning.

No doubt. But again, given that we'll probably see more of this sort  
of ambiguity from various providers out in internetland, perhaps the  
best approach is to just keep the decoding process simple

> I really like JSON but I think that its sparseness raises the  
> potential for machine confusion / ambiguous data handing situations.


I agree - I *really* want JSON to be useful, if only because XML seems  
such overkill for tossing around smallish collections of name:value  
pairs, but these ambiguities sure make it tougher to use.

To wrap this thread, on my local install, I've killed the section of  
JSON.lasso that is turning quoted integers into dates (roughly lines  
209-214). I guess I'll just have to manually type my strings-that-
happen-to-be-dates, which is fine by me.

On a related note, anyone know why these return true when #output is a  
string with the value of "400" (or any smallish integer value)?:

(Valid_Date: #output, -Format='%QT%TZ');
(Valid_Date: #output, -Format='%QT%T');

-Robert-

--
This list is a free service of LassoSoft: http://www.LassoSoft.com/
Search the list archives: http://www.ListSearch.com/Lasso/Browse/
Manage your subscription: http://www.ListSearch.com/Lasso/


Reply | Threaded
Open this post in threaded view
|

Re: JSON, quoted integers, and lasso

Fletcher Sandbeck-3
On 4/8/09 at 3:49 PM, [hidden email] (Robert Carpenter) wrote:

>On Apr 8, 2009, at 2:21 PM, Steve Upton wrote:
>
>>At 12:48 PM -0700 4/8/09, Robert Carpenter wrote:
>>>Seems like JSON is the only thing I post about lately...
>
>>thoughts, yes. Useful conclusions, no.
>
>Thanks for those thoughts. I'm starting to think the main issue here
>is that lasso is perhaps over-reaching in it's decoding - again, I was
>pleasantly surprised that it "did the right thing" with my ISO dates,
>but I'm now feeling that the "correct" approach is probably to just
>let strings be strings and leave it up to the app logic to decide if
>they need typing. As you point out, sometimes ITRW strings are
>comprised of integers, but they're still strings, damnit.

It should only decode strings as dates if they are in fully
qualified combined ISO 8601 format yyyy-mm-ddThh-mm-ss.  I think
there is a bug in [Valid_Date], fixed in Lasso 8.5.6 beta, which
makes this work properly (as I see you mention later in your message).

Here's the new definition if you want to replace it in your
LassoLibraries/Valid.lasso file.  With this only complete date
strings should be decoded as dates.  Of course, you could just
comment out the lines that check for the date/time strings and
then it won't try that at all.  There probably should be a
parameter which turns that functionality on and off.

[fletcher]


Define_Tag: 'Date', -Priority='Replace',
         -Namespace='_global_Valid_',
         -Required='date',
         -Optional='format';

     // Empty input
     #date == null ? return: false;
     (string: #date)->trim & == '' ? return: false;

     // Parse date
     if: (local_defined: 'format');
         local: 'parse' = (date: #date, -format=#format);
     else;
         local: 'parse' = (date: #date);
     /if;

     // Invalid dates
     (#parse->type == 'null') ? return: false;
     ((string: #parse)->size == 0) ? return: false;
     (#parse >> '0000') ? return: false;

     // Strict check of format against original date (allowing
for leading zeroes or spaces)
     if: (local_defined: 'format');
         (string: #date) == #parse->(format:
(string_replaceregexp: #format, -find='%-?_?', -replace='%')) ?
return: true;
         (string: #date) == #parse->(format:
(string_replaceregexp: #format, -find='%-?_?', -replace='%_')) ?
return: true;
         (string: #date) == #parse->(format:
(string_replaceregexp: #format, -find='%-?_?', -replace='%-')) ?
return: true;
         return: false;
     /if;

     return: true;

/Define_Tag;

--
Fletcher Sandbeck                         [hidden email]
LassoSoft, LLC                          http://www.lassosoft.com


--
This list is a free service of LassoSoft: http://www.LassoSoft.com/
Search the list archives: http://www.ListSearch.com/Lasso/Browse/
Manage your subscription: http://www.ListSearch.com/Lasso/