John C Klensin writes:
My--frightfully dangerous--inference....
text-plus/SMGL and probably (like Ned, I'm still a bit skeptical)
text-plus/Postscript
are valid combinations. So are
application/SGML and application/Postscript
And the difference is a matter of use and intent, not of whether "SGML"
is inherently "text-plus" or "application". It seems to me that the
intent is important here, and this provides a way to express that
intent, i.e., that it is reasonable to register both pairs of
combinations, with appropriate guidance about use.
I agree with this completely, as long as we limit the number of types something
can appear under. I want to avoid Mark's silly states. PostScript can appear
under text-plus, image (maybe not), or application. I don't see it appearing
under text or voice or binary.
The definer of a subtype must then decide what types it can appear under, with
a leaning towards limiting this number and hence avoiding silly states.
The concept Ned has in mind when he discusses the kind or use of SGML
(or, as Bill correctly points out, the family of DTDs) that he sees as
text-plus seems pretty clear to me. And we can all make examples that
would be "application" at best. Similar remarks probably apply to many
of the other obvious text-plus categories, as well as to sliding some
Postscript texts into that category.
Actually, I think the applications of this principle are pretty limited.
The number of composite formats is actually rather limited (largely due to the
difficulty of defining same and getting people to use them). The number of
single-use formats is huge -- look at how many ways there are to encode
image data, and image data only.
If the concept and distinctions are to be useful, then one must hope
that the originating user or sending system know, and hope that they
will accurately reflect whatever we believe. If that is not possible,
then we may have too many top-level types and should look at
"displayable on character device", "displayable on bitmapped device",
and maybe a few categories of "other"/"not intended to be displayed" and
be done with it.
In a highly integrated environment you'd know this sort of stuff. In a
less integrated environment you wouldn't. And this can be a problem. Letting
users describe their document (only in terms of letting them pick from a list
of possibly legal values, mind you) would be one approach. For automated
servers, I'd hope that it would be possible for the installer to tag things
with what they are (the problems of automatic servers are certainly not
restricted to the selection of content-type!).
Maybe that is all we should expect, and the putative problem
here does not need solving.
Well said. I agree with this too.
Ned