rest/datatypes: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (en-US)
 
(13 intermediate revisions by 3 users not shown)
Line 73: Line 73:
* dateTime[.iso8601]
* dateTime[.iso8601]


Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined.  That said, there are a number of open questions about how to use them:
While not perfect, these certainly cover the 80% case, and are reasonably well-defined.  That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?  
# should 'string' also be explicitly specified, or can it be assumed?  
#*Assumed, and also defined as utf-8. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)  
#*Assumed, and also defined as utf-8. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)  
#*Agreed with Kevin. 'string' should be the default if no type is specified.  Publishers MAY explicitly specify 'string'.
#*Agreed with Kevin. 'string' should be the default if no type is specified.  Publishers MAY explicitly specify 'string'. - Tantek
#*Shouldn't the encoding be that of the page the markup is found on (as specified in the HTTP and HTML specs), rather than defined as utf-8? [[User:Jim Ancona|Jim Ancona]]
#*Jim, that's a good point, the encoding should be determined by the rules of the containing document ((X)HTML) and protocol (HTTP). - Tantek
# does 'int' always mean 32-bits?
# does 'int' always mean 32-bits?
##  If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?  
##  If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?  
Line 85: Line 87:
###SQL's "decimal", perhaps?
###SQL's "decimal", perhaps?
##  If not, how should conforming implementations react to longer integers than they can handle?
##  If not, how should conforming implementations react to longer integers than they can handle?
##*I think integer is fine - we don't have an explict constraint here. Do you want to define +Inf -Inf and NaN behaviour? Certainly when building testcases and examples include these.  
##*I think integer is fine - we don't have an explict constraint here. Do you want to define +Inf -Inf and NaN behavior? Certainly when building testcases and examples include these.  


# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)
# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)
Line 92: Line 94:
== Proposal ==
== Proposal ==
The proposal is to adopt [http://www.xmlrpc.com/spec/ XML-RPC] scalar values as the class names for typed microformats, with the following caveats:
The proposal is to adopt [http://www.xmlrpc.com/spec/ XML-RPC] scalar values as the class names for typed microformats, with the following caveats:
* the alias 'i4' for integer SHOULD not be used
=== Integers ===
* the name 'long' MAY be used for 64-bit or longer integers
* the alias ''i4'' for integer SHOULD NOT be used
* for 'dateTime'
* the name ''long'' MAY be used for 64-bit or longer integers
** can we make this 'datetime' ? [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
* thus, the name ''int'' MAY be used for more than 32-bit signed integers
** microformats don't use camel case.  please see [[naming-principles]]. alternatives (Tantek):
 
*** date-time (if you consider it to be two words)
=== Date and Time ===
*** datetime (as proposed by Kevin, if you think it is one word)
* use ''datetime'' for ''dateTime.iso8601''
*** dt (reusing the common prefix shared by existing microformat class names: dtstart, dtend, dtreviewed from [[hcalendar|hCalendar]] and [[hreview|hReview]].  We could also make that a general rule for microformat class names for properties which take ISO8601 datetimes. (Tantek)
** camelCase is not appropriate according to microformat [[naming-principles]].
** the trailing '.iso8601' MUST be omitted, as '.' is not (always?) valid in HTML class names
** '.' is neither a valid HTML class name, nor a valid character (unescaped at least) in a CSS class selector
*** '.' is neither a valid HTML class name, nor a valid character (unescaped at least) in a CSS class selector. - Tantek
** Alternative: dt (reusing the common prefix shared by existing microformat class names: dtstart, dtend, dtreviewed from [[hcalendar|hCalendar]] and [[hreview|hReview]].  We could also make that a [http://microformats.org/wiki/naming-principles#dt_properties general rule for microformat class names for properties which take ISO8601 datetimes]. (Tantek)
** date/time formats SHOULD follow the [http://www.w3.org/TR/NOTE-datetime W3C profile] of [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]
* date/time formats SHOULD follow the [http://www.w3.org/TR/NOTE-datetime W3C profile]
** a more human-readable rendering may be used, with the ISO8601 value in an "abbr"
** at any rate, they MUST follow [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]
** a more human-readable rendering may be used, with the ISO8601 value in an ''abbr''
=== Binary Data ===
* binary data SHOULD be encoded in a [http://en.wikipedia.org/wiki/Data:_URI_scheme data: URI], with an explicit [http://www.htmlhelp.com/reference/html40/special/a.html ContentType] and a human-readable description as the body of the anchor.
* binary data SHOULD be encoded in a [http://en.wikipedia.org/wiki/Data:_URI_scheme data: URI], with an explicit [http://www.htmlhelp.com/reference/html40/special/a.html ContentType] and a human-readable description as the body of the anchor.
* if no datatype is specified, an implementation MAY either attempt to infer a datatype from the syntax of the value, or simply assert that the value is a string.  Thus, conforming implementations SHOULD always explicitly label strings.
* therefore, use ''binary'' for ''base64'', as there may be alternate, non-base64 encodings in the future
** Disagree - either we are labelling datatypes and thus labelling string is redundant, or we are trying to guess from syntax. If the latter this whole spec is unnecessary. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
 
** Agreed with Kevin.  Let's keep 'string' as the default, and allow explicit usage of it. -Tantek
=== String ===
* ''string'' MAY be omittted
* thus, any unlabeled entries MUST be interpreted as strings.
 
== Usage ==


To indicate that a particular micforomat uses typed values, precede that microformat with the class name 'typed', as in:
To indicate that a particular micforomat uses typed values, precede or follow that microformat with the class name ''typed'', as in:


<pre><nowiki>
<pre><nowiki>
  <ol class="typed xoxo">
  <ol class=''typed xoxo''>
</nowiki></pre>
</nowiki></pre>


or


== Example ==
<pre><nowiki>
<ol class=''xoxo typed''>
</nowiki></pre>


  &lt;dl class="typed xoxo">
In other words, this defines what might be called the "<pre>typed</pre>" microformat.
  &lt;dt>key&lt;/dt>&lt;dd class="string">value&lt;/dd>
  &lt;dt>integer&lt;/dt>&lt;dd class="int">137&lt;/dd>
  &lt;dt>real&lt;/dt>&lt;dd class="double">3.14159265&lt;/dd>
  &lt;dt>date&lt;/dt>&lt;dd class="dateTime">1994-11-05T13:15:30Z&lt;/dd>
  &lt;dt>date(abbr)&lt;/dt>&lt;dd class="dateTime">&lt;abbr title="1994-11-05">November 5, 1994&lt;/abbr>&lt;/dd>
  &lt;dt>true&lt;/dt>&lt;dd class="boolean">1&lt;/dd>
  &lt;dt>false&lt;/dt>&lt;dd class="boolean">0&lt;/dd>
  &lt;dt>data&lt;/dt>&lt;dd class="base64">&lt;a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image&lt;/a>&lt;/dd>
  &lt;/dl>


Example revised with above suggestions:
== Summary ==
* string (optional)
* boolean (0,1)
* int (WAS i4; MAY use long)
* double
* datetime (WAS dateTime.iso8601)
* binary (WAS base64)
* nil


  &lt;dl class="typed xoxo">
== Example ==
&lt;ol class="typed xoxo"> # every XOXO must begin with ol or ul
  &lt;li> 
  &lt;dl> 
   &lt;dt>key&lt;/dt>&lt;dd>value&lt;/dd>
   &lt;dt>key&lt;/dt>&lt;dd>value&lt;/dd>
   &lt;dt>integer&lt;/dt>&lt;dd class="int">137&lt;/dd>
   &lt;dt>integer&lt;/dt>&lt;dd class="int">137&lt;/dd>
Line 141: Line 153:
   &lt;dt>data&lt;/dt>&lt;dd class="binary">&lt;a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image&lt;/a>&lt;/dd>
   &lt;dt>data&lt;/dt>&lt;dd class="binary">&lt;a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image&lt;/a>&lt;/dd>
   &lt;/dl>
   &lt;/dl>
 
  &lt;/li>
'''Note:''' [[xoxo|XOXO]] always starts with either <code>ol</code> or <code>ul</code>. The <code>dl</code> in XOXO is always used to declare the properties of a specific <code>li</code>. These examples should be updated accordingly. -Tantek
  &lt;/ol>
 


== References ==
== References ==
Line 150: Line 161:
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal
 
* HTML 5 [http://hsivonen.iki.fi/html5-datatypes/ datatypes]


== See Also ==
== See Also ==
* [[xoxo]]
* [[xoxo]]
* [[naming-principles]]
* [[naming-principles]]

Latest revision as of 22:50, 31 August 2007

Datatypes in HTML

One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with xoxo and rest/ahah, in order to allow lossless import/export from various languages. These could also be used with forms to provide rest/descriptions of the type of data expected.

Contributors

  • Dr. Ernie Prabhakar
  • Chris RG
  • Mark Rickerby
  • Robert Bachmann
  • Kevin Marks
  • Tantek Çelik

Examples

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by xoxo.

Datatype comparison table
Language/format string float integer boolean data date/time null
XML Schema string float, double decimal, integer, etc. boolean hexBinary, base64Binary duration, dateTime, date, time nil
XML-RPC string double i4, int boolean base64 dateTime.iso8601 nil
Mac OS X plists string real integer true, false data date nil
JSON (JavaScript) string number number true, false N/A Date nil
YAML tags str int float bool null (base 64) N/A null
SQL (JDBC) char,varchar float, double, real decimal, numeric bit binary date, time, timestamp ?
C char[] float, double int, long, short bool, int char[] N/A (void*)0
Java char, String float, double int, long, short, byte boolean N/A util.Date null
PHP string float (double) integer boolean array N/A NULL
Perl array scalar scalar scalar array N/A
Python str float, complex int, long bool binascii, base64 time,datetime
Ruby + lib String Float Fixnum, Bignum TrueClass,FalseClass Hash Date NilClass
REBOL string! decimal! integer! logic! binary! date!, time! none!

Analysis

The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:

  • string
  • double
  • int [i4] - 4-byte integer (32-bit)
  • boolean (0,1)
  • base64
    • Lets call this 'binary' as the encoding is in the data: url, and DRY applies
    • RFC 2426 uses "B", which, when lowercased per microformats naming-principles is 'b'. -Tantek
  • dateTime[.iso8601]

While not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:

  1. should 'string' also be explicitly specified, or can it be assumed?
    • Assumed, and also defined as utf-8. Kevin Marks 16:39, 13 Feb 2006 (PST)
    • Agreed with Kevin. 'string' should be the default if no type is specified. Publishers MAY explicitly specify 'string'. - Tantek
    • Shouldn't the encoding be that of the page the markup is found on (as specified in the HTTP and HTML specs), rather than defined as utf-8? Jim Ancona
    • Jim, that's a good point, the encoding should be determined by the rules of the containing document ((X)HTML) and protocol (HTTP). - Tantek
  2. does 'int' always mean 32-bits?
    1. If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
      1. Python's 'long' is simple, but ambiguous.
      2. Ruby's BigNum is clear but much less common.
      3. XML-Schema has so many types it is hard to say.
        • In this case, XML-Schema makes the distinction that 'int' represents a standard 32 bit integer, while 'integer' represents a signed integer of arbitrary length.
      4. SQL's "decimal", perhaps?
    2. If not, how should conforming implementations react to longer integers than they can handle?
      • I think integer is fine - we don't have an explict constraint here. Do you want to define +Inf -Inf and NaN behavior? Certainly when building testcases and examples include these.
  1. Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)
    • See comments below regarding date-time.

Proposal

The proposal is to adopt XML-RPC scalar values as the class names for typed microformats, with the following caveats:

Integers

  • the alias i4 for integer SHOULD NOT be used
  • the name long MAY be used for 64-bit or longer integers
  • thus, the name int MAY be used for more than 32-bit signed integers

Date and Time

Binary Data

  • binary data SHOULD be encoded in a data: URI, with an explicit ContentType and a human-readable description as the body of the anchor.
  • therefore, use binary for base64, as there may be alternate, non-base64 encodings in the future

String

  • string MAY be omittted
  • thus, any unlabeled entries MUST be interpreted as strings.

Usage

To indicate that a particular micforomat uses typed values, precede or follow that microformat with the class name typed, as in:

 <ol class=''typed xoxo''>

or

 <ol class=''xoxo typed''>

In other words, this defines what might be called the "

typed

" microformat.

Summary

  • string (optional)
  • boolean (0,1)
  • int (WAS i4; MAY use long)
  • double
  • datetime (WAS dateTime.iso8601)
  • binary (WAS base64)
  • nil

Example

<ol class="typed xoxo"> # every XOXO must begin with ol or ul
 <li>   
 <dl>  
  <dt>key</dt><dd>value</dd>
  <dt>integer</dt><dd class="int">137</dd>
  <dt>real</dt><dd class="double">3.14159265</dd>
  <dt>date</dt><dd class="datetime">1994-11-05T13:15:30Z</dd>
  <dt>date(abbr)</dt><dd class="datetime"><abbr title="1994-11-05">November 5, 1994</abbr></dd>
  <dt>true</dt><dd class="boolean">1</dd>
  <dt>false</dt><dd class="boolean">0</dd>
  <dt>data</dt><dd class="binary"><a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image</a></dd>
 </dl>
 </li>
</ol>

References

See Also