> i have encountered, about fifth- or sixth-hand, the following query:
>
> >} >>> However, I would **LIKE** to put on my wishlist that HTML+ include,
> >} >>> along with the new tables and chemical notation features, some standard
> >} >>> support for graphs. Something like:
> >} >>>
> >} >>> <GRAPH TYPE=XY>
> >} >>> 0 0
> >} >>> 1 10
> >} >>> 2 40
> >} >>> 3 90
> >} >>> 4 160
> >} >>> </GRAPH>
> >} >>>
> >} >>>
> >} >>> ... and let the client side do the graphics.
> >} >>> Does anyone know if something like that has been proposed?
>
> this would open up a gigantic can of worms, it seems to me. has anyone
> else thought about it?
>
Well - it finally made a round trip!
I'm the author of the original message ( but I've somehow managed to miss
whatever intervening discussion I was quoted in! )
The <emphasis> in the phrase "**LIKE** to put on my wishlist"
indicates that I knew it would open up a "can of worms", so I
didn't expect it as a near term solution.
More effecient to send a list of ascii numbers than an image (usually)
A graph type is more structured and more in line with HTML indicating
markup and logical structure over presentation.
GIF or POSTSCRIPT looses (logical) information but fixes/secures
presentation information. <GRAPH> would leave presentation details
to the client. This could allow resizing or scrolling, as well
as the posibility of "sensitive" graphs.
The problem ("can of worms") I see is that a <GRAPH> type is
inherently more open ended than some other proposals like
chemical formula or math equations. Particularly, without any
"existing practice", a proposal is likely to produce a frenzy
of featuritis. [ Which is why I didn't propose it here in the
first place! ]
However, now that the proposal has been indirectly forwarded here,
I'ld like to modify it. Rather than a new <GRAPH> tag, I'ld
like to propose a modifier(s) to <TABLE> to indicate that a
graphic representation of the table is an alternate|preferred|
|required presentation format. ( I'm hoping that this change
would emphasize the view that there should be a minimum of
presentation control in the graph options. Basically, a
graph type (histogram,scatterplot,line-plot), some parameters
to indicate which columns of the table are X or Y values, and
a handful of control options. Otherwise, the client controls
the presentation. )
<TABLE GRAPH=type other-modifiers>
One optional modifier would indicate that if the client can't display
it as a graph, don't display anything at all. ( For GRAPH=HISTOGRAM,
where there are only a few numbers, it you can't display it graphically,
then you ought to just print the table values. For a line plot of 1000+
spectrometer channels * N spectra, if the client can't display a graph,
then nothing, or a placemarker, is better than a literal table. )
Obviously, this isn't a complete proposal. That's why I was fishing
around for "existing practice" or other comments first.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics