Skip to main content
J
jmuenning1-Visitor
1-Visitor
December 11, 2014
Question

Error running compose_using_xsl()

  • December 11, 2014
  • 4 replies
  • 1764 views

Hi all,


I am trying to use compose::compose_using_xsl( ) in Arbortext Editor 6.0 F000 to transform JATS 1.0 XML to NLM 2.2 XML. My XSLT 2.0 script was developed and runs exactly as intended in Oxygen using Saxon-PE 9.0.3.5 with no errors. When I run it using compose_using_xls() on a valid JATS instance, however, I am getting a return value of -1 and am seeing the following in the Event Log:


<record date="Thu" dec=" 11=" 10:29:11=" est=" 2014&quot;=" millis="1418311751648" severity="info" suppress="1">
<level>INFO</level>
<message>"file_serializer": Set buffering to off and flushing on pipe # "1".</message>
<context class="com.arbortext.epic.internal.compose.FilterContainerImpl" linenumber="271"&lt;br"/> method="endDocument" systemId="FilterContainerImpl.java"/>
</record>
<record date="Thu" dec=" 11=" 10:29:11=" est=" 2014&quot;=" millis="1418311751715" severity="fatal" suppress="0">
<level>FATAL ERROR</level>
<message>java.lang.NullPointerException</message>
</record>
<record date="Thu" dec=" 11=" 10:29:11=" est=" 2014&quot;=" millis="1418311751734" msgid="A50005"&lt;br"/> severity="error" suppress="0">
<level>ERROR</level>
<message location="(256,8,24)" publicid="EPIC">endDocument() fail (Saxparse for
NEJMra1407298_jem.xml).</message>
</record>
<record date="Thu" dec=" 11=" 10:29:11=" est=" 2014&quot;=" millis="1418311751735" severity="fatal" suppress="0">
<level>FATAL ERROR</level>
<message>Fatal error encountered while running composition pipeline. Configuration File:
"C:\Program Files\PTC\Arbortext Editor\composer\xsl.ccf".</message>
<context class="com.arbortext.epic.internal.compose.ComposerImpl" linenumber="210"&lt;br"/> method="runPipeline" systemId="ComposerImpl.java"/>
<record date="Thu" dec=" 11=" 10:29:11=" est=" 2014&quot;=" millis="1418311751735" msgid="A50005"&lt;br"/> severity="fatal">
<level>FATAL ERROR</level>
<message>endDocument() fail</message>
</record>
</record>
<record date="Thu" dec=" 11=" 10:29:11=" 2014&quot;=" millis="1418311751" severity="fatal" suppress="0">
<level>FATAL ERROR</level>
<message>Operation terminated.</message>
</record>


The XSLT contains an xsl:character-map to transform Unicode to numbered character references with hex encodings. After some experimentation, I discovered that the XSLT will run when I don’t use the character-map. In other words, the process will fail and I will see the message above when the XSLT contains this code:


<xsl:output method="xml" indent="no" encoding="UTF-8" use-character-maps="nejm-nlm-chars-test" <br="/> doctype-public="-//NLM//DTD Journal Publishing DTD v2.2 20060430//EN"
doctype-system="journalpublishing.dtd" />

<xsl:character-map name="nejm-nlm-chars-test">


<xsl:output-character character="À" string="À"/>
</xsl:character-map>


But not when it contains just this code:


<xsl:output method="xml" indent="no" encoding="UTF-8" <br="/> doctype-public="-//NLM//DTD Journal Publishing DTD v2.2 20060430//EN"
doctype-system="journalpublishing.dtd" />


Does anyone know how I can get Arbortext’s XSL processing to work with the character map in place? Am I missing something?


Thanks!


John

    4 replies

    L
    largyres1-Visitor
    1-Visitor
    December 11, 2014

    Do uou have the option of going directly thru Saxon?


    It's pretty straightfoward in ACL. Startingfrom


    local $output_file = "C:/temp/output_file.xml";


    # look at other switches here, e.g., -nopi -nonasciichar numref



    local problem = system("$java_xsl_cmd");




    method="endDocument" systemId="FilterContainerImpl.java"/>


    FATAL ERROR
    java.lang.NullPointerException

    severity="error" suppress="0">
    ERROR
    endDocument() fail (Saxparse for
    NEJMra1407298_jem.xml).


    FATAL ERROR
    Fatal error encountered while running composition pipeline. Configuration File:
    "C:\Program Files\PTC\Arbortext Editor\composer\xsl.ccf".
    method="runPipeline" systemId="ComposerImpl.java"/>
    severity="fatal">
    FATAL ERROR
    endDocument() fail



    FATAL ERROR
    Operation terminated.


    The XSLT contains an xsl:character-map to transform Unicode to numbered character references with hex encodings. After some experimentation, I discovered that the XSLT will run when I don't use the character-map. In other words, the process will fail and I will see the message above when the XSLT contains this code:


    doctype-public="-//NLM//DTD Journal Publishing DTD v2.2 20060430//EN"
    doctype-system="journalpublishing.dtd" />








    But not when it contains just this code:


    doctype-public="-//NLM//DTD Journal Publishing DTD v2.2 20060430//EN"
    doctype-system="journalpublishing.dtd" />


    Does anyone know how I can get Arbortext's XSL processing to work with the character map in place? Am I missing something?


    Thanks!


    John


    L
    largyres1-Visitor
    1-Visitor
    December 11, 2014

    and you'll need some to escape some of those quotes in local java_xsl_cmd ... " (weird, paste or Post lost 'em)


    - Lou

    J
    jmuenning1-VisitorAuthor
    1-Visitor
    December 12, 2014

    Thanks, Lou. I had previously tried using a system call directly to Saxon in ACL, but I had errors with catalog resolution: Saxon could't find the DTD referenced in source file. That wasn't a problem when I ran the transform through Arbortext with compose_using_xsl(), but then I had the problem with the character-map that I described in my previous message. I took your cue, went back the direct approach, and realized that I could use the write -sysid option to write the full path to the DTD into the input file before calling running the transform directly in Saxon. That works like a charm, so I won't be using compose_using_xsl() after all.


    John


    John Muenning | New England Journal of Medicine

    L
    largyres1-Visitor
    1-Visitor
    December 12, 2014

    Glad to hear it's working John.


    The -noheader switch for the write command removes the declaration altogether, so you shouldn't need to worry about either.


    ... and I can't resist trying a double backslah "\" for an escape 😉


    - Lou

    Terms & ConditionsAccessibility statement