Re: [xml] Catalogs and relative paths

[Simon McVittie <hacks pseudorandom co uk>]

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 
<http://pseudorandom.co.uk/~smcv/libxml2/cat-test.tar.gz> (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 
V1.0//EN" 
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

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

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


The test runs:

1) XML_CATALOG_FILES=xml.cat xsltproc null.xsl \
        http://localhost/virtual/test.xml
correctly outputs:
        <?xml version="1.0"?>
        This is the correct test.xml.

2) XML_CATALOG_FILES=xml.cat xsltproc --xinclude null.xsl \
        http://localhost/virtual/test.xml
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 <http://pseudorandom.co.uk/~smcv/libxml2/> (changed functions in 
libxml_fakebase.[ch], and a slightly modified xsltproc.c for testing 
purposes).

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".)

Regards,
        Simon