I tried some more experiments.
I used the BaseX GUI as follows:
1. Created a new database and used the GUI to select the catalog file directly. 2. Used the add function from the New Database dialog to load a directory, selecting all the .xml, .dita, and .ditamap files.
All the DITA files were skipped.
I did the same test using 8.4.1 under OS X but against the same source files and catalog and it worked fine.
So this seems to be a general issue with catalog resolution under Windows.
Cheers,
E. ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/12/16, 6:11 PM, "Eliot Kimber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of ekimber@contrext.com> wrote:
I'm trying to make BaseX work under Windows 7 and I don't seem to be able to get catalog resolution to work. (I'm doing a workshop in Japan and the classroom only has 32-bit Windows machines available--since Docker requires 64-bit Windows I'm having to scramble to make the same code work directly under Windows 7 32-bit--ugh.)
I'm using BaseX 8.4.1 with Java 8 (the Java supplied with the 32-bit version of oXygenXML).
In my .basex file I have these entries:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml" DTD = true SKIPCORRUPT = true CHOP = false
Using the DBA Web app I can see that the CATFILE property is set to that value, DTD is checked, CHOP is unchecked, and SKIPCORRUPT is checked, so my settings are clearly being used.
However, if I create a database and use the DBA app to load a document that uses a DTD mapped by the catalog (e.g., a DITA document), load fails with a "Can't resolve DTD" message.
The document is valid according to oXygen (and it's the same catalog--this is the OT oXygen is using) and of course my OS X and Docker-based versions of the same setup work fine, so it looks like a Windows-specific issue.
Is there any known issue with catalog resolution under Windows? Is there anything I can do to try to debug the problem?
Thanks,
Eliot
Eliot Kimber, Owner Contrext, LLC http://contrext.com
I tried the same experiment on Windows 10 and got the same failure result as on Windows 7. Java is:
C:\WINDOWS\system32>java -version java version "1.8.0_66" Java(TM) SE Runtime Environment (build 1.8.0_66-b18) Java HotSpot(TM) 64-Bit Server VM (build 25.66-b18, mixed mode)
Cheers,
Eliot ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/13/16, 9:05 AM, "Eliot Kimber" ekimber@contrext.com wrote:
I tried some more experiments.
I used the BaseX GUI as follows:
- Created a new database and used the GUI to select the catalog file
directly. 2. Used the add function from the New Database dialog to load a directory, selecting all the .xml, .dita, and .ditamap files.
All the DITA files were skipped.
I did the same test using 8.4.1 under OS X but against the same source files and catalog and it worked fine.
So this seems to be a general issue with catalog resolution under Windows.
Cheers,
E.
Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/12/16, 6:11 PM, "Eliot Kimber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of ekimber@contrext.com> wrote:
I'm trying to make BaseX work under Windows 7 and I don't seem to be able to get catalog resolution to work. (I'm doing a workshop in Japan and the classroom only has 32-bit Windows machines available--since Docker requires 64-bit Windows I'm having to scramble to make the same code work directly under Windows 7 32-bit--ugh.)
I'm using BaseX 8.4.1 with Java 8 (the Java supplied with the 32-bit version of oXygenXML).
In my .basex file I have these entries:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml" DTD = true SKIPCORRUPT = true CHOP = false
Using the DBA Web app I can see that the CATFILE property is set to that value, DTD is checked, CHOP is unchecked, and SKIPCORRUPT is checked, so my settings are clearly being used.
However, if I create a database and use the DBA app to load a document that uses a DTD mapped by the catalog (e.g., a DITA document), load fails with a "Can't resolve DTD" message.
The document is valid according to oXygen (and it's the same catalog--this is the OT oXygen is using) and of course my OS X and Docker-based versions of the same setup work fine, so it looks like a Windows-specific issue.
Is there any known issue with catalog resolution under Windows? Is there anything I can do to try to debug the problem?
Thanks,
Eliot
Eliot Kimber, Owner Contrext, LLC http://contrext.com
Hi Eliot,
I didn’t recently try it on Windows myself, but just two observations.
On 13.03.2016 01:13, Eliot Kimber wrote:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml"
There is a trailing quote sign here, is this intentional? Don’t know the effects of unbalanced quotes here.
In any case, it might be necessary to give the location as a file: URI, as in file:///C:/workspace/DITA-OT2.x/catalog-dita.xml Did you already try that?
Gerrit
I was just trying that now (the trailing quote was my typo but was also a red herring).
Yes, the value must be a URL and I've verified that using file:/c:/... works.
I'm trying to put together a code patch that does this automatically when a normal filename is specified because this is pretty bad Simon Says behavior. It doesn't help that the Javadoc for the Apache CatalogManager isn't itself explicit that the catalog files property is in fact URLs, not OS-specific file paths.
Cheers,
E.
---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/13/16, 5:19 PM, "Imsieke, Gerrit, le-tex" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of gerrit.imsieke@le-tex.de> wrote:
Hi Eliot,
I didn¹t recently try it on Windows myself, but just two observations.
On 13.03.2016 01:13, Eliot Kimber wrote:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml"
There is a trailing quote sign here, is this intentional? Don¹t know the effects of unbalanced quotes here.
In any case, it might be necessary to give the location as a file: URI, as in file:///C:/workspace/DITA-OT2.x/catalog-dita.xml Did you already try that?
Gerrit
I remember trying to figure out if the catalog files are supposed to be URIs or file paths (in commons resolver), and I think it was Catalog.parseCatalogFile that had a problem. It tries essentially:
catalogPath = path.replace(‘\', ‘/‘)
new URL(baseURL, catalogPath)
and if that is a malformed URL, it tries:
new URL(“file:”, catalogPath)
So, with a canonical windows file path, the URL that it uses is:
file:c:/somewhere/some.file
And then later somewhere that URL is not resolved.
Kendall
On 3/13/16, 12:27 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Eliot Kimber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of ekimber@contrext.com> wrote:
I was just trying that now (the trailing quote was my typo but was also a red herring).
Yes, the value must be a URL and I've verified that using file:/c:/... works.
I'm trying to put together a code patch that does this automatically when a normal filename is specified because this is pretty bad Simon Says behavior. It doesn't help that the Javadoc for the Apache CatalogManager isn't itself explicit that the catalog files property is in fact URLs, not OS-specific file paths.
Cheers,
E.
Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/13/16, 5:19 PM, "Imsieke, Gerrit, le-tex" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of gerrit.imsieke@le-tex.de> wrote:
Hi Eliot,
I didn¹t recently try it on Windows myself, but just two observations.
On 13.03.2016 01:13, Eliot Kimber wrote:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml"
There is a trailing quote sign here, is this intentional? Don¹t know the effects of unbalanced quotes here.
In any case, it might be necessary to give the location as a file: URI, as in file:///C:/workspace/DITA-OT2.x/catalog-dita.xml Did you already try that?
Gerrit
new URL(“file:” + catalogPath)
Appending text together seems to not be the best way to construct a URI.
On 3/13/16, 1:02 PM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
I remember trying to figure out if the catalog files are supposed to be URIs or file paths (in commons resolver), and I think it was Catalog.parseCatalogFile that had a problem. It tries essentially:
catalogPath = path.replace(‘\', ‘/‘)
new URL(baseURL, catalogPath)
and if that is a malformed URL, it tries:
new URL(“file:”, catalogPath)
So, with a canonical windows file path, the URL that it uses is:
file:c:/somewhere/some.file
And then later somewhere that URL is not resolved.
Kendall
On 3/13/16, 12:27 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Eliot Kimber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of ekimber@contrext.com> wrote:
I was just trying that now (the trailing quote was my typo but was also a red herring).
Yes, the value must be a URL and I've verified that using file:/c:/... works.
I'm trying to put together a code patch that does this automatically when a normal filename is specified because this is pretty bad Simon Says behavior. It doesn't help that the Javadoc for the Apache CatalogManager isn't itself explicit that the catalog files property is in fact URLs, not OS-specific file paths.
Cheers,
E.
Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/13/16, 5:19 PM, "Imsieke, Gerrit, le-tex" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of gerrit.imsieke@le-tex.de> wrote:
Hi Eliot,
I didn¹t recently try it on Windows myself, but just two observations.
On 13.03.2016 01:13, Eliot Kimber wrote:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml"
There is a trailing quote sign here, is this intentional? Don¹t know the effects of unbalanced quotes here.
In any case, it might be necessary to give the location as a file: URI, as in file:///C:/workspace/DITA-OT2.x/catalog-dita.xml Did you already try that?
Gerrit
This code would fail to construct a good Windows file: URL because it misses out the "/" after the "file:".
Cheers,
E. ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/14/16, 5:02 AM, "Kendall Shaw" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of kendall.shaw@workday.com> wrote:
I remember trying to figure out if the catalog files are supposed to be URIs or file paths (in commons resolver), and I think it was Catalog.parseCatalogFile that had a problem. It tries essentially:
catalogPath = path.replace(‘\', ‘/‘)
new URL(baseURL, catalogPath)
and if that is a malformed URL, it tries:
new URL(“file:”, catalogPath)
So, with a canonical windows file path, the URL that it uses is:
file:c:/somewhere/some.file
And then later somewhere that URL is not resolved.
Kendall
On 3/13/16, 12:27 AM, "basex-talk-bounces@mailman.uni-konstanz.de on behalf of Eliot Kimber" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of ekimber@contrext.com> wrote:
I was just trying that now (the trailing quote was my typo but was also a red herring).
Yes, the value must be a URL and I've verified that using file:/c:/... works.
I'm trying to put together a code patch that does this automatically when a normal filename is specified because this is pretty bad Simon Says behavior. It doesn't help that the Javadoc for the Apache CatalogManager isn't itself explicit that the catalog files property is in fact URLs, not OS-specific file paths.
Cheers,
E.
Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 3/13/16, 5:19 PM, "Imsieke, Gerrit, le-tex" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of gerrit.imsieke@le-tex.de> wrote:
Hi Eliot,
I didn¹t recently try it on Windows myself, but just two observations.
On 13.03.2016 01:13, Eliot Kimber wrote:
CATFILE = C:/workspace/DITA-OT2.x/catalog-dita.xml"
There is a trailing quote sign here, is this intentional? Don¹t know the effects of unbalanced quotes here.
In any case, it might be necessary to give the location as a file: URI, as in file:///C:/workspace/DITA-OT2.x/catalog-dita.xml Did you already try that?
Gerrit
basex-talk@mailman.uni-konstanz.de
-
Eliot Kimber -
Imsieke, Gerrit, le-tex -
Kendall Shaw