NOTE-CSS-potential-19981210

Suggested extension: format model for data types
================================================

This suggestion is influenced by NOTE-CSS-potential 
(22. Spreadsheet functions), but relates not necessarily 
to tables.

The problem is, that content is still cluttered with style. E.g. 
a string representation of the real '1,234.56-' contains:

 - scale/precision (number of digits before and after the 
   decimal point)
 - character of decimal point
 - character of group (thousand) separator
 - character and position of the sign
 - notation (scientific or not)
 - ...

Today, format is applied at the "server-side," i.e., by the author 
of the page. If numbers must be rounded for display, spreadsheet 
and ECMAScript functions at the "client-side" are faulty.

  Example:

     # Original value Rounded Value
     - -------------- -------------
     1           1.13           1.1
     2           1.14           1.1
   --- -------------- -------------
   Sum           2.27           2.2 vs. 2.3 !!!

It is easy to see, that one runs into problems
when utilizing other functionalities, like the clipboard
with the rounded values.


Because of this, we suggest a format model for data types.
We use the term data type in his broadest possible sense and
are aware of the fact that HTML and CSS don't support types.
But together with other possible extensions (such as spreadsheets
as suggested in NOTE-CSS-potential) there is a need for the 
implementor to cope with data types. (Or at least to implement 
functionality that will treat some data as if it were of a specific 
data type.)


Generally, a format is applied, when data types are casted. When a 
web browser renders a HTML document, there are several source types 
that have to be casted into a displayable destination type.
In this case only one destination type is needed:

 - string (CDATA section)

And there are at least three source data types (related to ECMAScript) 
that should be supported:

 - number
 - boolean
 - datetime

In the next section we introduce our suggested format model and after 
that we discuss several possibilities to include it in Web-documents.


Format Models
-------------

Possible format models are:

 - C-like ( '%4.2d' )
 - Format masks ( '0###.##-' )
 - other, e.g. separate properties ( 'sign: trailing' )

We prefer format masks!
Format masks are easy to understand and are efficiently written.
The disadvantage of C is, that it supports only numbers and strings. 
And if separate properties are used, too many properties would be 
necessary. 

 Possible format masks:

 - number

   - #,##0.#-
   - +#####0.#
   - #.#E

   Group separator, decimal point (and possibly sign) are language 
   specific. So they could be specified via the lang attribute (e.g. 
   lang='de'). Then we prefer generic characters instead of the 
   language-specific symbols used above, e.g.

   - #G##0D#S

   Because this is harder to read, one could use the standard English 
   signs as generic characters, e.g.

   - #,##0.#-

   The user can redefine those signs to meet his local preferences.

   The examples are derived from

     - Oracle SQL Format Model (which is possibly derived from Cobol 
       pictures)

 - boolean

   - (true,false)
   - (0,1)
   - (yes,no)
   - (†, )

   These examples use simple enumeration.

 - datetime

   - YYYY-MM-DD
   - hh:mm:ss
   - YYYY-MM-DDThh:mm:ssTZD 
   - YYYY-MM-DD hh:mm:ssTZD 
   - DD-Mon-YY

   These examples are derived from

     - http://www.w3.org/TR/NOTE-datetime
     - ISO 8601
     - Oracle SQL Format Model



Integrating Format
------------------

There are different ways to deal with format models:

 - HTML extensions

   - e.g. <COL datatype='number' sign='trailing'>


 - CSS extension

   - e.g. 

       ...
       COL.num { format-mask: #,##0.#- }
       ...
       <COL class='num'>
       ...
       <TD> -1234.56 <TD> .56 
       ...

    should be rendered as ... |1,234.6-|    0.6 | ...
      

 - XML and XSL


 - other

   - e.g. ActionSheets (Netscape), Behaviors (Microsoft)


 We prefer CSS, because format is style!


See also: 22. Spreadsheet functions for a similar discussion of 
          an integration. 


We consider this proposal as an outline of formats for data types. 
If you find it useful, we would like to offer our help and 
cooperation for the process of specification.

--------------------------------------
Steffen Göldner, sgoeldner@eurodata.de
Holger Maier, hmaier@eurodata.de

Received on Friday, 8 January 1999 06:35:58 UTC