[Top] [All Lists]

Re: Different approach to defining encodings

1991-11-08 07:01:49
Excerpts from mail: 7-Nov-91 Re: Different approach to d.. Neil
Katin(_at_)Eng(_dot_)Sun(_dot_)COM (1658)

Your fear seems to be that this will lower interoperability.  I
agree that unbridled usage of random encodings would be a bad
thing.  But how about if the new addition of a body part subtype
had to describe those transformations that it would support?  Subtypes
already have to describe the attributes that they support, and which
are optional and mandatory.  This would simply be another requirement
for defining a new subtype; since all implementers of the subtype
would have to understand the proposed transformations, interoperability
would be preserved.

I think that the requirement of a new subtype definition is likely to
lower the number of ways people do things overall.  For example, if we
define audio/g.721, people will know what it means.  If we define
"audio" and let people do something like "transformations = g.721", then
we also invite things like "audio; tranformations=g.721; compress;
uuencode".  In general, more generalized syntax invites more varied
usages, which is exactly the opposite of what I think we want to promote
here.  -- Nathaniel