Neil Katin writes:
There is no such format. The correct format name is almost certainly
something like Image/FrameMaker.
Just because an image contains text does not make it a text or text-plus
format.
I was going to let this conversation slide off because of diminishing
returns, but Mark's comment strikes right at my "big fear" of combining
type and subtype into one field: the arguments about where to put stuff.
Framemaker (for those who are not familiar with it) is a text processing
package, roughly akin to Microsoft Word, Interleaf, and perhaps a bit
of Slate.
Frame can write its documents out in several formats; one format is
SGML-like, is encoded using ascii, and is called Maker Interchange Format.
Another is an "internal" format that represents the same information
but is quicker to parse and more compact on disk. It is not human
readable and fits into our "binary" category with respect to transport
encoding because it does not have line length limitations.
My question, then, would be, "is it useful to display/revise Framemaker
material in its SGML-like format?". I suspect that the answer to this is "no".
This does not match PostScript, which is explicitly thought of as a revisable
document format (I don't agree, but this is what Adobe claims for PostScript,
not me). Thus, PostScript is grouped under text-plus, while Framemaker probably
should be grouped under image.
Take ODA as another example. ODA is a revisable document format, but an
ASCII-ified version of it is not well-defined, nor is such a version intended
to be revisable. You need a special program to display ODA and revise it. Thus
I think it belongs under image. However, the final decision on this should be
left up to the ODA group.
For that matter, I would not mind that much if we decided that Adobe is full of
it and moved PostScript over to the image type.
While these two formats should have different subtypes, it seems clear
to me that they should have the same type, because they represent the
same information.
I agree, they should have the same type.
Mark has a differerent intuition.
I don't think so. Mark simply wanted both of them grouped under image.
My problem is not that we disagree, but that the types are so loosely
defined that different vendors will have to face choices like this,
and these vendors will pick different alternatives. I'm afraid of the
operational problems that this will lead to.
This is definitely a potential problem, but you cannot solve it by fiddling
around with how you express type and subtype information. The solution is to
provide a registration service, with clear directions on how to group things.
This is the only effective solution to this problem that I can see.
Once the next draft of the RFC is out please contribute whatever text you think
is necessary to tighten up the type definitions to the point where you think a
vendor will be able to place various objects without a lot of trouble. The
problem of two vendors doing different things with the same subtype does not
arise if the registry is properly coordinated, and cannot be avoided if the
registry is not properly coordinated.
Ned