Fix processing errors for data objects

[robander]

Signed-off-by: Robert D Anderson robander@us.ibm.com

Description

Fixes two issues with processing for object elements:

• With local files referenced by object/@data, we set a default of format="html" in our job configuration. Out of the box DITA-OT 3.3.1 treats anything referenced with format="html" as lightweight DITA, and tries to parse the file, so we automatically parse (and presumably fail) on any local media object referenced by object/@data. To fix this, I've changed the default format for media objects from html to nondita, which still copies it to the output directory but avoids trying to parse it for any HTML processing. Tested with <object data="local-video.mp4"/> which results in failures from html2dita.xsl
• With absolute external URLs, we treat the object referenced by @data as a local file. The way I see to work around this is by moving the value to a key and using @datakeyref but that should not be necessary - we should recognize that the URL is absolute and avoid treating it as a local (html) file. If the org.lwdita plugin is disabled so that we do not try and parse the file, it still fails later when we try to copy this as a local HTML file. To correct this, I've added a test for attrValue.isAbsolute() which avoids further processing of the @data target when it is an absolute reference. Tested with the following, which also fails in html2dita.xsl: <object data="https://www.youtube.com/embed/BaUjhYw8IK4">

Motivation and Context

Ran in to both of these failures with DITA-OT 3.3.1 and object elements.

How Has This Been Tested?

Tested with each of the values above. Zip file:
object.zip

Type of Changes

• Bug fix (non-breaking change which fixes an issue)

[raducoravu]

Looks good, so the video gets copied to the output folder when you have the format "nondita", right? I had a similar patch on my side considering the data href as an "image" format instead of "html", probably because at that time only the "image" and "html" formats were copied to the output folder.
This might fix all these issues:
#2861
#2722
#2947

[robander]

@raducoravu That sounds right, yes. In my local test with the attached sample files, my local video (actually a text file with .mp4 extension) is copied to the output for HTML5. Thanks for digging through the issues tracker for all those related issues.