XML parser I/O error disappears if mentioned file is open in OxygenXML

Oxygen general issues.
michaelmh
Posts: 18
Joined: Tue Jan 19, 2016 5:55 pm

XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by michaelmh »

Hi folks,
I am working with a set of XSLT routines to migrate content from a previous environment. Everything is local, I am using OxygenXML Developer 28.0, build 2026020208.
The routines involve lookups in many (100+) other XML files to pull in content based on IDs, most of them have a DOCTYPE entry and I configured my Oxygen project to use catalog files which resolve the public identifiers to actual DTD files. When I open any of those files, the validation is successful.
I access the files like this:

Code: Select all

<xsl:variable name="instr" select="doc('../../input/reuse-rgd/_config/' || $srcLang || '/instr.xml')/cfg/group/instr-group[@id eq $instrId]" as="element(instr-group)"/>
For exactly this element, the XML parser reports:

I/O error reported by XML parser processing file:/C:/Users/path/input/reuse-rgd/_config/bg/instr.xml: Cannot resolve URI supplied for entity resolution

BUT: If I have this exact file open in OxygenXML, there is no error!
I am baffled and assume that I hit certain limitations regarding calls to files. Can I change certain settings to avoid this effect or shall I change the processing?

I would greatly appreciate any tips.
Best regards,
Michael
michaelmh
Posts: 18
Joined: Tue Jan 19, 2016 5:55 pm

Re: XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by michaelmh »

My first test was to change the code like this, but the problem persists.

Code: Select all

<xsl:variable name="theDoc" select="doc('../../input/reuse-rgd/_config/' || $srcLang || '/instr.xml')" as="document-node()"/>
<xsl:variable name="instr" select="$theDoc/cfg/group/instr-group[@id eq $instrId]" as="element(instr-group)"/>
By adding some log messages I can tell that this call comes earlier in the process for a similar file in a parallel folder (English instead of Bulgarian), but the call to the Bulgarian file is the first. The problem applies also to other languages.
michaelmh
Posts: 18
Joined: Tue Jan 19, 2016 5:55 pm

Re: XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by michaelmh »

Some more information.
The files, that needs to be open to be successfully validated contain many named entities in an internal DOCTYPE subset, like so

Code: Select all

<!DOCTYPE cfg PUBLIC "-//X//Y//EN" "cfg.dtd" [
<!ENTITY name1 SYSTEM "cfg\name1.xml">
<!ENTITY name2 SYSTEM "cfg\name2.xml">
<!ENTITY name3 SYSTEM "cfg\name3.xml">
<!-- etc. -->
Could this be the problem, that this file needs many more files to open to be assumed valid?
Mircea
Posts: 151
Joined: Tue Mar 25, 2003 11:21 am

Re: XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by Mircea »

Hi Michael,

If you're still looking for help, a small project demonstrating the issue would be very useful for us to take a look.
Please consider sending it to: support at oxygenxml dot com.

Best regards,
Mircea.
Mircea Enachescu
<oXygen> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
teo
Posts: 107
Joined: Wed Aug 30, 2017 3:56 pm

Re: XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by teo »

Hi Michael,

I'll give you details on how we tested, using a test setup explained below.

Code: Select all

project/
 |-- catalog.xml
 |-- dtd/
 |    |-- test.dtd
 |-- input/
 |    |-- reuse-rgd/
 |         |-- _config/
 |              |-- en/
 |              ¦    |-- instr.xml
 |              |-- bg/
 |                   |-- instr.xml
 |-- main.xsl

The catalog (added in Options > Preferences > XML > XML Catalog):

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
    <public
        publicId="-//TEST//DTD CONFIG 1.0//EN"
        uri="dtd/test.dtd"/>
</catalog>
The file "test.dtd":

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT cfg (group)>
<!ELEMENT group (instr-group)>
<!ELEMENT instr-group (#PCDATA)>
<!ATTLIST instr-group id CDATA #REQUIRED>
The files "instr.xml":

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cfg PUBLIC "-//TEST//DTD CONFIG 1.0//EN" "config.dtd">

<cfg>
    <group>
        <instr-group id="A">English</instr-group>
    </group>
</cfg>
and:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cfg PUBLIC "-//TEST//DTD CONFIG 1.0//EN" "config.dtd">

<cfg>
    <group>
        <instr-group id="A">Bulgarian</instr-group>
    </group>
</cfg>
The file "main.xsl":

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:math="http://www.w3.org/2005/xpath-functions/math"
    exclude-result-prefixes="xs math"
    version="3.0">    
    
    <xsl:param name="srcLang" as="xs:string"/>
    <xsl:param name="instrId" as="xs:string"/>
    
    <xsl:template match="/">        
        <xsl:variable name="instr"
            select="doc('input/reuse-rgd/_config/' || $srcLang || '/instr.xml')
            /cfg/group/instr-group[@id eq $instrId]"
            as="element(instr-group)?"/>
        
        <result>
            <xsl:value-of select="$instr"/>
        </result>        
    </xsl:template>    
</xsl:stylesheet>
All of these files are valid according to the default validation scenarios associated by Oxygen with their types.
I then configured an "XSLT Transformation on XML" scenario for "main.xsl" (with Saxon-PE 12.9 as the engine, and the XML target being "instr.xml") and configured the parameters:
instrId = 'A'
srcLang = 'bg'

Some observations and conclusions:
1. Running the transformation scenario yields the expected result: <?xml version="1.0" encoding="UTF-8"?><result>Bulgarian</result>
2. If I delete the catalog from Options > Preferences > XML > XML Catalog, then running the transformation fails (which was expected):
I/O error reported by XML parser processing .../input/reuse-rgd/_config/en/instr.xml: ...\input\reuse-rgd\_config\en\config.dtd (The system cannot find the file specified)
3. The message above is different from the one you reported, however. Maybe it comes from the engine you used for the transformation, maybe a custom one.
Or maybe my simplified test setup does not accurately reflect your situation, your working context.
4. My conclusion is that a well-configured XML catalog should allow the transformations in question without errors.

Regards,
Teo
Teodor Timplaru
<oXygen/> XML Editor
http://www.oxygenxml.com
michaelmh
Posts: 18
Joined: Tue Jan 19, 2016 5:55 pm

Re: XML parser I/O error disappears if mentioned file is open in OxygenXML

Post by michaelmh »

Hi Teo,
What a great effort in reproducing the situation. Thank you very much for this.

The main difference is that in my case the instr.xml contains references to more, other instr.xml. The called file represents a group of instruments, which contains certain information for the instrument group but also all other instruments.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cfg PUBLIC "-//TEST//DTD CONFIG 1.0//EN" "cfg.dtd" [
<!ENTITY instr_a SYSTEM "zz_instr\instr_a.xml">
<!ENTITY instr_b SYSTEM "zz_instr\instr_b.xml">
<!ENTITY instr_c SYSTEM "zz_instr\instr_c.xml">
]>
<cfg xml:lang="bg">
  <group topic="instr">&instr_a;&instr_b;&instr_c;
    <instr-group id="xyz"><name>Система XYZ</name></instr-group>
  </group>
</cfg>
The XML files included using entities using this method are each well-formed, but follow the cfg.dtd to be valid. They look similar to this

Code: Select all

<instr id="a630" xml:lang="bg">
  <name>Система  630</name>
</instr>
From what I understand, this creates an additional level of complexity.

My process runs fine if those 30 files are open. But opening them (and each has about 70+ of those included files) takes a while, and astonishingly, closing is also slow. I observed that closing those files using the Close Files to the Right menu command takes easily 30 seconds.

Isolating the behavior will be rather tricky, but I could show you in a demo.
Best regards,
Michael
Post Reply