Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix processing errors for data objects #3306

Merged
merged 2 commits into from May 14, 2019

Conversation

Projects
3 participants
@robander
Copy link
Member

commented May 13, 2019

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)

@robander robander force-pushed the robander:dataAttributeAsHtml branch from 84a8855 to 70973f1 May 13, 2019

Fix processing errors for data attributes
Signed-off-by: Robert D Anderson <robander@us.ibm.com>

@robander robander force-pushed the robander:dataAttributeAsHtml branch from 70973f1 to 6ce46fc May 13, 2019

Add datakeyref test
Signed-off-by: Robert D Anderson <robander@us.ibm.com>

@robander robander added this to In progress in 3.3.2 via automation May 13, 2019

@robander robander requested a review from jelovirt May 13, 2019

@robander robander moved this from In progress to Review in progress in 3.3.2 May 13, 2019

3.3.2 automation moved this from Review in progress to Reviewer approved May 14, 2019

@raducoravu
Copy link
Member

left a comment

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

This comment has been minimized.

Copy link
Member Author

commented May 14, 2019

@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.

@robander robander merged commit 807d3c1 into dita-ot:hotfix/3.3.2 May 14, 2019

3 checks passed

DCO DCO
Details
WIP Ready for review
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

3.3.2 automation moved this from Reviewer approved to Done May 14, 2019

@robander robander deleted the robander:dataAttributeAsHtml branch May 14, 2019

@robander robander added this to the 3.3.2 milestone May 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.