DIDL: Передача структурированных бинарных данных

Мы уже знакомили читателей с различными направлениями использования XML. Тем
не менее, несмотря на все многообразие этих областей применения, все они
подразумевали описание с помощью XML только текстовых документов. В данной
статье мы предлагаем читателям ознакомиться с еще одной возможностью XML -
описанием структурированных бинарных данных. Уже традиционно для этой рубрики
материал содержит пример реализации, снабженный фрагментами кода.

Обзор

В этой статье подробно рассматриваются причины, вызвавшие необходимость разработки стандарта передачи бинарных данных и описывается схема, предназначенная для решения описанных проблем. Таким образом, можно будет увидеть, как такая схема эффективно разделяет понятия элемента контента и отдельных файлов. В завершение статьи приводится XML-словарь Digital Item Declaration Language (Языка объявления цифровых элементов, DIDL), недавно выпущенный первый рабочий проект (first working draft) от ISO/MPEG, который, после завершения, обеспечит стандартные средства упаковки структурированных бинарных данных.

Необходимость стандарта для описания необработанного контента (raw content description standard)

Популярные сегодня Интернет-приложения в массе своей не обладают достаточными возможностями для переноса необработанного исходного контента. Контент web-страницы, например, может определяться как набор отдельных ресурсов - растровых и JPEG-изображений, текстовых блоков, и т.д., - агрегируемых в неком предопределенном формате. Компоненты web-страницы могут иметь атрибуты и отношения, которые, не являясь явно частью окончательной наглядной формы, могут тем не менее быть критичными для генерирования отображаемого результата. Информация, сопровождающая JPEG-изображение, например, может использоваться в процессе создания подписей к фотографиям. Информация об отношениях в группе изображений может использоваться для определения местонахождения изображений на странице. Если web-страница генерируется скриптом, информация о размерах различных изображений может применяться для принятия решения о том, какое изображение загружать в первую очередь.

Стандартный способ описания необработанного контента как структурированного набора ресурсов подразумевает: (1) стандартный и гибкий формат метаданных; (2) стандартный способ агрегации множества ресурсов различных типов; и (3) стандартный способ выражения структурных отношений в рамках набора ресурсов. Увязка стандартных по форме метаданных с данным файлом позволяет напрямую связывать семантические описания и характерный для приложения режим работы с содержащимся в файле контентом. Сегодня незапланированные (ad hoc) схемы метаданных используются в ряде Интернет-приложений. Например, в равноправных сетях длинные имена файлов часто используются в качестве приблизительной замены (crude substitutes) семантических описаний содержимого файлов. Заголовки файлов также имеют применение; однако форматы заголовков разработаны таким образом, чтобы документировать в основном только техническое, а не семантическое содержимое конкретного файла. И вместо широкого распространенного использования заголовков, структурированные бинарные данные в форме отдельного файла не могут сегодня предоставляться никаким клиентам или платформам без существенного вмешательства пользователя. Вмешательство обычно заключается в направлении броузера на некий web-сайт, выборе некоторого URI ресурса для загрузки или организации потока (streaming), и, если это файл, последующего направления загружаемого материала в некую директорию. Визуализация или просмотр контента во многих случаях включает в себя возможность клиентской системы информировать пользователя о том, что необходимый plug-in или плеер либо не установлен, либо не обновлен и предлагать поискать необходимое средство визуализации или просмотра в Интернет.

Самым большим ограничением схем форматирования мультимедийных заголовков и файлов является их наследственная неспособность описывать многокомпонентные наборы. XHTML, например, при нормальной работе в качестве формата вывода для многокомпонентного контента, совершенно не подходит для описания необработанных цифровых компонент и их отношений. Стандартный способ агрегации множества цифровых компонент требуется просто потому, что web-страницы и другие типы отображаемых объектов состоят из множества элементов.

И наконец, для связки таких объектов, как изображения, с соответствующим им текстом требуется способность формально описывать отношения ("…эта компонента идет вместе с той компонентой, а эта содержит вот ту компоненту и т.д."). Ее можно использовать и для описания компонентной структуры, трудной для описания с помощью текстовых метаданных.

Подходящий случай: семейный альбом в киберпространстве

Рассмотрим семейный цифровой альбом. Альбом может быть составлен из цифровых фотографий, видеозаписей и текстовых документов. Проектировщику альбома необходим способ непосредственного представления индивидуальных цифровых компонент как отдельной сущности, чтобы снабдить компоненты примечаниями (аннотациями) и определить отношения между ними ("эта видеозапись и эти фотографии были сделаны Бобом и Эмили во время их недавней поездки во Флориду"). Наличие формальной схемы аннотирования позволит другим членам семьи добавлять новые аннотации, не нарушая исходного контента ("озаглавьте эту фотографию"). Это также позволит устанавливать связи (intermedia anchor points), что было бы особенно полезно в случае длинных видеозаписей, содержащих разнородные фрагменты ("этот фрагмент - о том, как Боб выпал из лодки"). Вся техническая информация, необходимая для зрителя-клиента, как то: формат средства представления каждой компоненты, размеры бинарных элементов и т.д., должны были бы быть включены так явно, как только возможно. Поскольку набор скорее всего будет просматриваться родственниками и друзьями на всевозможных компьютерных платформах, возможность прозрачного для пользователя способа пакетирования множества версий формата одного и того же контента не менее важна для минимизации вмешательства пользователя в процесс доступа к альбому ("Мне нужна версия QuickTime этого видео").

Другой альбом задает другие требования к пакетированию. В этом случае для связи с определенным исходным компонентом контент требует шифрования, идентификации или формального заявления о правах. В примере альбома кто-то может пожелать связать некую фотографию или какой-то другой компонент с формальным заявлением об авторстве. Если одна из картинок является производной от какой-то другой, полезно определить ее как копию, а исходное фото - как первоисточник. С точки зрения долговременного использования и хранения ничто не повлияло бы на обслуживания исходного материала как нетронутого и восстановимого.

Возможно, самой существенной причиной использования цифрового пакетирования являются различия между описанием альбома и ресурсами. Хотя может потребоваться действительно включить небольшие ресурсы (как, например, пиктограммки изображений) в саму декларацию альбома, большинство ресурсов включаются в пакет с помощью ссылок. В идеале, в цифровом альбоме каждый компонент сопровождался бы не только, подробным описанием средства его представления, но и URI для получения соответствующего платформе plug-in броузера/плеера, способного визуализировать этот тип средств представления. Это было бы исключительно важным свойством в проектировании альбома для большой семьи, в котором различные компоненты набора распределены по различным фиксированным, но географически удаленным архивам. Высоко-компактная природа декларации позволяла бы быстро передавать и редактировать его, не перемещая весь набор. Содержимое альбома, таким образом, определялось бы в большей степени описанием пакета, а не самими его компонентами.

Метаданные, связанные с каждым компонентом, и отношения компонентов также позволяли бы зрителю выполнять поиск конкретного компонента по декларации пакета (возможно, с использованием регулярных выражений) и, таким образом, загружать или просматривать только поднабор материалов, на который указывает данный пакет ("Извлечь только фотографии Боба и Эмили за то время, пока они жили в Огайо").

И наконец, поскольку данная декларация пакета описывала бы только структурные и семантические отношения компонент в наборе альбома абсолютно независимо от отображения, форматирование визуализируемого вывода передавалось бы программному приложению или большой таблице, или средству трансформации. Это позволяло бы генерировать из одной и той же декларации пакета множество альбомов, отформатированных различными способами.

Язык объявления цифровых элементов - MPEG-21 Digital Item Declaration Language. При разработке своего нового стандарта MPEG-21 ISO MPEG нуждался в создании мультимедийной среды, способной поддерживать предоставление и использование всех типов контента различными категориями пользователей из множества прикладных доменов. Не так давно в этом году группа Multimedia Description Schemes (MDS) Group в составе MPEG выпустила первый рабочий проект словаря XML, язык MPEG-2 Digital Item Declaration Language (DIDL). Общей целью DIDL названо установление унифицированного и гибкого мультимедийного выделения данных и схемы взаимодействия объявления цифровых элементов. В рамках среды MPEG-21 Digital Item (Цифровой элемент) определен как структурированный цифровой объект со стандартным представлением, идентификацией и описанием. Сущность этого Digital Item также является базовой единицей распространения и транзакций в этой среде. DIDL основан на абстрактной модели, называемой Digital Item Declaration Model (Модель объявления цифрового элемента). Основные понятия этой модели приведены ниже. Многие элементы этой модели имеют прямую связь с элементами DIDL XML.

Resource (Ресурс)
Ресурс - это индивидуально идентифицируемый объект, например - видео- или аудиоклип, изображение или текстовый объект. Ресурс может быть и физическим объектом. Местонахождение всех ресурсов должно однозначно определяться с помощью конкретного адреса.

Component (Компонент)
Компонент - это привязка ресурса ко всем соответствующим ему описателям (см. ниже). Эти описатели представляют собой биты информации, связанные со всем или частью конкретного ресурса. Описатели компонент обычно содержат контрольную или структурную информацию о ресурсе (такую, как скорость передачи в битах, начальные точки или информацию по шифрованию), но в целом не содержат информации, описывающей "контент".

Descriptor (Дескриптор, средство описания)
Дескриптор связывает информацию с вложенным элементом. Эта информация может быть компонентом (например, пиктограммкой изображения) или фрагментом текста.

Statement (Объявление)
Объявление - это буквенная текстовая величина, содержащая информацию, но не содержащая данные. Примеры возможных объявлений включают информацию по описанию, контролю, отслеживанию проверок или идентификации.

Fragment (Фрагмент)
Фрагмент однозначно определяет специфическую точку или область в рамках ресурса (например, некую последовательность кадров длинной видеозаписи).

Anchor (Анкер)
Анкер привязывает дескрипторы к фрагменту, соответствующему некому конкретному местоположению или области в рамках ресурса.

Predicate (Предикат)
Предикат - это однозначно идентифицируемое объявление, способное быть истинным, ложным или неопределенным.

Selection (Выборка)
Выборка описывает конкретное решение, влияющее на одно или более условий где-либо в рамках элемента. Если выборка сделана, ее предикат принимает значение истинности, если выборка не сделана, ее предикат имеет значение "ложь", и если выборка остается неопределенной, предикат также остается неопределенным.

Condition (Условие)
Условие описывает вложенный элемент как дополнительный и связывает его с выборкой (выборками), влияющими на его включение.

Choice (Выбор)
Выбор описывает набор связанных между собой выборок, способных влиять на конфигурацию элемента. Выборки, входящие в выбор, имеют либо исключающий характер (выбрать только один), либо включительный (выбрать любое число, включая все и ни одного).

Item (Элемент)
Элемент - это группировка подэлементов или компонент, связанных с соответствующими дескрипторами. Элементы могут содержать результаты выборов, позволяющие настраивать или конфигурировать элементы. Элементы сами по себе могут быть условными. Если элемент не содержит подэлементов, он может считаться сущностью. Если он содержит подэлементы, он считается составным.

Container (Контейнер)
Контейнер - это потенциально иерархическая структура, позволяющая осуществлять группировку элементов. Эти группировки элементов могут использоваться для формирования логических пакетов (для перемещения или обмена) или логических хранилищ (для организации).

Assertion (Утверждение)
Утверждение определяет полностью или частично сконфигурированное состояние выбора с помощью утверждения значений истинности, ложности или неопределенности для ряда предикатов, связанных с выборками этого выбора.

Пример: пакетированный с помощью DIDL семейный альбом

DIDL-документы - это XML 1.0 documents. Специфической целью проектирования набора элементов была максимально возможная гибкость и обобщенность, создающая основу для создания построения функциональности. Это делалось для обеспечения возможности использования его в качестве ключевой базы при создании высокоуровневых элементов, возможно хранящихся в других пространствах имен XML. Актуальные XML-элементы, образующие DIDL, таковы:

<DIDL>
<DECLARATIONS>
<CONTAINER>
<ITEM>
<COMPONENT>
<RESOURCE>
<DESCRIPTOR>
<STATEMENT>
<ANCHOR>
<CHOICE>
<SELECTION>
<CONDITION>
<OVERRIDE>
<REFERENCE>
<ANNOTATION>
<ASSERTION>

<DIDL>
 <CONTAINER>
    <DESCRIPTOR>
      <STATEMENT TYPE="text/plain">Jones family 
        on-line photo albums</STATEMENT>
    </DESCRIPTOR>
    <ITEM>
      <DESCRIPTOR>
        <STATEMENT TYPE="text/plain">Album #1: 
           The Kids</STATEMENT>
      </DESCRIPTOR>
      <ITEM>
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">
            Johnny Williams' first day at Westside High school.  
            His friends Bruce and Walter are also pictured.
          </STATEMENT>
        </DESCRIPTOR>
          <COMPONENT>
            <RESOURCE REF="Pjn1.jpg" TYPE="image/jpg" />
          </COMPONENT>
      </ITEM>
      <ITEM>
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">
              Jane's first day at Jefferson elementary school, 
              accompanied by her Dad, Robert Williams
           </STATEMENT>
        </DESCRIPTOR>
          <COMPONENT>
            <RESOURCE REF="Pja1.bmp" TYPE="image/bmp" />
          </COMPONENT>
    </ITEM>
    <ITEM>
      <DESCRIPTOR>
        <STATEMENT TYPE="text/plain">Album #2: Bob & 
           Emily</STATEMENT>
      </DESCRIPTOR>
      <ITEM>
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">
            Bob catches a big one at Blue Lake.
          </STATEMENT>
        </DESCRIPTOR>
          <COMPONENT>
            <RESOURCE REF="Bp1.jpg" TYPE="image/jpg" />
          </COMPONENT>
      </ITEM>
      <ITEM>
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">
              Emily around the campfire at Blue Lake.
           </STATEMENT>
        </DESCRIPTOR>
          <COMPONENT>
            <RESOURCE REF="Ep1.bmp" TYPE="image/bmp" />
          </COMPONENT>
      </ITEM>
    </ITEM>
  </CONTAINER>
</DIDL>

Второй фрагмент примера иллюстрирует, как могут использоваться элементы DIDL CHOICE и SELECTION для пакетирования предоставляемых ресурсов (в данному случае - музыкального файла), имеющихся в более чем одном формате медиа-файлов.

<DIDL>
  <ITEM>
    <CHOICE MIN_SELECTIONS="1" MAX_SELECTIONS="1">
      <DESCRIPTOR>
        <STATEMENT TYPE="text/plain">What format would 
           you prefer?</STATEMENT>
      </DESCRIPTOR>
      <SELECTION SELECT_ID="MP3_FORMAT">
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">I want MP3</STATEMENT>
        </DESCRIPTOR>
      </SELECTION>
      <SELECTION SELECT_ID="WMA_FORMAT">
        <DESCRIPTOR>
          <STATEMENT TYPE="text/plain">I want WMA</STATEMENT>
        </DESCRIPTOR>
      </SELECTION>
    </CHOICE>
    <COMPONENT>
      <CONDITION REQUIRE="MP3_FORMAT"/>
      <RESOURCE REF="clip.mp3" TYPE="audio/mp3"/>
    </COMPONENT>
    <COMPONENT>
      <CONDITION REQUIRE="WMA_FORMAT"/>
      <RESOURCE REF="clip.wma" TYPE="audio/wma"/>
    </COMPONENT>
  </ITEM>
</DIDL>

В третьем фрагменте примера продемонстрировано, как можно сконструировать упаковщик DIDL вокруг внутреннего, основанного на XML типа дескриптора. В этом случае при создании схемы формирования заголовков фотографий применяется внешняя схема. Элементы в отдельной внешней схеме содержат префикс "xzs". Обозначение MIME типа принимает значение "text/xml".

<DIDL>           
  <CONTAINER>
    <ITEM ID="NIAGRA_PHOTO1">    
      <COMPONENT>
        <DESCRIPTOR>
          <STATEMENT TYPE="text/xml">
            <xzs:SpecialCaption>
              Bob and Mary Jones standing at Niagra Falls
            </xzs:Caption>
          </STATEMENT>
       </DESCRIPTOR>
       <DESCRIPTOR>
         <STATEMENT TYPE="text/xml"> 
           <xzs:CreatorName="Bill Smith"/>
         </STATEMENT>
       </DESCRIPTOR>
       <DESCRIPTOR>
        <STATEMENT TYPE="text/xml"> 
          <xzs:Copyright>
            1998 Bill Smith Photo Enterprises
         </xzs:Copyright>
        </STATEMENT>
       </DESCRIPTOR>
       <RESOURCE REF="pict1.jpg" TYPE="image/jpg"/>
     </COMPONENT>        
   </ITEM>
  </CONTAINER>   
</DIDL>

Вывод

Участвующие в Интернет-транзакциях структурированные бинарные данные - уже реальность, однако недостаток стандартов существенно затрудняет получение и передачу контента пользователями, не имеющими достаточных технических навыков. Контент, участвующий в транзакциях, обычно не имеет возможности взаимодействия с различными платформами и все еще до некоторой степени связан с парадигмой директории/файла, существенно ограничивающей его гибкость. MPEG-21 Digital Item Declaration Language направлен на решение этой и связанных с нею проблем путем обеспечения относительно простого стандартного метода описания сложных многокомпонентных наборов источников контента.

Ссылки

• Последний рабочий проект MPEG-21 Digital Item Declaration
• Главная страница MPEG

Автор: Марк Уолкер (Mark Walker), Тодд Шварц (Todd Schwartz), Вон Айверсон (Vaughn Iverson)