• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Preprocessing transform doesn't resolve specialized DITA doctype

New Here ,
Nov 22, 2019 Nov 22, 2019

Copy link to clipboard

Copied

I have a client-specific DITA specialization. I've configured my structapps.fm file to handle the specialization and I can successfully read and write DITA files in Structured FrameMaker (2019)

 

However, part of the specialization requires me to use XSL to transform the DITA before it's imported into FrameMaker. I've successfully written preprocessing transforms before, but those were for standard DITA content without custom specializations.

 

I believe all the pieces are in a row, however when the parser used by SAXON attempts to open the DITA topic, it cannot resolve the public doctype identifier. It falls back on the (more-or-less pro forma) system identifier and fails, because—of course—the DTD file is not local to the topic.

 

Here is my application from structapps.fm:

Application name:    xxx-topic
DTD: $STRUCTDIR\xml\DITA_1.3\app\xxx\dita-ot-2.5.4-xxx\plugins\com.xxx.doctypes\dtd\xxx-topic.dtd
Read/write rules:    $STRUCTDIR\xml\DITA_1.3\app\xxx\xxx\xxx-topic.rules.txt
XSLT Preferences:    
Preprocessing:    
XSLT Processor:    SAXON
Stylesheet:    $STRUCTDIR\xml\DITA_1.3\app\xxx\xslt\xxx-import.xsl
Postprocessing:    
XSLT Processor:    SAXON
Stylesheet:    $STRUCTDIR\xml\DITA_1.3\app\xxx\xslt\xxx-export.xsl
Template:    $STRUCTDIR\xml\DITA_1.3\app\xxx\xxx\xxx.template.fm
Entity locations
Public ID:  -//xxx//DTD DITA xxx Topic//EN
Filename:  $STRUCTDIR\xml\DITA_1.3\app\xxx\dita-ot-2.5.4-xxx\plugins\com.xxx.doctypes\dtd\xxx-topic.dtd
Conditional Text:    
Output Text PI:    OutputVisibleTextWithoutPIs
Use API client:    ditafm_app

This is the relevant portion of my test file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xxx-topic PUBLIC "-//xxx//DTD DITA xxx Topic//EN" "xxx-topic.dtd">
<xxx-topic id="topic_a">
    <title>Topic A</title>
    <xxx-body>
        ...
    </xxx-body>
</xxx-topic>

Finally, here's what I get on the console:

XSL:C:\Program Files\Adobe\Adobe FrameMaker 2019\structure\xml\DITA_1.3\app\xxx\xslt\xxx-import.xsl

XSL Processor Messages (Processor: SAXON)
I/O error reported by XML parser processing file:/C:/Users/simonfbate/Documents/xxx/test-files/xxx-topic_a.dita: Could not find file 'C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic.dtd'.
I/O error reported by XML parser processing file:/C:/Users/simonfbate/Documents/xxx/test-files/xxx-topic_a.dita: Could not find file 'C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic.dtd'.

Transformation Aborted.

XML Read Report Log
Source Document: C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic_a.dita

XSLT Processor Messages
XSL Transformation Log
Input: C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic_a.dita
XSL:C:\Program Files\Adobe\Adobe FrameMaker 2019\structure\xml\DITA_1.3\app\xxx\xslt\xxx-import.xsl
XSL Processor Messages (Processor: SAXON)
I/O error reported by XML parser processing file:/C:/Users/simonfbate/Documents/xxx/test-files/xxx-topic_a.dita: Could not find file 'C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic.dtd'.
I/O error reported by XML parser processing file:/C:/Users/simonfbate/Documents/xxx/test-files/xxx-topic_a.dita: Could not find file 'C:\Users\simonfbate\Documents\xxx\test-files\xxx-topic.dtd'.
Transformation Aborted.

 

The application is able to read and write the specialized DITA content when I remove the preprocessing transform elements from structapps.fm. I have not yet tested whether the postprocessing (export) XSL works; I want to resolve the preprocessing issue first.

I tried replacing $STRUCTURE with the absolute path in the Entity Locations filename, but that made no difference.

Saving a copy of the DTD in the source folder is a non-starter. It's not practical and we deem that it's not acceptable to the client.

 

In other discussions in this forum, I've seen mention of passing parameters to the XSL from FrameMaker, but because the error is happening in the parser, rather than in XSL proper, that doesn't help.

 

If anyone has any ideas about why the parser is not resolving the public DOCTYPE, I'd love to hear them.

 

Thanks,

Simon

TOPICS
Structured

Views

658

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Expert , Dec 02, 2019 Dec 02, 2019

I may be missing it, but does your XMLApplication have a DOCTYPE element? Try adding a DOCTYPE child with xxx-topic as the content and see what happens.

Votes

Translate

Translate
Adobe Employee ,
Nov 25, 2019 Nov 25, 2019

Copy link to clipboard

Copied

Hi,

I have sent you a private message. Kindly help us with the information so that we can connect and look into the issue.

Regards,

Ajit

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Dec 02, 2019 Dec 02, 2019

Copy link to clipboard

Copied

Hello,

 

I'm having the same problem, FM-XSLT doesn't take the public Doctype (only if it's in the same folder as the xml source file).

 

Does Adobe already have a solution for that error ?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 02, 2019 Dec 02, 2019

Copy link to clipboard

Copied

I may be missing it, but does your XMLApplication have a DOCTYPE element? Try adding a DOCTYPE child with xxx-topic as the content and see what happens.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Dec 02, 2019 Dec 02, 2019

Copy link to clipboard

Copied

Bingo!

That was it (doh!).

Thanks!

Simon

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Dec 02, 2019 Dec 02, 2019

Copy link to clipboard

Copied

LATEST

Thanks for marking my answer as correct. As a word of warning, I actually discovered this because I had the opposite problem: I had two structured applications with the same DOCTYPE and was getting the same error as you did.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines