I will elaborate some on my original mail, which was probably too brief
to be useful outside of its originally intended audience; and I'll
respond to some of Chris's points.
In overview, I want to make two basic points:
1. Recent work on CGM extensions (and the CGM:1992 republication)
provide the features to *enable* hot-link applications, with either
embedded or external link definitions.
2. Formats follow from requirements (or should do so). I have been
involved in standards requirements work for several years, including:
the exhaustive requirements studies (with associated ANSI and ISO
ballots) to define the new CGM:1992 capabilities; the work of several
application communities (CALS, ATA, petroleum, ODA, NITF, etc) who have
defined profiles of CGM (as well as IGES and other formats); and the
requirements work for the CGM Amd.2 "Application Structuring".
Graphics in electronic documents has been a prominent application in all
of this, including inline graphics, networked document applications,
intelligent graphics and IETM (interactive electronic technical manual),
hypermedia and multimedia. Nothing I have seen in the WWW dialog and
papers so far represents truely novel or unique requirements. Therefore
I assert that it is highly likely that the proposed "SVF" work can be
based on existing formats (such as CGM), rather than a totally
incompatible "from scratch" effort.
To respond to a couple of the detailed comments of Chris...
>Do a search for CGMs on http and ftp
>sites - most are 1987 CGM generated by Corel Draw.
Technical clarification: CGM:1987 is almost identical to the Version 1
level of CGM:1992 -- *almost* because the latter has incorporated a
number of "Defect Corrections" to the former. For most practical
purposes they are the same, but the latter should always be used instead
of the former, because of these defect corrections (in the words of the
ISO standard, CGM:1992 "supersedes and replaces" CGM:1987). CGM:1992
adds a lot of graphical horsepower in upward compatible Version 2 and
Version 3 levels. V2 and V3 features are just starting to appear in
implementations. The 1987 CGM from Corel Draw, assuming it was legal
in 1987, is likely valid under 1992.
>> This is wrong.
>
>I hope you mean, the first sentence is wrong (which it is; thanks for the
>information about Amd. 2 which I was unaware of). The second one is, of course,
>correct.
Yes, that is my meaning -- I was too brief in my comments here.
Some comments on the body of Chris's message...
Chris is correct that Amd.2 provides the "enabling technology" for hot
links to URL (or anything), but that the actual extensions must be
defined by the application community. In this case, the mechanism of a
Profile is appropriate. The WWW community would define a particular
Application Structure (or structures) to accomplish the job. A subset
of other CGM functions to provide an equivalent to SVF could also be
defined.
Profiles can be registered by a relatively quick process within ISO
(they are called International Standardized Profiles, ISP). This
approach (if adequately publicized) minimizes the chance that a second,
equivalent, but incompatible flavor from being defined (such is the
purpose of ISPs).
As Chris notes, profiles have helped to suppress the earlier
incompatible flavors of CGM. I believe the same would be true of a
hot-linked WWW application, and it would also minimize the problem of
"browser bloat" which Chris anticipates.
>Furthermore, the hotlinks would then be intimately associated with the
>CGM, so if you want to use the same CGM in different situations you need
>to make copies of the CGM and edit the Application Structures to suit.
>
>It is not at all obvious that this is the way to proceed.
If I'm understanding his comments correctly, Chris is concerned with the
"intimate" embedding of the link information in the CGM itself (which,
by the way, is apparently just what the SVF Specification defines).
Whether link information, application intelligence, etc, should be
internal to the graphical file or external is one of the main issues
amongst early adopters of Amd.2 (for example, the Intelligent Graphics
initiative of the Air Transport Association, ATA). There are two
schools of thought: the structures and links should be embedded; or, the
structures and links should be in an associated "overlay" file. I have
seen proposed scenarios for use of CGM and Amd.2 in both approaches.
At this point, I'm going to defer to those who are more actively
involved in WWW, or in IETMs in other communities (such as CALS and
ATA), to debate and craft the particular solution. However from my
current understanding of the WWW requirements, it still appears that CGM
has the needed attributes to serve as a basis for the SVF work.
>People said that in 1987 about CGM ;-) [yet another graphics file format?]
When work commenced on CGM in 1981, there was no suitable open standard
equivalent to CGM's place in the information pipeline (or Computer
Graphics Reference Model [CGRM], if you prefer). In 1987 there still
wasn't. In 1992 there still wasn't. There still isn't. At least not a
standard. Perhaps the latter attribute -- that the format be a stable,
open, international standard -- is not important.
>Also this is obfuscation; as Lofton is well aware, putting all "graphics"
>formats in one basket is hardly comparing like with like. Placing these as data
>capture metafiles on a Computer Graphics Reference Model, we see rather less
>than the stated "90" files in the Viewing Environment, where CGM sits. I can
>think of EPS, Adobe Illustrator EPS, Coreltrace EPS (think of these as
>application profiles using subsets of EPS to allow editing) and DXF. These all
>have different characteristics, even within the one environment. DXF provides
>features, for example, that EPS does not and vice verca.
Although this point is peripheral to the main issue of this discussion,
I'd like to one statement above. File formats at this level in the
information pipeline are not as rare as Chris implies. From the Table
of Contents and off the top of my head, I've come up with at least a
dozen more at roughly the same position in the reference model (GEM VDI,
Harvard Graphics CHT, HDF, IGES, Lotus PIC, Macintosh PICT, Microsoft
RTF, Microsoft WMF, NAPLPS, MET [Presentation Manager Metafile],
WordPerfect Graphics Metafile, MIF, etc.)
Most of these are probably unsuitable for functional reasons (which
perhaps is why Chris excluded them), or because they are proprietary and
not open standards (which characteristic is shared by EPS and DXF).
>So, my original comment still stands: A new format is fine if it does a
>different job (if not, it is not fine). Surely Lofton does not argue with this?
If in fact it is really a "different job". Clearly, the file format
definition follows from the requirements. As I indicated at the start,
most of the requirements which I have heard in this dialog, in the
"Moline paper," and other discussions are familiar. If this is the
case, then "SVF" will be isomorphic to a profile of one or more existing
formats.
>Reading the original propsal for moline, it seems that some thought has
>gone into the proposal which I assume Lofton read before commenting on
>it. I would therefore be interested to hear his specific objections to
>it, apart from the fact that it has not settled on CGM. Then again, it
>has not NOT settled on it either, as the paper makes clear.
I question the last statement. As you no doubt know, there is a draft
specification of SVF -- "Specification for the Simple Vector Format
(SVF)". The functionality, syntax, and encoding are already designed,
from scratch. A table in the paper presents comparative file sizes on a
couple of sample pictures for several file formats (DXF, HPGL, IGES,
raster format, and of course SVF). CGM is not mentioned at all.
The Moline paper does propose a reasonable way forward -- requirements
determination from all sectors of industry, "lively discussion", etc.,
leading to the design of a format. I'm a bit confused how this fits together
with the already-written and fairly complete SVF definition.
Finally, Chris asked for specific comments against the Moline paper.
I'll make a few about the paper and the SVF Specification itself.
1. The articulated goals of the "SVF", and the problem to be solved,
are sound. But they are not unique to the WWW, and in fact several
other application communities (e.g., ATA, CALS, ...) have been
addressing them for several years. Hence I repeat my assertion, SVF
likely can and should be a profile of an existing format.
2. The tradeoffs and criteria for the encoding of "SVF" functionality are
familiar: transmission speed? file size? format robustness in the face
of possible data loss? translation speed? These were faced during CGM
standardization. They can be mutually contradictory. Perhaps the
answer is not a single syntax to encode the functionality, but one or
more equivalent syntaxes (CGM defined three equivalent encodings, each
optimized for different criteria).
3. About the proposal to look at existing formats, and eliminate those
that are too simple "or too complex": the latter should not justify a
"from scratch" definition of a new format. Rather, a subset or
"Profile" of an existing format should be used, if all other factors are
acceptable with a candidate format. This has been commonly done with
IGES and CGM in various electronic documentation communities. As Chris
pointed out, it was done for EPS as well. Looking at the SVF
Specification document itself, the graphical functionality could easily
be a simple Profile of CGM. (The encoding doesn't match any of the
standard ones. If all of the standard ones are truely inadequate, for
well defined reasons, then one could consider defining a new encoding.)
3. I believe that the difficulty and magnitude of the Requirements
Determination phase of an SVF project have been vastly underestimated,
if this is truely to be a "consensus format" as implied in the Moline
paper. The difficulty of collecting requirements, refining them into a
concise and accurate set, and reaching consensus, is the principal
reason that ISO standards take so long to develop.
4. The current SVF Specification document does indeed define a simple
format. I believe that it is too simple to be very useful for the
claimed applications: "...GIS maps, scientific data, financial charts,
facility layouts, architectural and engineering designs, and more."
All of these areas were studied during the requirements work for CGM
Version 3, and have been studied by various application communities
since. SVF lacks basic facilities for effective data representation in
several areas, for example: line drawing attributes, filled area styles and
primitives, integrated vector/raster overlays, etc...
SVF is reminiscent of a profile definition that was once proposed in the
ODA (Office Document Architecture) community, but SVF is even simpler.
The ODA profile was critized by graphics experts (and ultimately
discontinued, I believe), in part because it was judged to be too simple
to be useful, even for simple technical illustrations, presentation
graphics, etc.
Here is where the Requirements Determination for WWW becomes critical.
How simple can the "SVF" be? What do you do when it lacks a rudimentary
capability, without which one cannot efficiently represent the graphic
(e.g., text direction, fill pattern, etc)? What is the "growth" path for
those SVF users who suddenly have a picture that they cannot efficiently
represent?
5. The SVF Specification does seem anticipate continued evolution of
the specification, and discusses enhancements so that "older viewers
[can] display most of a new file so the user could at least see some of
the file." First comment: why not simply choose a syntax which allows
new elements to be skipped, since the SVF version is embedded in each
file. Second comment: is this really useful? How often is a user going
to be interested in a picture known to be wrong or incomplete? Example:
the addition of a new "bold text" attribute causes an old viewer to drop
the "NOT" from the string: "The valve direction in the reactor coolant
line should NOT be reversed". Humor aside, this should not be a high
priority requirement.
6. The existing SVF Specification is not adequate for an implementation
of the format. It is surprising how much has to be written to make a
completely unambiguous and standalone specification, even of a simple
format (which is another reason that standards take so long). There
should be "standards quality" document, if SVF is truely to be an open
and accessible format.
There are many other technical and procedural points that could be
raised about the paper and the specification. Presumably these will
start to be flushed out, should the proposed open process of defining an
"SVF" for WWW take place.
Regards,
Lofton Henderson.