- From: Garret Wilson <garret@globalmentor.com>
- Date: Fri, 21 Dec 2007 06:59:15 -0800
- To: Graham Klyne <GK@ninebynine.org>
- CC: Eric Prud'hommeaux <eric@w3.org>, ietf-types@iana.org, "Sean B. Palmer" <sean@miscoranda.com>, Tim Berners-Lee <timbl@w3.org>, "Daniel W. Connolly" <connolly@w3.org>, Dave Beckett <dave@dajobe.org>, Lee Feigenbaum <lee@thefigtrees.net>, Dan Brickley <danbri@danbri.org>, www-archive@w3.org
Garret Wilson wrote: > I don't have a strong opinion here, but I will point out that RFC 2046 > talks about the category being "the highest level" division and that > it is "useful". To me, it is useful at a high level to note that the > content types discussed here have the following characteristics: > > * The content bytes are interpreted as text characters (i.e. Unicode > code points); ignoring encoding, no bytes are interpreted as anything > other than text characters. (These text characters may later be > subject to some meta-interpretation---e.g. delimiters---but they are > first interpreted as text characters.) > > * These content types can always be edited in a text editor. > > * Abstract values, such as numbers, are represented by their text > lexical forms, not by some non-text encoding. Oh, and I forgot to add (perhaps most importantly): * I can allow CVS or Subversion or some other version control system manage the file as text, not binary, even able to do diffs and merges based upon end-of-line characters. To me, that's where the power of the text/* types come in---we can do processing on them as text. Garret
Received on Friday, 21 December 2007 15:00:56 UTC