Mark,
Thanks for the comments.
It appears to place requirements on models (section 2, which supposedly only
discusses the need, section 4, and Appendix I) which seem to severely and
unnecessarily restrict the scope of this new primary type.
model was intensionally restricted. Everything "can" be a model
just like everything "can" be an application.
Section 2.2 goes to a great deal of effort to argue the benefits of "model"
over the multimedia types. It seemed rather pompous to me, as if "throw
enough bullshit to confuse the reader and he'll be shocked into a confused
silence." Yet expends only a single paragraph on the important issue, which
is "why not use application?"
Application is a catch all. Everything can be lumped into application.
Model's intent is to group together all 3D (4D) data types with an
emphysis on spatial/temporal. Model specifically does not include
mathematical constructs.
Section 6 makes some (to me) unsupported assumptions -- "the data files are
``read-only'' and do not contain file system modifiers or batch/macro
commands." The existing proposed model subtypes may not do this, but this may
not be the case in general. It also describes a serious security risk --
"internal structure of the data files may direct agents to access additional
data from the network" which was glossed over.
We'll improve the verbage to describe exactly what "additional data"
is being accessed. The intent is that the additional data is
static and isn't crutial by itself to the understanding of the model.
Section 5 and Section 6 got swapped. This should be fixed.
Oops...
Items 6-7 are
just plain wrong, IMHO; if they are excluded from the scope of model the day
will come when we have to create yet another new type to put these in.
This has already been discussed. We'll need a more substantive debate
to make a decision. It's a debate about type vs. content. Yes, the
mathematicians will want some kind of type, as do the chemists, astrophysists,
etc. I'm told that a generic subtype is in the works which associatively
collects information. i.e. a multipart with information linking the
parts.
Appendix III should be moved to the main body as "initial models". The
qualifiers as filename extensions should be changed to a new parameter, e.g.
The subtypes will be registered separately. They are mentioned here
for reference only. We did this as a result of the previous 10 weeks
of discussions when they were listed up in the main body.
Appendix IV talks about how images and video aren't models, but the first
three examples are GIF or MPEG data. This does not support the contentsion
made earlier.
The first three are GIF and MPEG data for those who like to look at
GIF and MPEG representations of model data. The other three pointers
(on page 15) point to model data objects. You can look at the IGES
data, the VRML data, or the MESH data with your favorite IGES, VRML,
or MESH viewer. See the WWW Viewer Test Page for pointers.
--
+----------------------------------------------------+
|Scott D. Nelson B131 Rm2074 3-1250 |
|Lawrence Livermore National Laboratory |
|7000 East Ave., L-153 Livermore CA 94550 |
|email: nelson18(_at_)llnl(_dot_)gov http://www-dsed.llnl.gov/ |
+----------------------------------------------------+