Re: <graph>

"Steven D. Majewski" <sdm7g@virginia.edu>
Date: Fri, 9 Sep 94 07:57:15 EDT
Message-id: <Pine.A32.3.90.940909030153.15125B-100000@elvis.med.Virginia.EDU>
Reply-To: sdm7g@virginia.edu
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: "Steven D. Majewski" <sdm7g@virginia.edu>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: <graph>
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)

On Thu, 8 Sep 1994, Tom Magliery wrote:

> 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