RE: Dita 2.0 multimedia elements flaws

[kris eberleinconsulting.com <kris@eberleinconsulting.com>]

 

Dawn, thanks for forwarding this.

 

Folks at Siemens, please send this feedback to the dita-comment list, which is the mechanism for folks who are not members of the DITA Technical Committee to communicate with the DITA Technical Committee. You can find more information about the dita-comment list at https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=dita

 

When we receive your feedback through the dita-comment list, I’ll add it to the agenda for our next DITA TC meeting.

 

Best,

Kris

 

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Owner, Eberlein Consulting LLC
kris@eberleinconsulting.com

Skype: kriseberlein; voice: +1 (919) 622-1501

 

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Dawn Stevens
Sent: Wednesday, June 29, 2022 6:18 PM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] FW: Dita 2.0 multimedia elements flaws

 

Hi all,

Please see concerns sent to me from Siemens regarding the multimedia domain.

 

I did take this opportunity to remind them of my email from a couple of weeks ago inviting them to directly participate on the committee.

 

Dawn

 

From: Trenkamp, Chris <christopher.trenkamp@siemens.com>
Date: Wednesday, June 29, 2022 at 10:11 AM
To: Atkinson, Tracey <tracey.atkinson@siemens.com>, Petersman, Melanie <melanie.petersman@siemens.com>
Cc: Dawn Stevens <dawn.stevens@Comtech-serv.com>
Subject: RE: Dita 2.0 multimedia elements flaws

Dawn, we have some concerns about the DITA 2.0 multimedia elements.  Can this be brought up in your next TC meeting?

 

From: Trenkamp, Chris (DI SW T&I TO DO CTD)
Sent: Tuesday, June 28, 2022 2:55 PM
To: Atkinson, Tracey (DI SW T&I TO DO CTD) <tracey.atkinson@siemens.com>; Petersman, Melanie (DI SW T&I TO DO CTD) <melanie.petersman@siemens.com>
Subject: Dita 2.0 multimedia elements flaws

 

We started looking at the DITA 2.0 specification’s media domain and believe there’s several flaws.  Have the following issues been raised in the TC meetings?

 

Videos are not necessarily HTML

 

The DITA 2.0 multimedia elements were modelled 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 the rest of the other domain objects.  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 this imposes is:

 

• 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="" keyref=”…” format=”…”/>

  <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.  The same href, format, keyref 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 users to provide their own mappings for the MIME type.