[Top] [All Lists]

Re: text/*

1998-10-30 17:19:55

Sorry, I thought you had made up an example, I didn't realize this was a real type.

There's an interesting case, but it's a VERY SPECIAL case. It's audio that can actually be read by humans directly (well, not *this* particular human, but... :-)).

In that case, I can understand your interpretation of 2046 (though I think the registration is wrong and should be audio/ and that 2046 should be clarified). However, I really wouldn't build a theory around such oddball cases. I would especially worry about using words like "encoding" when talking about them.

Much data that is textual is not intended to be directly read by users and does not belong in text/* by virtue of its textual form. May people do not understand this, and believe that any representation that consists of short lines of ascii characters means the type belongs in text/*. Not so.

...but that the 'Media' frosting on top can be anything at all:


Only in the oddball case where you have a media type that can actually be directly read in the raw by an ordinary user. I assert that the set of such types is very small indeed.

...whereas 'audio', 'image' and 'video' types describe the top layer of


Ah, but here you can have a textual layer, too:


You just have to say in the registration of audio/hypothetical-thing that it takes a charset parameter (and presumably has other textual behaviors like newline canonicalization). For example, I might register audio/yes-and-no, where I describe a sound by means of the words yes and no. I could then say (forgive me on the details):

ct: audio/yes-and-no; charset=us-ascii; language=fr

oui oui oui non non oui

That's textual, but it sure doesn't belong in text/*.

<Prev in Thread] Current Thread [Next in Thread>