Re: [xslt] Using catalog files on Windows

[Daniel Veillard <veillard redhat com>]

On Sun, Mar 10, 2002 at 09:39:26AM +0100, Jirka Kosek wrote:
> Thanks, setting XML_CATALOG_FILES works fine, I didn't know about this
> envar before. However setting SGML_CATALOG_FILES didn't affected entity
> resolution -- I played with its setting for a long time before posting
> my question.

  Strange, both are supported, but obviously with different semantics
concerning the object being pointed to.

> BTW, while using XML catalogs, I recognized that libxml catalog code
> resolves relative URIs in a different way than Norm's resolver. When I
> have something like
> 
>     <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
>             uri="docbookx.dtd"/>
> 
> in my XML catalog (it is in a same directory as docbookx.dtd),
> docbookx.dtd is not resolved relative to XML catalog and I get following
> error from xsltproc: 
> 
> Found public match -//OASIS//DTD DocBook XML V4.1.2//EN
> Resolve URI docbookx.dtd
> prvni.xml:3: warning: failed to load external entity "docbookx.dtd"
> 
> I can solve this problem by adding <group
> xml:base="file:///right/directory/here"> around <public/>, but I think
> that when there is no explicit xml:base, location of catalog file should
> be taken as xml:base. But to be honest I didn't read XML catalogs
> specification so precisely so I cann't really argue on this topic. 

  First xml:base is part of XML Catalogs:
 http://www.oasis-open.org/committees/entity/spec-2001-08-06.html#attrib.common

  And I'm 100% sure the URL for the resource is computed accordingly to the
base of the element holding the URI, the fact that adding xml:base makes it
work is just a proof of that. The code in catalog.c does:

xmlParseXMLCatalogOneNode()
....
    base = xmlNodeGetBase(cur->doc, cur);
    URL = xmlBuildURI(uriValue, base);
    if (URL != NULL) {
....

What is very possible is that your document hosting <public> ends-up
having a Windows path, and of course the xmlBuildURI() function which
applies RFC2396 URI-Reference building code to the letter fails to parse
base as an URI and you end-up having URL==uriValue leading to the behaviour
you are seeing.

  The best seems to make sure that you only use file:/// constructs in your
catalog hierarchy or in the environment variable holding the catalog paths.
All the uri fields in XML Catalogs are URI-Reference and Windows paths are
inadequate there, my bet is that's the source of the problem.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/