Data exchange formats (longish)

From: André Dolenc (Helsinki University of Technology)
To: RP-ML
Date: Thursday, September 29, 1994
Subject: Data exchange formats (longish)

I feel compeled to STEP into this discussion.

Although the STL file format has its drawbacks, many of the problems experienced
by users are related to poorly designed and implemented software tools.
Even a good data exchange format such as CFL would not eliminate these problems.

Nowadays, all efforts in the direction of finding a substitute for the
representation of facetted models should be done within STEP. There are two
major reasons for this:

1. The industry already has a de facto standard (STL). A new format must
   add a lot of value to justify the effort. Simply proposing a format with
   no redundancy is not good enough.

2. Formats such as STL, CFL, WAVEFRONT, SGO, etc, result in LOSS OF INFORMATION.
   Consequently, it is much more difficult, or impossible, to generate optimal
   process plans. Within the STEP framework, one can use product data for this
   purpose. This, together with features like non-redundancy, would justify
   the switch to a new format.

This forum could, instead, collect the REQUIREMENTS for a new format, instead
attempting to define one. This alone is one of the most important STEPs in
defining a neutral data exchange format. And, believe me, it is not easy.

For instance, most of the discussions assume that the data exchange flows in
one direction, from the sender to the receiver. What if the receiver would
like to tell the sender the problems identified in the model, and how they were
corrected, *if* they were corrected. We fall in the silly situation of using
the good old IGES/VDAFS/SET standards that have been around for years, and
which everyone is trying to get rid of.

Concerning data exchange formats, the MAJOR BOTTLENECK is the absence of
an OPEN FORMAT for sliced models. As far as I know, the only serious effort
being carried out in this direction is in Europe. Here, a data exchange format
called CLI is being developed within the BRITE/EURAM program by three projects.
(Sorry Gill, the FRAMES in CFL are not good enough...)
In addition, a data exchange format called LEAF may be implemented for
research purposes, and placed in the public-domain (following similar lines as
EDIF).

The specs of CLI are available on the Web in Cranfield. We will soon have them
on-line here as well.

-------------
PS: Here at HUT we have been developing software for RPT since 1989. One tool
is capable of generating both STL and CFL files, so we had the opportunity
to compare both concerning storage requirements and functionality. The results
of this comparison can be found in the Appendix of my PhD thesis, and they will
be available on the Web RSN.

Regards,
Andre'