Internet media type: как нам реорганизовать рабкрин

Контентом (от англ. content = содержание/содержимое) называют информацию, приготовленную в доступном для восприятия человеком виде. Когда-то давно была разработана система классификации медиатипов контента (Internet Media Type): тексты (text), изображения (image), аудио (audio), видео (video) и прикладных программ (application). После медиатаксона через дробь записывают формат, например вот так: text/plain, image/jpeg, video/avi.

Со временем список таксонов добавили ещё model — статичные 3d-модели или сцены. Предлагалось также добавить по аналогии с video (= dynamic image + audio) добавить slideshow (= dynamic text + audio), и movement (= dynamic 3d + audio). Я бы добавил ещё таксон data для структурированных (напр. таблично или древовидно) данных: структурированные данные тоже можно рассматривать как контент, полезная информация статистического толка зачастую распространяется не в составе сопроводительного текстового документа, а сама по себе, и, стало быть, должна иметь отдельный таксон.

Далее можно заметить, что все указанные виды media характеризуют завершенные (finished, sealed, immutable) произведения. Нужен таксон для объектов "в работе" (work-in-progress, editable, mutable), для этого в IT-слэнге уже выработался довольно странный термин document, который логично использовать в качестве таксона. Далее было бы были таксоны более низкого уровня, позволяющие указывать медиатип с точностью до неважности конкретного формата, т.е. так что объекты одного медиатипа, но разных форматов, были большей частью взаимноконвертируемы.

Примеры:
text.rich/tex <-> text.rich/rtf <-> text.rich/html-restricted,
text.typeset/pdf <-> text.typeset/ps,
text.interactive/html <-> text.interactive/msxml.

Внутри image я вижу подтаксоны image.picture, image.photo, image.scan, image.medical.mri, ...
Внутри music — music.record и music.synth, внутри video — video.record и video.animation.
Внутри document: document.text.rich/docx, document.application-sources.java/jar, document.video.record, и так далее.

Форматы я бы разделил на readable и binary. Читабельные форматы начинать писать с буквы, а перед двоичными ставить например двоеточие:
– text.plain/plain, text.rich/rtf
– image.photo/:jpeg, image.picture/:png

Если формат контейнерный и может содержать много разного, в скобках нужно указывать схему того, что там находится или звёздочку, если схема не указана. Если у формата есть подформат (кодек), он (или список таковых) указывается в квадратных скобках.
- text.rich/:zip(odf)
- text.rich/xml(xhtml)
- data/xml(*)
- data.stats/xml(//stats.myapp.com)
- video.movie/:avi[xvid, mp3]

Наконец, следовало бы ввести форму записи для типов служебной информации (предназначенной для человеческого потребления), у которой есть формат, но нет медиатайпа. Естественный выбор на мой взгляд падает на прочерк в качестве медиатипа:
-/xml(//someapp.com/license/1.0)
-/:kryo(//someapp.com/measurement-persistence-data/1.0)

Система должна быть расширяемой, но в то же время допускать краткие имена. В качестве названий форматов и схем поэтому предлагается использовать либо (без всякой регистрации) url, по которому находится определение формата/схемы, либо (после регистрации оного) краткое имя:
– text.interactive/xml(xhtml) = text.interactive/xml(//w3c.org/xhtml/1.1)
– text.rich/:zip(odf) = text.rich/:zip(//oasis.org/opendocument.text)

Если бы было сделано так, никогда не вырасли бы монстры наподобие
“application/vnd.openxmlformats-officedocument.wordprocessingml.document”.