[uf-rest] Introducing JAHAH

[Dr.Ernie Prabhakar]

Hi Bob,

On Jan 5, 2006, at 6:00 PM, Bob Ippolito wrote:
>> 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.

One of the things about microformats (in case you hadn't learned how  
the game is played here :-) is to try to follow existing conventions  
as much as possible.  In this case, I started with Mac OS X plists,  
and moved to XML Schema Datatypes:

http://www.w3.org/TR/xmlschema-2/#built-in-datatypes

Yes, it is somewhat complex, but it is a well-defined standard.   I'm  
certainly open to doing something simpler, but I'd want to have some  
reasonably strong precedent, so it doesn't just become personal  
taste.  I do like the idea of defaulting to a generic, high-precision  
'number' class, especially since it is easy to specialize using  
multiple classes.

I personally like the Mac OS X plist typing (number, data, etc.), but  
I don't know if that's normative enough to drive a web standard.

Tantek, Kevin -- I feel it is time to start capturing this concept on  
the wiki somewhere, as there appears to be sufficient demonstrated  
interest in using xoxo in this manner, and it would be good to do the  
research and normalize something.  So its not just something created  
over beers in an Indian restaurant last month...

Where would be the optimal place?  Off the main xoxo page, or under  
the rest section?  Can you suggest a good page title?

Thanks,

-- Ernie P.


>
> 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