I have been very leery of the Client-side imagemaps, and the prospect of vector
images makes me moreso. One problem with the client-side approach is that it
is not very scalable. I run several imagemaps now with over 50 hotspots, and
those of us in the GIS/Mapping industry have several applications waiting in
the wings which could conceivably have thousands of hotspots. I don't think
anyone would want these encoded in the HTML code. In my mind, the best place
to encode these is within the file itself (I say that because I would probably
be generating the files on-the-fly, not using existing CGM files).
The other problem denotes that you seem to have missed one of the advantages
of Softsource's proposal (which could just as easily be done with CGM), which
is the ability of the browser/viewer to do zooming and panning on the file.
How would moving targets be handled with client-side imagemap definitions?
The first two of your three points above can be done with graphics-file-
encoded imagemaps just as easily as client-side. I believe all three imagemap
methods have their merits for different situations, and would like to see them
all stick around.
About the standardization of CGM: I don't think it is any more difficult to
have a working group build a standard WWW CGM profile than to build SVF.
Vision: Vector support can impact much more than distributing engineering
drawings. If it is done right, it can lend a whole new metaphor to
the WWW. Designers could use either (preferably both, for graphics-impaired
users) a text-based metaphor (HTML) or a truly visual-based one (SVF/CGM),
both with the same hypertext capabilities. The two metaphors should be
compatible, but separable (i.e. I should have a graphics-based browser which
can include HTML text as part of an image, as well as vice versa).
Brandon Plewe
plewe@acsu.buffalo.edu