Re: [xml] Catalogs and relative paths

On Wednesday 28 May 2003 08:53, you wrote:
What does the catalog you are using look like?

Sorry, I should have made the test available: I've put a copy at 
<> (put the rewrite 
and virtual directories under the web server root).

Anyway, here's the catalog:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog 
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

  <system systemId="http://localhost/virtual/test.xml";
  <uri name="http://localhost/virtual/test.xml";

  <system systemId="http://localhost/virtual/include.xml";
  <uri name="http://localhost/virtual/include.xml";

The test runs:

1) xsltproc null.xsl \
correctly outputs:
        <?xml version="1.0"?>
        This is the correct test.xml.

2) xsltproc --xinclude null.xsl \
I expected:
        <?xml version="1.0"?>
        This is the correct test.xml.
        This is rewrite/indirected.xml, which virtual/include.xml should resolve to.
Actual output:
        <?xml version="1.0"?>
        This is the correct test.xml.
        This is rewrite/include.xml which should not be accessed, if relative paths
        work the way I think they do.

(Omitting either the <system/> or <uri/> elements in the catalog doesn't 
change the result.)

I've adapted the external entity handler from libxml2 to give me the results I 
expected; the changes are trivial, and I'll convert it into a patch for 
libxml2 if the results I expected are correct, or incorporate it into my app 
if these changes shouldn't be the default behaviour. For now, there's a copy 
in <> (changed functions in 
libxml_fakebase.[ch], and a slightly modified xsltproc.c for testing 

Change summary:

* replace xmlNewInputFromFile(filename) with a similar function taking two 
arguments, "filename" (the rewritten URI) and "original" (the original URI)

* in this function, pass "filename" (the rewritten URI) to 
xmlParserInputBufferCreateFilename, but use "original" instead to fill in the 
"filename" and "directory" fields of the xmlParserInputPtr

* call this function from the external entity handler.

for instance converting
http://wwwsource/foo to file:///home/smcv/websource/foo.xml.
(This lets me
use relative paths starting with / in a convenient way)

A parh starting with '/' is not relative per definition.

OK, "relative URIs starting with /". As filenames they'd be absolute, but in 
URI terms they're relative since they depend on the base URI's scheme and 
authority components.

The reason I wanted to do this: with the base URI set to the "virtual" 
http://wwwsource/foo, /some/path means http://wwwsource/some/path, which then 
gets mapped usefully to file:///home/smcv/websource/some/path.xml. If the 
base URI is the "rewritten" file:///home/smcv/websource, /some/path means 
file:///some/path, which is pretty useless if all my source code is contained 
in the websource directory.

(I admit I *could* use purely relative paths, but that makes repeated 
references references to "global" resources unwieldy - either I'd have to use 
the full URI with the authority and scheme, or decide on a per-page basis how 
many ../ components to prepend. I use the same method on my website, so my 
internal links all look like "/2003/css/base.css".)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]