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

> -----Original Message-----
> From: Daniel Veillard [mailto:daniel@veillard.com] 
> Sent: Thursday, 09 June, 2005 18:29
> To: Paul Grosso
> Cc: public-xml-core-wg@w3.org
> Subject: 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,

Actually, I am much more familiar with the opposite paradigm.

There is no system-wide catalog.  A given application (e.g.,
a particular editor) might have a default catalog, but if
that's the case, it's because the application wants to use
a particular catalog.

More generally, a user specifies a catalog to use if they
want to use one.

So for me, it's never the case that there is a system-wide
catalog, but it's extremely common for a given application
and/or user to specify their own catalog--or, in fact, a
hierarchy of catalogs to use for different doctypes or
whatever.

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

No catalog spec defines any such thing as a "system catalog",
but if you want to define such a thing, I think the wording
I quoted earlier from the catalog spec would allow you to do
just what you said above.  

So you would always go to the catalog(s) if the 'current catalog' 
is anything other than just what you call the 'system catalog', 
but if the 'current catalog' is nothing other than just what 
you call the 'system catalog', you can decide not to use it 
for 'local' paths.  (In fact, as long as your system catalog 
has no "system" or "rewriteSystem" or "delegateSystem" entries, 
avoiding the catalog for 'local' paths should't make any difference.)

paul

Received on Friday, 10 June 2005 15:21:11 UTC