Re: can an app use an XML Catalog to resolve an xinclude href value?

On Thu, Jun 09, 2005 at 07:10:05PM -0400, Paul Grosso wrote:
> 
> What I don't understand is why an application would
> load a catalog that shouldn't be used.
> 
> You make it sound like you are always loading a catalog.
> If so, why?  You should only even consider using a catalog
> if the user has pointed to a catalog.  An XML processor should
> not go looking for catalogs unless the user has told it to
> do so.  And if the user has told you to use a catalog, I
> wouldn't be surprised if the user got upset when you then
> ignore it for some cases.
> 
> I'm probably misunderstanding something here.

  Because the catalog is a system wide resource. Anchored
in /etc/xml/catalog :

paphio:~ -> more /etc/xml/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">
  <delegatePublic publicIdStartString="-//OASIS//ENTITIES DocBook XML" catalog="file:///usr/share/sgml/docbook/xmlcatalog"/>
etc...

we don't expect the user to point to it, it's there, it doesn't 
cost anything in general *except* if you require to override
default file access resolution with it. All applications potentially
use the catalog. They do so only when the XML parser does not found
a local resource or tries to get to a remote resource.

Some users may override with their own catalog. It's really not common,
usually that's people building documentation and needing to override the
system default DocBook installation. 
The solution to the dilemna might be to force the behaviour you expect
if the person set a catalog environment variable to override the default
catalog, but keep the existing behaviour if they are using the system one.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |

Received on Thursday, 9 June 2005 23:28:52 UTC