Bug #3025: absolute windows paths for command line option -catalog causes an error "Malformed URL" - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3025

closed

absolute windows paths for command line option -catalog causes an error "Malformed URL"

Added by Stefan Krause about 8 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

O'Neil Delpratt

Category:

Command Line

Sprint/Milestone:

Start date:

2016-11-12

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7, 9.8

Fix Committed on Branch:

9.8, trunk

Fixed in Maintenance Release:

9.8.0.8

Platforms:

Description

Under some circumstances, a Windows styled absolute path for the command line option -catalog causes an error "Malformed URL"

The specific circumstances in my case are:

stylesheet A imports a stylesheet B, and the path to the imported stylesheet is given as an URN
catalog A references catalog B, catalog B resolves the path to stylesheet B
catalog B and stylesheet B reside within a subdirectory relative to stylesheet A and catalog A

The execution fails only, if the path to the catalog is given as an absolute path in Windows style. If the same catalog is refered as a relative path or an URI, the transformation succeeds.

The example files are attached to this ticket, the command line was

C:\_trash\saxonica>Saxon-PE\bin\Transform.exe -xsl:importing-stylesheet.xsl -it:main -catalog:c:\_trash\saxonica\catalog.xml

Im using Saxon Saxon-PE 9.7.0.7N on Windows 10 Build 1607

Files

saxonica.zip (1.42 KB) saxonica.zip

sample files to reproduce the bug

Stefan Krause, 2016-11-12 23:27

Actions

Copy link

Updated by Stefan Krause about 8 years ago

The bug also applies to Saxon-PE 9.7.0.11N.

Actions

Copy link

Updated by Michael Kay about 8 years ago

Category set to Command Line
Assignee set to O'Neil Delpratt

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Status changed from New to In Progress
Priority changed from Low to Normal
Applies to branch 9.7 added

Hi,

My apologies in taking so long to look at this bug issue. I did not see the problem on my Windows 7 machine, but when I tried running the same example on a different machine running with Windows 10 I reproduced the same exception you reported. Investigating the bug.

Actions

Copy link

Updated by Stefan Krause over 7 years ago

Is there any chance that you will fix it in the near future? Otherwise, I have to write a workaround on my side now. Thank you.

Actions

Copy link

Updated by O'Neil Delpratt over 7 years ago

Hi,

Sorry I let this bug issue slip. I will investigate further this bug issue in the week and get back to you shortly.

Actions

Copy link

Updated by O'Neil Delpratt over 7 years ago

This problem of the "Malformed URL" also happens on the Java platform in Windows 10. We can narrow down this issue to the Java platform as Saxon .NET is cross compiled from the Java product.

Actions

Copy link

Updated by O'Neil Delpratt over 7 years ago

Update:

Still investigating this one, which led me to look at the source of the xml-resolver-1.2.jar. This library is doing the mapping of catalog files to the URN.

For some reason the variable vector 'catalogEntries' which is held in the class Catalog.java of the xml-resolver.jar is empty under Windows 10 when we are doing the resolving. A call is made to resolveLocalURI within which failure to locate the urn in the catalogEntries vector. This results in a fallback, which is to use the supplied uri string which is a urn in our case. A Malformed URL Exception is subsequently thrown.

Actions

Copy link

Updated by O'Neil Delpratt over 7 years ago

We are setting the system property xml.catalog.files to the value supplied in the -catalog option.

It's not well documented, but it seems this system property expects to find a URI rather than a filename.

So the following work around should work:

-catalog:file:///c:/_trash/saxonica/catalog.xml

For the future, if the -u option is set or if the supplied value begins with http:// or file:// option then we should use it unchanged otherwise we should assume we have been given a file name and convert it to URI.

Actions

Copy link

Updated by O'Neil Delpratt over 7 years ago

Status changed from In Progress to Resolved
Applies to branch 9.8 added
Fix Committed on Branch 9.8 added

I have committed a fix to the 9.8 branch in accordance with comment #8.

Actions

Copy link

#10

Updated by Stefan Krause over 7 years ago

Do you have any idea when v9.8 will be released? Can you merge the bugfix back to the 9.7 branch? Thank you.

Actions

Copy link

#11

Updated by O'Neil Delpratt over 7 years ago

Status changed from Resolved to In Progress

Hi,

We will look if this can be retrofitted to the 9.7 branch.

Actions

Copy link

#12

Updated by Michael Kay over 7 years ago

9.8 is now in the testing phase. Hopefully it's now weeks rather than months away. But we let it cook until it tastes right, rather than deciding on a date in advance.

Actions

Copy link

#13