- From: Chris Tilbury <C.J.Tilbury@estate.warwick.ac.uk>
- Date: Fri, 7 Jul 1995 14:36:24 BST
- To: papresco@calum.csclub.uwaterloo.ca (Paul Prescod), lilley <lilley@afs.mcc.ac.uk>
- Cc: www-html@www10.w3.org
On 7 Jul 95 at 13:46, lilley wrote: > Paul Prescod said: > > The real problem is not in HTML, it is in the non-existance of a > > widely used chart data format. I think Paul really meant "non-proprietary widely used" :-) > Actually there is an existing Internet Media Type (MIME type) called > > text/tab-separated-values > > which can have any suitable graphing program as a viewer. I use xmgr Which, as lilley points out, there is. Whilst bringing in external standards is one possibility, perhaps we need to hark back to one of the "first principles" of HTML, that being that it is intended to be a simple markup language. We already have an (proposed) element in <TABLE> which is ideally suited to storing numeric /data/ - a markup version of text/tab-separated-values, if you like - and along with the <TD> and <TH> elements and the CLASS attribute (as well as the AXIS and AXES attributes in more complex cases) we can sufficiently identify the structure of that data such that it can be interpreted by a browser. I would personally like to avoid a new <CHART SRC="some_url"> element, or some application of the <FIG> container, for a number of reasons. Chief amongst these are (i) {on <CHART>} If we can manage it successfully with what is currently available, why add another unnecessary element? The HTML 3 Draft already has many, many tags - of which the content value of some is slightly dubious (<I>, <SMALL>, <BIG>, <B>). We should, ideally, be looking to depreciate some (all?) of these, not add new and unnecessary ones. {on <FIG SRC="data.tab">} Likewise, further complicating the HTML standard by using a separate external format for storing numeric data, just because the author has hinted, via the stylesheet, that he/she would /like/ the data to be rendered as a 3d pie chart titled at 45 degrees with the second and fifth segments exploded by 10% of the diameter of the pie, is probably not a good idea. If nothing else, it instantly excludes the person /viewing/ the document from being able to take their favourite browser, point it at a page created by someone with enough knowledge to create tables (but not enough knowledge to use the other format) and choosing a browser option which allows /them/ to render the data in a chart after a little bit of direction on the precise structure of the data in the table. (ii) platform independence. I prefer the original posters suggestion of using the <TABLE> tag, if for no other reason than if a platform is unable to have an external chart viewer it can merely ignore the styles applied to that TABLE element and render in a tabular text format, or read it aloud in the case of a visually impaired or blind user. Yes, we could come up with a standard which could be interpreted in different fashions by a range of viewers, or incorporate an existing standard into HTML/Web Browsers), but why do this (see [i] above) if what we have already is sufficient - isn't it this which HTML is supposed to do be so good at? (iii) Using the <STYLE>, or <LINK> to stylesheet, mechanisms also gives authors the ability to compose different stylesheets for different environments if it is known that a certain environment is incapable of succesfully reproducing a certain style. This would keep the platform-specific brigade happy, if nothing else. In my mind, there is no need to alter the HTML markup elements in order to fulfill the charting requirements - leave it as-is. Stylesheets provide us with all we need, and they keep it out of the actual HTML standard, which is a Real Good Thing, IMHO. :-) Ciao, Chris -- Chris.Tilbury@estate.warwick.ac.uk; MIME Mail Welcome Tel: +44 1203 523523x2665, Fax: +44 1203 524444
Received on Friday, 7 July 1995 09:38:09 UTC