> 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