[uf-rest] Introducing JAHAH

[Bob Ippolito]

On Jan 5, 2006, at 5:30 PM, Dr. Ernie Prabhakar wrote:

>>> So, has anyone done a JSON<->XOXO bridge?
>>
>> I'm not terribly sure why you'd want to do it, the use cases are  
>> pretty different and they're definitely not 1:1 on features.  JSON  
>> has no canonical hyperlink representation, and XOXO has no  
>> canonical representation for null, numbers, booleans, or  
>> string:value maps.  JSON is the plist equivalent for the web.  In  
>> fact, it's awfully close in syntax to old-style NeXT plists (minus  
>> timestamps and data).
>
> Hmm, not sure what happened to my previous message.  Anyway,  
> hopefully this will answer your question:
>
> http://www.opendarwin.org/~drernie/xoxo-datatypes.html
>
> There's even a demo about it here:
>
> http://opendarwin.org/~drernie/C499496031/E20051026153908/index.html

Well you didn't say you were speaking of something other than the  
mainline XOXO :)  Given that extension, yes, there is certainly a  
complete mapping from JSON to XOXO... not quite the other way around  
though.  JSON has no representation for data, date, or set and list- 
of-dicts would be lossy.

I think there's too much TMTOWTDI in your spec though.

I'd drop double, float, and integer in place of a single number type:  
let's call it number.  The recommended implementation for Number  
would be a 64-bit floating point number (C double).  This is parity  
with JavaScript's Number type, Python's float, etc. and has enough  
bits to represent any number in either of your three types.  I'd also  
explicitly specify what to do with Inf, -Inf, and NaN; either make  
them invalid to have in a document, or represented as strings in some  
way.  If valid, the aforementioned spellings are convenient because  
that's what JavaScript understands.

hexBinary should go.  There's no particularly good reason to have it  
there.  base64 is more compact and widely available anyway.   
base64Binary should be renamed to simply data.  Note also that your  
hexBinary example actually has a base64 payload ;)

dateTime should be renamed to datetime (or timestamp) and its payload  
must either be in the date (YYYY-MM-DD) or UTC designator format  
(YYYY-MM-DDThh:mm:ss.sZ) to make implementations simpler.  I'd wager  
that people are prone to forget to capitalize it; especially given  
that everything in XHTML and all of the other types (now, anyway),  
are entirely lowercase.

-bob