Menu
▾
▴
#3 Problems locating DTDs with relative URIs
Suppose I point XPE at an XML document which contains the following DOCTYPE:
<!DOCTYPE config SYSTEM "config.dtd">
and the DTD lives in the same directory as the XML file.
When the URL is this:
http://localhost:8080/CityScape/CityScapeA.xml
I get the following message from XPE:
java.io.FileNotFoundException: D:\JavaTools\xpe\realEstate.dtd (The system cannot find the file specified)
at com.meterware.httpunit.WebResponse.getDOM(WebResponse.java:361)
at xpe.XPE.loadDocumentHttpUnit(XPE.java:280)
at xpe.XPE.loadDocument(XPE.java:254)
at xpe.XPE.<init>(XPE.java:57)
at xpe.XPEPanel.updateXPE(XPEPanel.java:249)
at xpe.XPEPanel.evaluate(XPEPanel.java:268)
at xpe.XPEPanel.load(XPEPanel.java:231)
etc etc.
The problem here is that the XML parser is looking for the DTD in the wrong place - it is looking in the directory in which xpe.jar was launched from.
Similarly, when the URL is this:
file:c:/Program Files/Apache Tomcat 4.0/webapps/CityScape/CityScapeA.xml
I get the following from XPE:
java.io.FileNotFoundException: D:\JavaTools\xpe\realEstate.dtd (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:103)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:148)
at java.net.URL.openStream(URL.java:955)
at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:719)
at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:681)
at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:256)
at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:814)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:328)
at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:479)
at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:521)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:148)
at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:211)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:224)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:86)
at xpe.XPE.loadDocumentJAXP(XPE.java:292)
at xpe.XPE.loadDocument(XPE.java:267)
at xpe.XPE.<init>(XPE.java:57)
at xpe.XPEPanel.updateXPE(XPEPanel.java:249)
at xpe.XPEPanel.evaluate(XPEPanel.java:268)
at xpe.XPEPanel.load(XPEPanel.java:231)
etc etc
I believe that the root cause of the problem is that the methods in the XPE class which load documents use an InputStream rather than an InputSource, which means that the XML parser loses the URL context for the DTD. I did hack around in the source code and at one point I successfully got documents containing a DOCTYPE to load successfully using HTTP, but file URLs were still a problem. (I gave up because I was running into classpath and version conflicts.)
Logged In: YES
user_id=258611
A sample URL displaying this behavior is:
http://tlaloc.sfsu.edu/~yoon/csc413/test/test2.xhtml
It contains
<!DOCTYPE xhtml SYSTEM "xhtml.dtd">
and the file http://tlaloc.sfsu.edu/~yoon/csc413/test/xhtml.dtd
does exist, but it still looks for it locally (using a file: URL
pointing to the local current directory, wherever Java was
launched from).
By the way, I believe that this is a flaw in the XML spec
itself. As far as I can tell, a relative reference like "config.dtd"
is not a legal value for the SYSTEM tag -- although it does
seem to work for local filesystems, due to lenient XML parser
implementations. It would be great if the people who designed
the XML spec had provided us a way to say "wherever this
doc is, the DTD is stored in the same directory," but I can't
find it.
If anyone can help me find a way to tell an XML parser to do
this, please let me know.
Note that I did think of a workaround, but it's nasty: you load
the file into memory as bytes, do a manual search-and-
replace of the SYSTEM string with its local-filesystem
equivalent, then parse that. Ugh.
Logged In: YES
user_id=258611
Sorry, that should be "with its remote-url equivalent"
Logged In: YES
user_id=258611
Logged In: YES
user_id=258611
A workaround for this issue is to use the Catalog Resolver. See
the web site at
http://www.purpletech.com/xpe/index.jsp#docbook for
instructions.
Logged In: YES
user_id=258611
There is a workaround. See the section "DocBook and CatalogResolver
support" on http://xpe.sf.net
I have added this as a feature request. See http://
sourceforge.net/
tracker/
index.php?func=detail&aid=743715&group_id=54719&atid=474582