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
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
