Concerns about DITA 2.0's multimedia elements

["Mr. Christopher Trenkamp" <christopher.trenkamp@siemens.com>]

Sorry for all the back-and-forth emails.  Hopefully all the issues should be worked out now.

We started looking at the DITA 2.0 specificationÂs media elements and believe thereÂs several flaws.

## Videos are not necessarily HTML

The DITA 2.0 multimedia elements were modeled on HTML5Âs video and audio tags.  DITA is format-agnostic (the only exception that I know of is the object tag).  Modelling these multimedia elements after HTML5 is inconsistent with how the schema is modeled.  Video and audio are not necessarily HTML only; PDFÂs are capable of playing videos.

## The video and media-sourceÂs @format attribute

The format attribute is being used as the MIME type of the video file.  The problems with this are:

* The MIME type isnÂt necessarily derived from the extension of the file.  Sometimes itÂs necessary to derive the MIME type from the file contents.
* I donÂt think authorÂs should be concerned with the MIME type of the video file.  This should be determined by the processor.  Alternatively, the web server can inject this information into the HTML.
* https://docs.oasis-open.org/dita/dita/v1.3/os/part3-all-inclusive/langRef/attributes/theformatattribute.html   
* The format attribute, if left unspecified, is derived from the href attribute.  By making the format attribute for videoÂs a MIME type of the video file, it CANNOT interoperate with the normal processing rules where the format is derived from the href.
* The format for the video element will be transformed into the type attribute in HTML5.  The type attribute in HTML5 is optional: https://html.spec.whatwg.org/multipage/embedded-content.html#attr-source-type 
* To top off the previous concerns, the end result is attaching an attribute that is not even required.  It was meant to save network traffic if the browser doesnÂt support the video type (which is a rarity anyway).

## The video elementÂs @href, @keyref, @poster, @posterkeyref, and @format attributes

The video element can specify both the video source and poster.  In typical processing on the xref and topicref elements, the format attribute can either be manually specified, or itÂs derived from the href.  The poster attribute does not have a format attribute to go with it.  This is inconsistent with the way the @href, @keyref, and @format attributeÂs behave on other elements.  Another problem is the @scope attribute is undefined for the @href and @poster attributes, so the processor doesnÂt have an easy way to tell if the resource is externally managed.

## How to fix these issues

Remove the @href, @keyref, @poster, @posterkeyref, and @format attributes from the video element.  The href and keyref were optional anyway and the same thing could be accomplished by putting them on a media-source element.  Introduce a poster element that can be specified as a child of the video element:

<video>
  <poster href="..." format="..." scope="..."/>
  <media-source href="..." keyref="..." format="..."/>
</video>

By putting the @href, @keyref, @format, @scope, etc. attributes into their own separate elements for the poster and media-source elements, this will allow processors to reuse the same functionality thatÂs already being used for xrefÂs and topicrefÂs and the same @href, @format, @keyref, etc. processing rules will apply.

If the processor must inject the MIME type into the sourceÂs type attribute, implementations can provide this mapping out-of-the-box, derived from media-sourceÂs format attribute:

* avi -> video/x-msvideo
* mp4 -> video/mp4
* mpeg -> video/mpeg
* ogv -> video/ogg
* webm -> video/webm
* etc.

This way, the format attribute can play by the same format attribute rules that apply for the xref and topicref elements, the MIME type can be derived from the format attribute, will remove the burden from authors for needing to specify the MIME type for the video, and still allow implementations to provide their own mappings for the MIME type.